Re: Tomcat's data-source issue with Fork Join Tasks
Hi Mark, Many Thanks for your response. I was able to resolve this issue by writing the below code just before JNDI Look Up: Thread l_thread = Thread.currentThread(); l_thread.setContextClassLoader(this.getClass().getClassLoader()); initialContext = new InitialContext(); I have a questions based on the discussions on the thread link you provided: If this is something to do with ForkJoin Pool, then why it is happening only in Tomcat why not in other application servers as I mentioned in my initial post. Regards, Priyam On Sat, Mar 17, 2018 at 2:22 AM, Mark Thomas wrote: > On 16/03/18 12:06, Priyam Srivastava wrote: > > I have a scenario where we have to run some random number of independent > > tasks to load data from DB. So I am using Java's fork Join framework to > > create those task and then invoke them. > > See: > https://bz.apache.org/bugzilla/show_bug.cgi?id=60620 and the various > threads linked from there. > > Mark > > > > > > Each task opens its own connection using datasource and closes it. > > > > But in Tomcat, I am getting below error at line: > > > > initialContext = new InitialContext(); > > > > javax.naming.NoInitialContextException: Cannot instantiate class: > > org.apache.naming.java.javaURLContextFactory > > at javax.naming.spi.NamingManager.getInitialContext(Unknown Source) > > ~[?:1.8.0_161] > > at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source) > > ~[?:1.8.0_161] > > at javax.naming.InitialContext.init(Unknown Source) ~[?:1.8.0_161] > > at javax.naming.InitialContext.(Unknown Source) ~[?:1.8.0_161] > > at com.dummy.test.TestClass.compute(TestClass.java:71) [classes/:?] > > at java.util.concurrent.RecursiveAction.exec(Unknown Source) > [?:1.8.0_161] > > at java.util.concurrent.ForkJoinTask.doExec(Unknown Source) > [?:1.8.0_161] > > at java.util.concurrent.ForkJoinPool$WorkQueue.execLocalTasks(Unknown > > Source) [?:1.8.0_161] > > at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(Unknown Source) > > [?:1.8.0_161] > > at java.util.concurrent.ForkJoinPool.runWorker(Unknown Source) > [?:1.8.0_161] > > at java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source) > > [?:1.8.0_161] > > Caused by: java.lang.ClassNotFoundException: > > org.apache.naming.java.javaURLContextFactory > > > > This error seems to be coming only in Tomcat and when I run the same code > > in Wildfly/Glassfish or JBOSS EAP, everything works fine. > > > > On the other hand if I change my code and run these tasks using Thread > > instead of Fork Join framework, I don't face this issue in Tomcat. > > > > So why this error is coming in Tomcat only? > > > > Note: I am getting this error after deploying in Tomcat and hitting app > URL > > from Postman. The so called missing class is already there in > > jar catalina.jar present inside /lib > > > > Environment Details: > > > > Java Version: 1.8 > > Tomcat Version: 8.5, 9.0.6 > > OS: Windows 10 Pro 64 bit > > Database: Oracle 11g and MySQL 5.7 > > > > I have uploaded a dummy code to simulate this issue in Git. Please refer > to > > the readme.txt for full details there. > > > > Git URL: > > https://github.com/wambling/my-project.git > > > > Regards, > > Priyam > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Tomcat shutdown, webapp vs database pools
I have a war file that defines a context.xml file, some cxf based web services and a few other background tasks using quartz that are initialized in a servlet context listener. When tomcat shuts down, it appears that tomcat stops the database connection pool before the cxf services or the quartz tasks. This causes huge amounts of log output. I'm a bit unclear as to how to adjust/change the shutdown order of the database pool vs the servlet listeners. The web app's web.xml does declare a resource-ref element that points at the jndi lookup name, but perhaps the configuration is wrong. I have looked at https://tomcat.apache.org/tomcat-8.0-doc/jndi-resources- howto.html#JDBC_Data_Sources and my configuration appears to be correct, however something is still not quite right. What am I doing wrong?
Re: Request attributes
On 16/03/18 19:14, Mark A. Claassen wrote: > I recently discovered some request attributes that I was curious about. Are > these accurate across all connectors? Or are these the defaults for using > something like the NIO connector? > Specifically in my case, I am using the APR connector and openSSL. > > Example: > > > Attribute 'org.apache.tomcat.util.net.secure_protocol_version' = > 'TLSv1.2' > Attribute 'javax.servlet.request.key_size' = '256' > Attribute 'javax.servlet.request.cipher_suite' = > 'ECDHE-RSA-AES256-GCM-SHA384' If they are present, they will be correct. They are supported by all TLS connectors (so they should be present for all secure connections). Mark > > Thanks, > > Mark Claassen > Senior Software Engineer > > Donnell Systems, Inc. > 130 South Main Street > Leighton Plaza Suite 375 > South Bend, IN 46601 > E-mail: mailto:mclaas...@ocie.net > Voice: (574)232-3784 > Fax: (574)232-4014 > > Disclaimer: > The opinions provided herein do not necessarily state or reflect > those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and > assumes no legal liability or responsibility for the posting. > > > - > 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: Tomcat's data-source issue with Fork Join Tasks
On 16/03/18 12:06, Priyam Srivastava wrote: > I have a scenario where we have to run some random number of independent > tasks to load data from DB. So I am using Java's fork Join framework to > create those task and then invoke them. See: https://bz.apache.org/bugzilla/show_bug.cgi?id=60620 and the various threads linked from there. Mark > > Each task opens its own connection using datasource and closes it. > > But in Tomcat, I am getting below error at line: > > initialContext = new InitialContext(); > > javax.naming.NoInitialContextException: Cannot instantiate class: > org.apache.naming.java.javaURLContextFactory > at javax.naming.spi.NamingManager.getInitialContext(Unknown Source) > ~[?:1.8.0_161] > at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source) > ~[?:1.8.0_161] > at javax.naming.InitialContext.init(Unknown Source) ~[?:1.8.0_161] > at javax.naming.InitialContext.(Unknown Source) ~[?:1.8.0_161] > at com.dummy.test.TestClass.compute(TestClass.java:71) [classes/:?] > at java.util.concurrent.RecursiveAction.exec(Unknown Source) [?:1.8.0_161] > at java.util.concurrent.ForkJoinTask.doExec(Unknown Source) [?:1.8.0_161] > at java.util.concurrent.ForkJoinPool$WorkQueue.execLocalTasks(Unknown > Source) [?:1.8.0_161] > at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(Unknown Source) > [?:1.8.0_161] > at java.util.concurrent.ForkJoinPool.runWorker(Unknown Source) [?:1.8.0_161] > at java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source) > [?:1.8.0_161] > Caused by: java.lang.ClassNotFoundException: > org.apache.naming.java.javaURLContextFactory > > This error seems to be coming only in Tomcat and when I run the same code > in Wildfly/Glassfish or JBOSS EAP, everything works fine. > > On the other hand if I change my code and run these tasks using Thread > instead of Fork Join framework, I don't face this issue in Tomcat. > > So why this error is coming in Tomcat only? > > Note: I am getting this error after deploying in Tomcat and hitting app URL > from Postman. The so called missing class is already there in > jar catalina.jar present inside /lib > > Environment Details: > > Java Version: 1.8 > Tomcat Version: 8.5, 9.0.6 > OS: Windows 10 Pro 64 bit > Database: Oracle 11g and MySQL 5.7 > > I have uploaded a dummy code to simulate this issue in Git. Please refer to > the readme.txt for full details there. > > Git URL: > https://github.com/wambling/my-project.git > > Regards, > Priyam > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Request attributes
I recently discovered some request attributes that I was curious about. Are these accurate across all connectors? Or are these the defaults for using something like the NIO connector? Specifically in my case, I am using the APR connector and openSSL. Example: Attribute 'org.apache.tomcat.util.net.secure_protocol_version' = 'TLSv1.2' Attribute 'javax.servlet.request.key_size' = '256' Attribute 'javax.servlet.request.cipher_suite' = 'ECDHE-RSA-AES256-GCM-SHA384' Thanks, Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:mclaas...@ocie.net Voice: (574)232-3784 Fax: (574)232-4014 Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Binding a non root user to port 443
Thank You Olaf === Thank You; Chris Cheltenham Technology Services The School District of Philadelphia Work # 215-400-5025 Cell # 215-301-6571 - Original Message - From: "Olaf Kock" To: "users" Sent: Friday, March 16, 2018 7:21:26 AM Subject: Re: Binding a non root user to port 443 Chris, On 15.03.2018 13:34, Cheltenham, Chris wrote: > Andre, > > You probably missed where I had mentioned the infrastructure group poo poo'd > altering iptables for whatever reason. > > Here is what I think are my 5 best choices for running tomcat as a non root > user on a privileged port. > > 1) redirect 443 to 8443 on the load balancer. VIP side. > > 2) iptables > > 3) jsvc > > 4) authbind > > 5) set cap > > I do NOT have control of the VIP so I can only make suggestions based on > what I have control of. I don't understand. I always make suggestions for areas that I don't have control of. It'd be frightening if I didn't, because that would mean that I'd control too much. IMHO 1 is the best point: The loadbalancer balances something anyway - you'd just document the application it should balance and the ports it should be available under. You probably can't tell them they need to bind another port than 443 /on their frontend/, but you should certainly be able to tell them where your application lives that they should connect to in the backend. That's a configuration they'd have to make anyway and I hope they'd not be opposed to entering a port number. > Therefore, the latter three are what I am looking into. > > I do not like set cap because it opens up ALL the privileged ports to a > binary , such as java or http. > Authbind is an install of a potentially buggy or unsecure software. another reason for 1... > I am not really sure how my post warranted so much attention but I > appreciate it. well, you posted a question, gave the background - that's what this list is for. Olaf - 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
Tomcat's data-source issue with Fork Join Tasks
I have a scenario where we have to run some random number of independent tasks to load data from DB. So I am using Java's fork Join framework to create those task and then invoke them. Each task opens its own connection using datasource and closes it. But in Tomcat, I am getting below error at line: initialContext = new InitialContext(); javax.naming.NoInitialContextException: Cannot instantiate class: org.apache.naming.java.javaURLContextFactory at javax.naming.spi.NamingManager.getInitialContext(Unknown Source) ~[?:1.8.0_161] at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source) ~[?:1.8.0_161] at javax.naming.InitialContext.init(Unknown Source) ~[?:1.8.0_161] at javax.naming.InitialContext.(Unknown Source) ~[?:1.8.0_161] at com.dummy.test.TestClass.compute(TestClass.java:71) [classes/:?] at java.util.concurrent.RecursiveAction.exec(Unknown Source) [?:1.8.0_161] at java.util.concurrent.ForkJoinTask.doExec(Unknown Source) [?:1.8.0_161] at java.util.concurrent.ForkJoinPool$WorkQueue.execLocalTasks(Unknown Source) [?:1.8.0_161] at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(Unknown Source) [?:1.8.0_161] at java.util.concurrent.ForkJoinPool.runWorker(Unknown Source) [?:1.8.0_161] at java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source) [?:1.8.0_161] Caused by: java.lang.ClassNotFoundException: org.apache.naming.java.javaURLContextFactory This error seems to be coming only in Tomcat and when I run the same code in Wildfly/Glassfish or JBOSS EAP, everything works fine. On the other hand if I change my code and run these tasks using Thread instead of Fork Join framework, I don't face this issue in Tomcat. So why this error is coming in Tomcat only? Note: I am getting this error after deploying in Tomcat and hitting app URL from Postman. The so called missing class is already there in jar catalina.jar present inside /lib Environment Details: Java Version: 1.8 Tomcat Version: 8.5, 9.0.6 OS: Windows 10 Pro 64 bit Database: Oracle 11g and MySQL 5.7 I have uploaded a dummy code to simulate this issue in Git. Please refer to the readme.txt for full details there. Git URL: https://github.com/wambling/my-project.git Regards, Priyam
Re: Binding a non root user to port 443
Chris, On 15.03.2018 13:34, Cheltenham, Chris wrote: Andre, You probably missed where I had mentioned the infrastructure group poo poo'd altering iptables for whatever reason. Here is what I think are my 5 best choices for running tomcat as a non root user on a privileged port. 1) redirect 443 to 8443 on the load balancer. VIP side. 2) iptables 3) jsvc 4) authbind 5) set cap I do NOT have control of the VIP so I can only make suggestions based on what I have control of. I don't understand. I always make suggestions for areas that I don't have control of. It'd be frightening if I didn't, because that would mean that I'd control too much. IMHO 1 is the best point: The loadbalancer balances something anyway - you'd just document the application it should balance and the ports it should be available under. You probably can't tell them they need to bind another port than 443 /on their frontend/, but you should certainly be able to tell them where your application lives that they should connect to in the backend. That's a configuration they'd have to make anyway and I hope they'd not be opposed to entering a port number. Therefore, the latter three are what I am looking into. I do not like set cap because it opens up ALL the privileged ports to a binary , such as java or http. Authbind is an install of a potentially buggy or unsecure software. another reason for 1... I am not really sure how my post warranted so much attention but I appreciate it. well, you posted a question, gave the background - that's what this list is for. Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
