Hi Mark, I verified with the changes you made and it is working now. Thanks a lot. Is there any plan for next release in near future?
Regards, Chinoy -----Original Message----- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, October 04, 2016 12:27 PM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Unable to access Global JNDI Resource On 04/10/2016 04:54, Chinoy Gupta wrote: > Hi Mark, > > Thanks for the info. But I am afraid the custom loader directly > extends URLClassLoader. Actually my application is a generic web app > which can be deployed in any ApplciationServer like tomcat, JBoss, > etc. So I don't have any tomcat specific implementations. That is fine. It isn't the class hierarchy that matters, but the class loader hierarchy. I've made the fix to 9.0.x, 8.5.x, 8.0.x, 7.0.x and 6.0.x. As long as when you call getParent() recursively on your class loader the web application class loader is returned before null is returned then it will now work. Mark > > Regards, Chinoy > > -----Original Message----- From: Mark Thomas [mailto:ma...@apache.org] > Sent: Monday, October 03, 2016 6:16 PM To: > Tomcat Users List <users@tomcat.apache.org> Subject: Re: Unable to > access Global JNDI Resource > > On 30/09/2016 13:34, Chinoy Gupta wrote: >> Hi Mark, >> >> The following is added in server.xml: >> >> <GlobalNamingResources> <!-- Editable user database that can also be >> used by UserDatabaseRealm to authenticate users --> <Resource >> name="UserDatabase" auth="Container" >> type="org.apache.catalina.UserDatabase" description="User database >> that can be updated and saved" >> factory="org.apache.catalina.users.MemoryUserDatabaseFactory" >> pathname="conf/tomcat-users.xml" /> >> >> <Environment name="my/secret/password" value="JohnDoe" >> type="java.lang.String"/> </GlobalNamingResources> >> >> And the following is added in context.xml: >> >> <Environment name="my/local/test" value="local test" >> type="java.lang.String" override="false"/> <ResourceLink >> name="my/secret/password" global="my/secret/password" >> type="java.lang.String" /> >> >> If I try to get "my/local/test", it works and I get "local test". >> But if I try to get " my/secret/password", it returns NULL. > > This works for me with both 9.0.x and 8.0.x. > > Your previous posts mentioned a custom class loader. If the web > application class loader is not the thread context class loader then > the resource will not be visible. > > Is that custom class loader a child of the web application class > loader? If so, a fix for the next release should be fairly simple. > > Mark > > >> >> Regards, Chinoy >> >> -----Original Message----- From: Mark Thomas >> [mailto:ma...@apache.org] Sent: Friday, September 30, 2016 6:00 PM >> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Unable >> to access Global JNDI Resource >> >> On 30/09/2016 13:20, Chinoy Gupta wrote: >>> Hi Mark, >>> >>> This is my stacktrace: >>> >>> ResourceLinkFactory.validateGlobalResourceAccess(String) line: >>> 109 ResourceLinkFactory.getObjectInstance(Object, Name, Context, >>> Hashtable<?,?>) line: 142 NamingManager.getObjectInstance(Object, >>> Name, Context, Hashtable<?,?>) line: 321 NamingContext.lookup(Name, >>> boolean) line: 847 >>> NamingContext.lookup(Name) line: 158 NamingContext.lookup(Name, >>> boolean) line: 835 NamingContext.lookup(Name) line: 158 >>> NamingContext.lookup(Name, boolean) line: 835 >>> NamingContext.lookup(String) line: 172 >>> >>> validateGlobalResourceAccess function returns false and then >>> getObjectInstance returns NULL. >> >> You haven't defined a ResourceLink. >> >> Mark >> >>> >>> Regards, Chinoy >>> >>> >>> -----Original Message----- From: Mark Thomas >>> [mailto:ma...@apache.org] Sent: Friday, September 30, 2016 5:28 PM >>> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: >>> Unable to access Global JNDI Resource >>> >>> On 30/09/2016 12:50, Chinoy Gupta wrote: >>>> I am getting NULL instead of the resource's value. I debugged the >>>> tomcat code and figured out that in ResourceLinkFactory.java, >>>> before fetching the resource there is a validation based on current >>>> classloader. That validation fails and tomcat returns NULL. >>> >>> The above statement is not correct. If the class loader based >>> validation fails, Tomcat throws an exception. It does not return >>> null. >>> >>> Mark >>> >>>> >>>> -----Original Message----- From: Mark Thomas >>>> [mailto:ma...@apache.org] Sent: Friday, September 30, 2016 4:11 PM >>>> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: >>>> Unable to access Global JNDI Resource >>>> >>>> On 30/09/2016 11:30, Chinoy Gupta wrote: >>>>> Hi, >>>>> >>>>> I have a web application which runs on tomcat. In server.xml, I >>>>> provide some resources under "<GlobalNamingResources> section" and >>>>> then provide a ResourceLink to the same in context.xml. And then I >>>>> fetch that resource in my application. This was working properly >>>>> earlier but started breaking with 8.0.37. >>>> >>>> Define breaking. Ideally with a stack trace. >>>> >>>> Mark >>>> >>>> >>>>> I think the reason is the extra validation check introduced in >>>>> ResourceLinkFactory class. My application has its own classloader >>>>> and when I try to fetch the JNDI resource, the Thread's >>>>> classloader is my custom one rather than the default one. Because >>>>> of that validation fails and tomcat returns NULL. Is there a way >>>>> to fix this through configuration or any other means? >>>>> >>>>> Regards, Chinoy >>>>> >>>>> >>>> >>>> >>>> ------------------------------------------------------------------- >>>> - >>>> >>>> - >>>> >>>> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>>> >>>> ------------------------------------------------------------------- >>>> - >>>> >>>> - >>>> >>>> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>> >>> >>> -------------------------------------------------------------------- >>> - >>> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> -------------------------------------------------------------------- >>> - >>> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
