apache-tomcat-9.0.70 >> JNDI look up fails in a different thread context class loader !!
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
Re: apache-tomcat-9.0.70 >> JNDI look up fails in a different thread context class loader !!
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 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
Re: apache-tomcat-9.0.70 >> JNDI look up fails in a different thread context class loader !!
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. 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 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 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
Re: apache-tomcat-9.0.70 >> JNDI look up fails in a different thread context class loader !!
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 On Monday, December 12, 2022 at 09:49:50 PM GMT+5:30, Mark Thomas 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 > 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 > 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
Re: apache-tomcat-9.0.70 >> JNDI look up fails in a different thread context class loader !!
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 On Tuesday, December 13, 2022 at 02:06:06 PM GMT+5:30, dineshk 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 On Monday, December 12, 2022 at 09:49:50 PM GMT+5:30, Mark Thomas 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 > 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 > 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
JTA transactions support in Tomcat 9 !!
Hi , Could anybody provide the information if JTA transactions are supported or not in Tomcat 9.X. If not , is there any way to achieve the JTA transactions ? We are using hibernate for our persistence layer. RegardsDinesh
How to do a JNDI look up in a different thread
Hi , Thanks for your prompt reply. But the below suggestion "Set the thread context class loader to the web application class loader." will not work in our case as we have our own custom class loader to load the hibernate resources like e.g. hbm files , Entity classes and all. Below is the code snippet : Configuration cfg = new Configuration(); cfg.addInputStream(inputStrm); // This is the input stream of the .hbm file which is in our database and Entity class in this xml to be loaded by our custom class loader only as our Entity classes in the database. cfg.buildMappings(); cfg.buildSessionFactory(); // It fails in JNDI look up if I dont set the web application class loader as context class loader. so ideally if I set my custom class loader as context class loader I am able to load my .hbm files and corresponding Entity classes. If I set the context class loader to wep application class loader my JNDI look-up works but I get class not found exception for my Entity classes referred in the .hbm files. Any idea to solve this? RegardsDinesh From: Mark Thomas Sent: 29-07-2016 16:19 To: Tomcat Users List Subject: Re: How to do a JNDI look up in a different thread On 29/07/2016 11:41, Khandelwal, Dinesh wrote: > > Hi, > > As part of my project , we maintain multiple Hibernate session factoriesand > as building these session factories take lot of time which causes server > totake more time in start-up , we are creating these session factories > indifferent threads Each thread creating one factory but when > theconfiguration.buildsessionFactory() [Hibernate internally does JNDI look > upwhich fails]API is called it throws Unable to lookup JNDI > name[java:/comp/env/BFDS]. > > Please note that I am using Tomcat 7 and I have tried multiple JNDI > namecombinations e.g. java: /BFDS , java:global/BFDS , BFDS etc. but nothing > works.Same code works in JBOSS 7 and Websphere. > > Please suggest something. Set the thread context class loader to the web application class loader. Mark
Re: Java EE -> Jakarta migration (urgent)
Mark , Really appreciate your prompt response. One more question, We are trying out Eclipse Transformer to change the third part jars from javax to Jakarta but it doesn’t work. Would you be able to help in this regard ? I was using transformer cli for this . We would need a tool to do the impact analysis for third party jars and our application itself where all we do use javax which require a migration to Jakarta. ThanksDinesh Sent from Yahoo Mail for iPhone On Sunday, December 15, 2024, 12:01 AM, Christopher Schultz wrote: Dinesh, On 12/14/24 1:36 AM, dineshk wrote: > We are currently using Tomcat 9.0.70 . I would like to know what is > EOL (stretched) for this version ? Secondly , we would like to know > if moving to higher version of Tomcat e.g. 10.X would force us to > migrate to Jakarta specs instead of using the Java EE specs ? > Currently , we could not move to Jakarta specs for next 2-3 years , > do we have any back word compatibility w.r.t. to Java EE specs with > higher versions of Tomcat ? I've had pretty good results with a basic servlet-based application and Tomcat's auto-migration capabilities. I have not run it in production, though. I would encourage you to check-out your application in a development/testing environment with Tomcat 10.1 (please read the Tomcat migration documentation) and see if it works for you. If it works, then you have fine-grained control over how fast you migrate from Java EE -> Jakarta EE. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Java EE -> Jakarta migration
Any help would be really appreciated. Regards Dinesh Sent from Yahoo Mail for iPhone On Sunday, December 15, 2024, 12:06 PM, dineshk wrote: Mark , Really appreciate your prompt response. One more question, We are trying out Eclipse Transformer to change the third part jars from javax to Jakarta but it doesn’t work. Would you be able to help in this regard ? I was using transformer cli for this . We would need a tool to do the impact analysis for third party jars and our application itself where all we do use javax which require a migration to Jakarta. ThanksDinesh Sent from Yahoo Mail for iPhone On Sunday, December 15, 2024, 12:01 AM, Christopher Schultz wrote: Dinesh, On 12/14/24 1:36 AM, dineshk wrote: > We are currently using Tomcat 9.0.70 . I would like to know what is > EOL (stretched) for this version ? Secondly , we would like to know > if moving to higher version of Tomcat e.g. 10.X would force us to > migrate to Jakarta specs instead of using the Java EE specs ? > Currently , we could not move to Jakarta specs for next 2-3 years , > do we have any back word compatibility w.r.t. to Java EE specs with > higher versions of Tomcat ? I've had pretty good results with a basic servlet-based application and Tomcat's auto-migration capabilities. I have not run it in production, though. I would encourage you to check-out your application in a development/testing environment with Tomcat 10.1 (please read the Tomcat migration documentation) and see if it works for you. If it works, then you have fine-grained control over how fast you migrate from Java EE -> Jakarta EE. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Java EE -> Jakarta migration
I understand. Thanks. Sent from Yahoo Mail for iPhone On Wednesday, December 18, 2024, 10:26 PM, Christopher Schultz wrote: Dinesh, On 12/18/24 11:42 AM, dineshk wrote: > Any help would be really appreciated. You haven't provided much information so far. This is what you said (paraphrasing): 1. I'm using a tool unrelated to Tomcat for something 2. It "doesn't work" 3. Please help We are not in the habit of supporting tools from other sources. You haven't given any details about (a) what you tried (b) what happened when you tried it and (c) what you expected instead of what happened. If you want any further responses on this list, you're going to have to provide more detail. And again, remember that we really don't support the Eclipse Transformer. If you want help with that, you should talk to Eclipse. If you want to use Tomcat's Migration Tool, we can probably be of more help. -chris > On Sunday, December 15, 2024, 12:06 PM, dineshk > wrote: > > Mark , Really appreciate your prompt response. One more question, We are > trying out Eclipse Transformer to change the third part jars from javax to > Jakarta but it doesn’t work. Would you be able to help in this regard ? I was > using transformer cli for this . We would need a tool to do the impact > analysis for third party jars and our application itself where all we do use > javax which require a migration to Jakarta. > ThanksDinesh > > > Sent from Yahoo Mail for iPhone > > > On Sunday, December 15, 2024, 12:01 AM, Christopher Schultz > wrote: > > Dinesh, > > On 12/14/24 1:36 AM, dineshk wrote: >> We are currently using Tomcat 9.0.70 . I would like to know what is >> EOL (stretched) for this version ? Secondly , we would like to know >> if moving to higher version of Tomcat e.g. 10.X would force us to >> migrate to Jakarta specs instead of using the Java EE specs ? >> Currently , we could not move to Jakarta specs for next 2-3 years , >> do we have any back word compatibility w.r.t. to Java EE specs with >> higher versions of Tomcat ? > I've had pretty good results with a basic servlet-based application and > Tomcat's auto-migration capabilities. > > I have not run it in production, though. > > I would encourage you to check-out your application in a > development/testing environment with Tomcat 10.1 (please read the Tomcat > migration documentation) and see if it works for you. If it works, then > you have fine-grained control over how fast you migrate from Java EE -> > Jakarta EE. > > -chris > > > - > 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
Java EE -> Jakarta migration (urgent)
Hi Team, We are currently using Tomcat 9.0.70 . I would like to know what is EOL (stretched) for this version ? Secondly , we would like to know if moving to higher version of Tomcat e.g. 10.X would force us to migrate to Jakarta specs instead of using the Java EE specs ? Currently , we could not move to Jakarta specs for next 2-3 years , do we have any back word compatibility w.r.t. to Java EE specs with higher versions of Tomcat ? RegardsDinesh
Re: The future of Tomcat 9
Hi , Any expected time horizon from now to support the Java EE with 9.x.x ? Any possibility on how many years from now , it would be supported? Dinesh Sent from Yahoo Mail for iPhone On Tuesday, February 25, 2025, 5:06 PM, Michael Osipov wrote: On 2025/02/25 10:45:53 Mark Thomas wrote: > All, > > Tomcat 9 is the last major Tomcat version supporting Java EE. Therefore, > the Tomcat community intends to provide support for Tomcat 9 beyond the > 10 years for which major Tomcat versions are typically supported. > > Extended support will be provided via a new 9.1.x branch that will be > started when 9.0.x reaches end of support. The APR/Native Connector will > not be available in Tomcat 9.1.x. > > The deprecation notice for the APR/Native connector will be updated for > the next 9.0.x release to indicate that it will be removed in 9.1.x > onwards in addition to the current statement that it has been removed in > 10.1.x onwards. > > Support for NIO+OpenSSL and NIO2+OpenSSL will continue in Tomcat 9.1.x > via Tomcat Native 2.x. > > Back-ports of security fixes, bug fixes and new features will continue > for 9.1.x as they have done for 9.0.x. > > End of support for Tomcat 9.0.x is expected *no earlier than* 31 March 2027. > > End of support for Tomcat 9.1.x has not been determined. At least 12 > months notice will be provided for 9.1.x end of support. If that is the case one should modify libtcnative not to require APR at build time at all. Please note that would also kill UDS support on 9.x when run on < Java 17. Please sharply review all APR feaitures which are *not* available with NIO2 and document appropriately. If I am wrong, let me know! Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 9.0.x support Java 17 ?
Hi Team, Could anybody clarify on if we could use Java 17 with Java EE specs with tomcat 9.0.x ? RegardsDinesh Sent from Yahoo Mail for iPhone
