----- Original Message ----- From: "Ian Darwin" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Arshad Mahmood" <[EMAIL PROTECTED]> 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 need > > to look at to trace this problem. Alternatively, if somebody can confirm > > that the JNDI-Howto example for a custom beanFactory works correctly in 4.1 > > (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 java:comp/env/bean > 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" context. 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 ? Regards. > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
