On Tue, Dec 13, 2022 at 9:36 AM dineshk <dinesh143...@yahoo.com.invalid> wrote: > > > Hi Mark, > I guess you are right , I tried with simple web application and JNDI look up > fails in both tomcat 7.x and 9.x if the current thread context class loader > is changed but strangely when we deploy our application which uses hibernate > (4.3.11) , it does work in tomcat 7.x but not in 9.x. Not sure what is > causing this to work in tomcat 7.x and not in tomcat 9.x. > Secondly , is this implementation "JNDI binding with context class loader" > tomcat specific as it works in both JBoss EAP and IBM WebSphere , any inputs > why JNDI look up works in these application servers and not in tomcat? > RegardsDinesh
Tomcat only uses the context class loader because it works. The current thread can also be used, you can write a valve that binds it using this call: https://github.com/apache/tomcat/blob/main/java/org/apache/naming/ContextBindings.java#L138 It is used during startup here, as an example: https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/core/StandardContext.java#L5740 Rémy > On Monday, December 12, 2022 at 09:49:50 PM GMT+5:30, Mark Thomas > <ma...@apache.org> wrote: > > On 12/12/2022 16:07, dineshk wrote: > > > > Hi Mark, > > We could reproduce this issue very easily with simple java program as well. > > Just before doing the JNDI look up , set any custom class loader in the > > current thread as context class loader , this will fail the JNDI look up > > where as if we don't set any custom class loader , it works fine. > > That is the expected behaviour. > > What is curious is how this ever worked for Tomcat 7 given that Tomcat > has used class loader binding with JNDI look-ups 4.1.x (and possible > earlier). > > If you can provide a simple test case that demonstrates the look-up > working in Tomcat 7 and failing in Tomcat 9 I'll take a look. > > It should be possible to demonstrate the issue with a simple web > application that defines an environment entry in web.xml and then looks > it up in a JSP. > > Mark > > > > Let me know , if we have any solution for this. > > RegardsDinesh > > On Monday, December 12, 2022 at 07:01:24 PM GMT+5:30, dineshk > > <dinesh143...@yahoo.com.invalid> wrote: > > > > > > Hi Mark , > > I don't think we should suspect the custom class loader here as its very > > old code and works fine across all application servers e.g. IBM WebSphere > > and JBoss EAP 7.X. The custom class loader is required as our java classes > > are part of the Database which we need to load and hence required. > > It works in Tomcat 7.X as well but when we moved to 8.x or 9.x in both it > > failed. > > RegardsDinesh > > On Monday, December 12, 2022 at 06:33:56 PM GMT+5:30, Mark Thomas > > <ma...@apache.org> wrote: > > > > The JNDI binding code is unchanged (apart from the removal of some > > deprecated methods) between 7.0.x and 9.0.x (and beyond that range). I > > think you'll need to do some debugging to figure out exactly why this > > isn't working but I suspect the custom class loader is at least a part > > of the reason. > > > > There may be better options that using a custom class loader. What are > > the requirements that mean you need to use one? > > > > Mark > > > > > > On 12/12/2022 12:42, dineshk wrote: > >> Hi , > >> We are trying to deploy our application on tomcat 9.0.70. Before the > >> hibernate bootstraps in our application , we do change the "Current Thread > >> Context Class Loader " in the running thread to our "Custom class loader" > >> which is required. > >> Changing the "Current Thread Context Class Loader " fails the JNDI look > >> up for data source done by hibernate. > >> if the "Current Thread Context Class Loader " is not changed than JNDI > >> look up works. > >> We have also deployed the same application with the same configurations on > >> apache-tomcat-7.0.57 and it works fine there , no issues with JNDI look up. > >> We have not faced this issues on IBM WebSphere and JBoss EAP but > >> apache-tomcat-7.0.57 onwards. > >> It will be great help if we could get a solution for this. > >> > >> RegardsDinesh > > > > --------------------------------------------------------------------- > > 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
