Prev: get CPU info, RAM info
Next: ordinal() returns inconsistent values?
From: Tim Slattery on 8 Apr 2010 16:15
Jean-Baptiste Nizet <jnizetNOSPAM(a)NOSPAMfree.fr> wrote:


>In Tomcat, you have to declare a resource in
>the context of the webapp (see
>http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#JDBC%20Data%20Sources)

In spite of what it says there, I don't have to do that. I'm not doing
that and the app works.

--
Tim Slattery
Slattery_T(a)bls.gov
http://members.cox.net/slatteryt
From: Tom Anderson on 8 Apr 2010 19:53
On Thu, 8 Apr 2010, Tim Slattery wrote:

> Tom Anderson <twic(a)urchin.earth.li> wrote:
>
>> The Tomcat form is what the standard specifies. If you use that in
>> WebLogic and JBoss, does it work?
>
> Don't know about JBoss (that was a while ago), but it does not work in
> Weblogic.

Okay, having dug into this a bit, i think the rule is that java:comp/env
has to be visible *from a J2EE component*, which i suspect in practice
means from an EJB. It's basically a private environment area that
surrounds each component - each component actually has a *different*
comp/env. I would guess, then, that you're making your lookups from
outside a component - from code somewhere in the region of the servlets,
perhaps? In that case, there is no proper comp/env defined. Exactly where
in the JNDI namespace your resources are bound is, inexplicably, not
specified, and containers can do what they like. Tomcat makes it look the
same as if the lookup came from a component, WebLogic doesn't.

I haven't found a good solution for this. Most of the suggestions are
along the lines of this:

>> If not, er, well, yes. Define a server-dependent JNDI name prefix and pass
>> it in as an env-entry or system property, perhaps?
>
> No idea of that.

public class JNDILookupHelper {
public static Object lookup(String name) throws some exceptions {
String prefix = System.getProperty("jndi.prefix", "");
String fullName = prefix + name;
InitialContext ic = new InitialContext();
return ic.lookup(fullName);
}
}

Then apply -Djndi.prefix= as needed.

tom

--
In-jokes for out-casts
From: Tim Slattery on 9 Apr 2010 12:58
Tom Anderson <twic(a)urchin.earth.li> wrote:

>Okay, having dug into this a bit, i think the rule is that java:comp/env
>has to be visible *from a J2EE component*, which i suspect in practice
>means from an EJB. It's basically a private environment area that
>surrounds each component - each component actually has a *different*
>comp/env. I would guess, then, that you're making your lookups from
>outside a component - from code somewhere in the region of the servlets,
>perhaps?

Yes, a servlet. The app is based on Struts.

> String prefix = System.getProperty("jndi.prefix", "");

This looked really good, but....there's no "jndi.prefix" property in
either Tomcat 6 or Weblogic 10, nor anything close (I listed them all
out).

According to
http://java.sun.com/javaee/5/docs/tutorial/doc/bncjk.html, I should be
able to do this using "Resource injection", but I can't make that work
in either server.

--
Tim Slattery
Slattery_T(a)bls.gov
http://members.cox.net/slatteryt
From: Lew on 9 Apr 2010 17:38
Tom Anderson wrote:
>> String prefix = System.getProperty("jndi.prefix", "");

Tim Slattery wrote:
> This looked really good, but....there's no "jndi.prefix" property in
> either Tomcat 6 or Weblogic 10, nor anything close (I listed them all
> out).

There is if you don't ignore tom's suggestion to define one:
>> Then apply -Djndi.prefix= as needed.

Defining the variable to be read is a not-insignificant step.

> According to
> http://java.sun.com/javaee/5/docs/tutorial/doc/bncjk.html, I should be
> able to do this using "Resource injection", but I can't make that work
> in either server.

I've not been able to make resource / dependency injection work yet. I've
only tried it with GlassFish.

--
Lew
From: Abu Yahya on 10 Apr 2010 15:45
Roedy Green wrote:
> On Thu, 08 Apr 2010 09:03:56 -0400, Tim Slattery <Slattery_T(a)bls.gov>
> wrote, quoted or indirectly quoted someone who said :
>
>> This seems completely nuts to me. Am I missing a way around this, or
>> am I doomed to recompile and/or add searches on more and more variants
>> of the JNDI name?
>
> Hold your nose for this one. It smells of very old C++ code.
>
> Poke around in System.properties to see if you can find something that
> will tell you which womb you are using. Then write a method that does
> your JNDI given a magic string.
>

We had a similar problem, and went with a solution similar to what Roedy
suggests - finding out which womb we are in. We had to port our
application to Websphere and Tomcat. For Tomcat, we instantiate
InitialContext by calling the zero argument constructor, while in
WebSphere we need to pass a Properties object with a key-value pair of
Context.INITIAL_CONTEXT_FACTORY==>"com.ibm.websphere.naming.WsnInitialContextFactory"

So, here's what we did. We tried to get the initial context object using
the WebSphere method, but if that failed, we assumed we were in Tomcat
and called the zero argument constructor and attached the prefix.

Here's the relevant piece of code:

java.util.Properties parms = new java.util.Properties();

// Assume WebSphere
parms.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory");
try{
// Get initial context object
initCtx = new InitialContext(parms);
}catch(Exception c){
// Exception, so we are in Tomcat
initCtx = new InitialContext();
initCtx = (Context) initCtx.lookup("java:comp/env");
}
this.datasource = (DataSource) initCtx.lookup(dbDataSource);


> If there isn't anything, invent something. Possible tools:
> System.properties, SET environment, hide something in the persistence
> mechanism, loading a small XML config file, loading some
> tweaking/customisation code via Class.forName.
>
> This last one it what I use for my own static macros to load dozens of
> custom parameters and custom methods in one fell swoop.
>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: get CPU info, RAM info
Next: ordinal() returns inconsistent values?