Ok. Thanks a lot Mark. Regards, Chinoy
-----Original Message----- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, October 04, 2016 2:37 PM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Unable to access Global JNDI Resource On 04/10/2016 09:33, Chinoy Gupta wrote: > 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? I typically do releases monthly, starting the release process at the beginning of the month. I like to clear all the open bugs first so exactly when the release starts depends on how long that takes. Hopefully, I should be in a position to tag and start the actual release later this week. Mark > > 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 > --------------------------------------------------------------------- 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
