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