tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arshad Mahmood" <>
Subject Re: JNDI with a custom factory not working
Date Thu, 13 Jun 2002 12:27:10 GMT

----- Original Message -----
From: "Ian Darwin" <>
To: "Tomcat Developers List" <>; "Arshad
Mahmood" <>
Sent: Thursday, June 13, 2002 1:48 AM
Subject: Re: JNDI with a custom factory not working

> On June 12, 2002 07:45 am, Arshad Mahmood wrote:
> > I am having a problem trying to use a custom factory with JNDI. I get an
> > exception froom org.apache.naming.factory.ResourceFactory. I have added
> > debug and it appears that my "factory" parameter is not being picked up
> > from the server.xml.
> >
> > Can somebody familiar with the naming code point me to the classes I
> > to look at to trace this problem. Alternatively, if somebody can confirm
> > that the JNDI-Howto example for a custom beanFactory works correctly in
> > (I have tried it and it doesn't) then I will look at my configuration
> > again.
> Doesn't work for me either. Inserting a listBindings() call for
> reveals nothing bound there.

I have traced the problem a little further and I think I know what the
problem is but I haven't got a clue how to fix it.

Basically, it appears that a different NamingContext is created per
thread/class loader. Let's assume that you have a tomcat instance called
"Standalone", a virtual host "localhost" and a context "myapp".

If you define any JNDI resources in the server.xml, then they appear to be
put into a naming context call "//Standalone/myapp". Your resource
definitions in the web.xml go into the "//Standalone/localhost/myapp"

If you attempt to read the resources from your servlet then the
"//Standalone/localhost/myapp" context is used, this is ok for jdbc, etc
because the factory is hardwired into the naming code. But if you have
defined a custom factory then no definition exists in this context for that
(because it's been put into the "//Standalone/myapp" context). I believe
this also goes for any parameters that you have defined.

The fix would appear to be for Tomcat to put the resources under the virtual
in the first place for those defined in the server.xml. There is still an
issue though for the "global resources" as I am not sure you can link to
them because they are under a different naming context.

This is an initial investigation so my analysis may be FLAWED.

Remy, does this explanation of how the naming contexts are defined/used make
sense ?


> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message