Actually this one turned out to be due to using some bad sample/test code in the JBoss source, which has an extraneous character.

If you look in EJBTester.java and SimpleServlet.java, the code there sets the Context.URL_PKG_PREFIXES (aka "java.naming.factory.url.pkgs") value to "org.jboss.naming;". This is supposed to be a colon separated list of package prefixes. I have no idea how the trailing semicolon got into the value in the JBoss source.

My initial tries failed since I was creating the InitialContext with specific values passed in via the hashset, with said values cut and pasted from the sample code. I finally figured out what was going on when I noticed that the lookup worked if I relied on using a default InitialContext.

Regards,
Colin


David Jencks wrote:

this kind of problem often is a result of having a jndi.properties file
that directs jndi lookups through tcp/ip availiable to the servlet's
classloader. Check your packages and remove any such files.

david jencks

On 2002.11.13 11:13:08 -0500 Colin Sampaleanu wrote:

The original scenario (not written by me), was that a startup servlet called a session EJB which started Quartz, then Quartz started jobs from a pool of threads (I know this is theoretically not kosher since EJBs are not supposed to do thread management). One of these jobs then tried to access JNDI.

However, I have verified that even in the startup servlet (using Jetty as the web container), I am able to load a context in the global namespace, e.g.
Context cx = (Context) ic0.lookup("/queue");
works, but I am unable to load any contexts or objects in the java: namespace, e.g
Context cx = (Context) ic0.lookup("java:/jdbc");
DataSourcet ds0 = (Context) ic0.lookup("java:/DefautlDS");
Both of the latter fail with an exception that the name is not bound. I can see the binding are ok using the JNDI lister.

I have tried using both the defualt InitialContext (new InitialContext()), and also one with jboss specific (jnp) settings,
h.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
h.put(Context.URL_PKG_PREFIXES, "org.jboss.naming;");
with the same results.

I've also verified that the 'Java2ClassLoadingCompliance' value is set to true...

Colin


Scott M Stark wrote:


The java: namespace is not associated with threads, its associated with
a class loader. The context in which the lookup of the java: context
occurs must have a thread context class loader with a class loader

from the JBoss.

xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx

----- Original Message ----- From: "Colin Sampaleanu" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 12, 2002 7:55 PM
Subject: [JBoss-user] How to access datasource at java:whatever from

another thread?




I am binding a datasource using oracle-service.xml, which uses RarDeployment to bind the datasource to JNDI using the 'java:' namespace. Unfortuntately I have an issue accessing this from a thread started by a Quartz scheduled job, presumably because items in the

java:
namespace are thread specific, and the quartz started thread doesn't have a copy.

My jndi name is 'jdbc/Certification', so it being bound as 'java:jdbc/Certification', and I can verify this by using the JNDI viewer in the jmx-conxole. I presume that EJBs are able to access this namespace because it is copied for them on deployment, but when Quartz creates the new thread, that thread is not created by the container, so

doesn't get a copy of the java: namespace, and can access only the global namespace.

Am I missing somehting? Is there any way to access this namespace from other threads, or bind the datasource such that I can get at it? Any info is much appreciated.

Regards,

Colin



-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user




-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user





-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to