----- Original Message ----- From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Thursday, June 13, 2002 5:33 PM Subject: Re: JNDI with a custom factory not working
> 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 Remy, Thanks for you response. I didn't make myself very clear, I'll try again. The Problem ========= In the server.xml have defined a global resourcce under the name "rohas/filecache". The resource params defines a "factory" along with other attributes. In my context I have defined a "ResourceLink" that maps to the global name (I have given them both the same name, I assume that doesn't make a difference). In the web.xml for my application I have defined a "resource-ref" that points to this resource. When I try and access the resource via an InitialContext in the "init" function of my servlet, I get a NamingException from org.apache.naming.factory.ResourceFactory.getObjectInstance. To look into the problem I put some debug into the "org.apache.naming.NamingContext" class in the lookup method. I noticed that when this class was called a few times, the "name" member varied between "//Standalone/myapp" amd "//Standalone/localhost/myapp", etc. I was a bit surprised because I thought when I asked "java:comp/env" I would always get the same "NamingContext" and not different ones. I then traced the code through "org.apache.naming.java.javaURLContextFactory", which in turn uses "org.apache.naming.SelectorContext". The SelectorConext class uses "getBoundContext" to retrieve the appropriate NamingContext to which it delegated the lookup/bind/unbind, etc. The getBoundContext then uses ContextBindings.getContext to get the context (if doesn't exist then it creates a new one). *** IMPORTANT *** The member variable initialContext is overriden inside the "if" of this function (is this intentional). ContextBindings appears to return a NamingContext based on the class loader currenty in used. Hence the multiple contexts and why the name I am looking for doesn't appear in the context which I am using for lookup. Regards, Arshad > -- > 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]>
