Arshad Mahmood wrote: > ----- 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 ?
I'm not sure I understand very well, so I'll assume it's a problem with the links. The global resources defined in server.xml are not accessible by default in the web applications (because you may want to restrict some to specific webapps, etc). So you have to link them using a ResourceLink element. You can also define the resource links in the default context so that all your contexts in your host or engine will have the link, instead of having to define it in each one. The admin webapp will have full support for this shortly (I reckon that configuring this is *hard* at the moment). Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
