tomcat server mode and client mode
Hi all, I have a basic doubt in tomcat configuration . Though Iam not new java development Iam new to tomcat configuration. can any one can tellme about diff between tomcat's server mode and client mode. Or atleast give some pointers to the related resources thank you regards Srikanth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat SSL Cipher Configuration
Jojo Paderes wrote: Hi, I'm looking for some decent documentation and technical reference on how to configure Tomcat's SSL cipher. Say for example I want Tomcat to support a specific SSL cipher suite like Triple DES. Hope someone has done something like this already. I'm using Tomcat 5.5 btw. Thanks, Jojo I may be mistaken here, but I don't think Tomcat does provide config options for the actual ciphers used - at least not in server.xml. It relies on the ciphers provided by the JDK. I think those can be configured in the policy file. This might be useful for you: http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html Edmund - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mysterious error with Tomcat 5.5.9 and Log4J
Hi! I posted this thread on friday evening, not a good idea, I think. Because the problem is still there, I will have a second try... I encountered a very mysterious problem using log4j with tomcat 5.5.9. In order to use log4j i have the file commons-logging.properties in my WEB-INF/classes directory with the following content: orr.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JCategory Log I did not notice my mistake in writing orr.apache instead of org.apache. I used log4j.properties to configure log4j to my needs. When I deployed ma web-app with these files, tomcat did NOT complain about it. Everything worked fine. Then I wrote another web-app, now without the mistake in writing, and Tomcat complained with the following error: SCHWERWIEGEND: Error deploying web application archive BuildManagerWA.war java.lang.NoSuchMethodError: org.apache.log4j.Category.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljav a/lang/Object;Ljava/lang/Throwable;)V at org.apache.commons.logging.impl.Log4JCategoryLog.error(Log4JCategoryLog.java :149) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java: 3673) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4104) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:7 59) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:788) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:498) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanSer verInterceptor.java:221) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanSer verInterceptor.java:120) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanS erverInterceptor.java:84) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanSer verInterceptor.java:120) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanSer verInterceptor.java:120) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(Cont extClassLoaderMBeanServerInterceptor.java:203) at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1043) at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1377) at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:636) at org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java:423) at javax.servlet.http.HttpServlet.service(HttpServlet.java:712) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:178) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:482) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126 ) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105 ) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne ction(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav a:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWo rkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:684) at java.lang.Thread.run(Unknown Source) What is going on there? If I change org.apache into orr.apache everything works fine again! Has anybody an idea? Peter -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: Tomcat security realms question
Thanks Mark. I agree, but they are the security people and I have to at least try to comply. Do you think it would be feasible for us to change the org.apache.catalina.authenticator.AuthenticatorBase for Tomcat 4.1.18 to change the session ID post logging in? We'd obviously have to recompile tomcat after doing so. Are there any hidden gotchas you can think of with doing that? Thanks Alex. -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, 18 July 2005 2:50 AM To: Tomcat Users List Subject: Re: Tomcat security realms question The problem you describe is true of any session tracking system running over http. The solution is to use https. However, here's a question to fire back at your security team: If you are worried about an attacker physically looking at a session ID on a user's screen, what about if they decide to install a keyboard logger (physical or software) whilst they have access to the user's machine? In fact, I can think of a whole bunch of other things I could do as well that would be equally or more damaging than hijacking a single session. Fundamentally, if an attacker has physical access to a machine it is game over - they have won. Your security team knows the threat model for you situation far better than I do but it sounds to me like they are trying too hard in one area and have missed a bunch of other threats. Mark Akoulov, Alexandre [IT] wrote: Hi all I have a problem that's been raised by my security team to do with using Tomcat JDBCRealms. We're using such realms to protect restricted resources. We also have a custom login form. The steps Tomcat seems to follow when using such a setup is: 1. Check to see if the user is logged in with access to the restricted resource. 2. If they aren't, forward them to the login page and create an HTTPSession to keep track of that user. 3. Once they've logged in, add the authentication system to the HTTPSession created in step 2 to hold that info and forward them to the resource. 4. Continue using the same HTTPSession to maintain state. The problem my security team has with this is that someone could potentially steal the users HTTPSession ID before they've logged in, as this is created in the login screen. e.g. the user is forwarded to the login screen, then goes to make themselves a cup of coffee. A hacker goes to their computer and writes down the session ID. The user comes back and logs in, and the hacker pretends to be them from another computer. My question is: how can I avoid this situation and keep the security guys happy? Is it possible to have the session ID held by the browser (in JSessionID) change post-login (ie make tomcat invalidate the current session and create a new session after the user has been successfully authenticated)? Thanks for your help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Mysterious error with Tomcat 5.5.9 and Log4J
Hi! I searched the internet and found a couple of people with the same problem, but no explanation. Seemingly my error with orr.apache... works, but it is not really satisfying. One hint I found was that Log4JCategoryLog is deprecated, and Log4JLogger should be used instead. So change your commons-logging.properties to org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger which works with org.apache very well. A mysterious error... Peter -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Montag, 18. Juli 2005 09:30 An: tomcat-user@jakarta.apache.org Betreff: Mysterious error with Tomcat 5.5.9 and Log4J Hi! I posted this thread on friday evening, not a good idea, I think. Because the problem is still there, I will have a second try... I encountered a very mysterious problem using log4j with tomcat 5.5.9. In order to use log4j i have the file commons-logging.properties in my WEB-INF/classes directory with the following content: orr.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JCategory Log I did not notice my mistake in writing orr.apache instead of org.apache. I used log4j.properties to configure log4j to my needs. When I deployed ma web-app with these files, tomcat did NOT complain about it. Everything worked fine. Then I wrote another web-app, now without the mistake in writing, and Tomcat complained with the following error: SCHWERWIEGEND: Error deploying web application archive BuildManagerWA.war java.lang.NoSuchMethodError: org.apache.log4j.Category.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljav a/lang/Object;Ljava/lang/Throwable;)V at org.apache.commons.logging.impl.Log4JCategoryLog.error(Log4JCategoryLog.java :149) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java: 3673) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4104) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:7 59) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:788) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:498) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanSer verInterceptor.java:221) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanSer verInterceptor.java:120) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanS erverInterceptor.java:84) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanSer verInterceptor.java:120) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanSer verInterceptor.java:120) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(Cont extClassLoaderMBeanServerInterceptor.java:203) at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1043) at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1377) at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:636) at org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java:423) at javax.servlet.http.HttpServlet.service(HttpServlet.java:712) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:178) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:482) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126 ) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105 ) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne ction(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav a:527) at
Preprocessing JSP pages
Perhaps you can help me. We have an application which used Tomcat v4, which I'm migrating to use 5.5.9. We made some changes to the Tomcat source to allow JSP pages to be preprocessed, so that we could strip out/add in certain code branches at runtime based on configuration. We did this by making changes to e.g. ParserController.java. In retrospect this wasn't a great idea, because it meant we had to ship our own version of Tomcat, so we're looking at removing these changes so that we can use a vanilla version of Tomcat. I can roll my own different version of this preprocessing, e.g. as part of starting Tomcat. But I'm wondering whether there's a way you're supposed to do something like this? E.g. is there a way you can register something to get invoked when Tomcat is loading JSP, without having to hack the code to do so? Thanks for any help, Edward Hibbert.
apache jk_mod connecor to tomcat; threads not being released
Hi folks, Pretty new to the apache/tomcat world so please forgive any naivety. We have an apache instance on one server that connects to a tomcat instance on another using jk_mod The problem is that no matter what values I use for the worker.properties config the threads on the tomcat side are never recycled/dropped/released. Consequently the number of threads gradually climbs to the value set in the server.xml file by maxProcessors at which point no new requests are met. A bounce of either the tomcat or the apache process is all that seems to reset it. I have put on trace level logging but found nothing useful in the JK log file. Has anyone encountered this before and I am just being a bit dense and missing something ? Please get back to me if you need more details. Very grateful for any assistance - some version numbers and worked property values below. Cheers Mark Apache 1.3 jk_mod 1.2.10 Tomcat 5.0.24 java j2sdk1.4.2_08 JkWorkerProperty worker.funds.type=ajp13 JkWorkerProperty worker.funds.host=xxx.xxx.xx.com JkWorkerProperty worker.funds.port=8203 JkWorkerProperty worker.funds.lbfactor=50 JkWorkerProperty worker.funds.cachesize=1 JkWorkerProperty worker.funds.cache_timeout=60 JkWorkerProperty worker.funds.socket_keepalive=0 JkWorkerProperty worker.funds.socket_timeout=5 JkWorkerProperty worker.funds.recycle_timeout=30 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Preprocessing JSP pages
How about integrating it in your ant build script? This changes your preprocessing from runtime to compile time. Bernhard -Ursprüngliche Nachricht- Von: Edward Hibbert [mailto:[EMAIL PROTECTED] Gesendet: Montag, 18. Juli 2005 11:32 An: tomcat-user@jakarta.apache.org Betreff: Preprocessing JSP pages Perhaps you can help me. We have an application which used Tomcat v4, which I'm migrating to use 5.5.9. We made some changes to the Tomcat source to allow JSP pages to be preprocessed, so that we could strip out/add in certain code branches at runtime based on configuration. We did this by making changes to e.g. ParserController.java. In retrospect this wasn't a great idea, because it meant we had to ship our own version of Tomcat, so we're looking at removing these changes so that we can use a vanilla version of Tomcat. I can roll my own different version of this preprocessing, e.g. as part of starting Tomcat. But I'm wondering whether there's a way you're supposed to do something like this? E.g. is there a way you can register something to get invoked when Tomcat is loading JSP, without having to hack the code to do so? Thanks for any help, Edward Hibbert. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preprocessing JSP pages
Our changes are things like diagnostic trace/logs, which we can't have permanently switched on for performance reasons. We might want to switch them on, occasionally, at a customer site. Indeed, we don't want to have them permanently present in the JSP at all (i.e. convert the pre-processing into a run-time check), also for performance reasons. That was the original motivation for making this stuff pre-processed. Edward. -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: 18 July 2005 10:58 To: 'Tomcat Users List' Subject: AW: Preprocessing JSP pages How about integrating it in your ant build script? This changes your preprocessing from runtime to compile time. Bernhard -Ursprüngliche Nachricht- Von: Edward Hibbert [mailto:[EMAIL PROTECTED] Gesendet: Montag, 18. Juli 2005 11:32 An: tomcat-user@jakarta.apache.org Betreff: Preprocessing JSP pages Perhaps you can help me. We have an application which used Tomcat v4, which I'm migrating to use 5.5.9. We made some changes to the Tomcat source to allow JSP pages to be preprocessed, so that we could strip out/add in certain code branches at runtime based on configuration. We did this by making changes to e.g. ParserController.java. In retrospect this wasn't a great idea, because it meant we had to ship our own version of Tomcat, so we're looking at removing these changes so that we can use a vanilla version of Tomcat. I can roll my own different version of this preprocessing, e.g. as part of starting Tomcat. But I'm wondering whether there's a way you're supposed to do something like this? E.g. is there a way you can register something to get invoked when Tomcat is loading JSP, without having to hack the code to do so? Thanks for any help, Edward Hibbert. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preprocessing JSP pages
From: Edward Hibbert [mailto:[EMAIL PROTECTED] Indeed, we don't want to have them permanently present in the JSP at all (i.e. convert the pre-processing into a run-time check), also for performance reasons. That was the original motivation for making this stuff pre-processed. If you haven't benchmarked the effect on performance of leaving the switches in the code, you might like to look at the log4j site, where there are benchmarks on log4j. It's illuminating. - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preprocessing JSP pages
Have you considered using the assertion facility in the Java 5.0 compiler? Daron. -Original Message- From: Edward Hibbert [mailto:[EMAIL PROTECTED] Sent: Monday, 18 July 2005 7:38 PM To: Tomcat Users List Subject: RE: Preprocessing JSP pages Our changes are things like diagnostic trace/logs, which we can't have permanently switched on for performance reasons. We might want to switch them on, occasionally, at a customer site. Indeed, we don't want to have them permanently present in the JSP at all (i.e. convert the pre-processing into a run-time check), also for performance reasons. That was the original motivation for making this stuff pre-processed. Edward. -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: 18 July 2005 10:58 To: 'Tomcat Users List' Subject: AW: Preprocessing JSP pages How about integrating it in your ant build script? This changes your preprocessing from runtime to compile time. Bernhard -Ursprüngliche Nachricht- Von: Edward Hibbert [mailto:[EMAIL PROTECTED] Gesendet: Montag, 18. Juli 2005 11:32 An: tomcat-user@jakarta.apache.org Betreff: Preprocessing JSP pages Perhaps you can help me. We have an application which used Tomcat v4, which I'm migrating to use 5.5.9. We made some changes to the Tomcat source to allow JSP pages to be preprocessed, so that we could strip out/add in certain code branches at runtime based on configuration. We did this by making changes to e.g. ParserController.java. In retrospect this wasn't a great idea, because it meant we had to ship our own version of Tomcat, so we're looking at removing these changes so that we can use a vanilla version of Tomcat. I can roll my own different version of this preprocessing, e.g. as part of starting Tomcat. But I'm wondering whether there's a way you're supposed to do something like this? E.g. is there a way you can register something to get invoked when Tomcat is loading JSP, without having to hack the code to do so? Thanks for any help, Edward Hibbert. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.0/50 - Release Date: 16/07/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preprocessing JSP pages
Without wishing at all to be ungrateful - this is just one example of what we use the preprocessing for. I'm sure I can find a way to remove each of them, and turn them into runtime switches, and find a way of making that perform ok (if it needs it). If it were me, that's what I'd have done to start off with :-). But it's likely to be a sizeable effort - more effort than converting our current preprocessing into a different form, or reintegrating the code changes we made to Tomcat 4. So what I'm after is whether there is a common way of hooking in preprocessing. If there isn't - which the replies so far suggest - then fine. Edward. -Original Message- From: Peter Crowther [mailto:[EMAIL PROTECTED] Sent: 18 July 2005 11:12 To: Tomcat Users List Subject: RE: Preprocessing JSP pages From: Edward Hibbert [mailto:[EMAIL PROTECTED] Indeed, we don't want to have them permanently present in the JSP at all (i.e. convert the pre-processing into a run-time check), also for performance reasons. That was the original motivation for making this stuff pre-processed. If you haven't benchmarked the effect on performance of leaving the switches in the code, you might like to look at the log4j site, where there are benchmarks on log4j. It's illuminating. - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preprocessing JSP pages
I'm not sure what you mean. Throwing an assertionerror exception? Why would I do that (for something like this) rather than using an if test? Edward. -Original Message- From: Daron [mailto:[EMAIL PROTECTED] Sent: 18 July 2005 11:18 To: 'Tomcat Users List' Subject: RE: Preprocessing JSP pages Have you considered using the assertion facility in the Java 5.0 compiler? Daron. -Original Message- From: Edward Hibbert [mailto:[EMAIL PROTECTED] Sent: Monday, 18 July 2005 7:38 PM To: Tomcat Users List Subject: RE: Preprocessing JSP pages Our changes are things like diagnostic trace/logs, which we can't have permanently switched on for performance reasons. We might want to switch them on, occasionally, at a customer site. Indeed, we don't want to have them permanently present in the JSP at all (i.e. convert the pre-processing into a run-time check), also for performance reasons. That was the original motivation for making this stuff pre-processed. Edward. -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: 18 July 2005 10:58 To: 'Tomcat Users List' Subject: AW: Preprocessing JSP pages How about integrating it in your ant build script? This changes your preprocessing from runtime to compile time. Bernhard -Ursprüngliche Nachricht- Von: Edward Hibbert [mailto:[EMAIL PROTECTED] Gesendet: Montag, 18. Juli 2005 11:32 An: tomcat-user@jakarta.apache.org Betreff: Preprocessing JSP pages Perhaps you can help me. We have an application which used Tomcat v4, which I'm migrating to use 5.5.9. We made some changes to the Tomcat source to allow JSP pages to be preprocessed, so that we could strip out/add in certain code branches at runtime based on configuration. We did this by making changes to e.g. ParserController.java. In retrospect this wasn't a great idea, because it meant we had to ship our own version of Tomcat, so we're looking at removing these changes so that we can use a vanilla version of Tomcat. I can roll my own different version of this preprocessing, e.g. as part of starting Tomcat. But I'm wondering whether there's a way you're supposed to do something like this? E.g. is there a way you can register something to get invoked when Tomcat is loading JSP, without having to hack the code to do so? Thanks for any help, Edward Hibbert. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.0/50 - Release Date: 16/07/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preprocessing JSP pages
If you place method calls in the assertion statements and compile the code with assertions disabled the code for method calls should be removed (It isn't removed from the .class files but hopefully from the output the JIT). Your remark about what your supposed to do made me think of it. Regards, Daron. -Original Message- From: Edward Hibbert [mailto:[EMAIL PROTECTED] Sent: Monday, 18 July 2005 7:54 PM To: Tomcat Users List Subject: RE: Preprocessing JSP pages I'm not sure what you mean. Throwing an assertionerror exception? Why would I do that (for something like this) rather than using an if test? Edward. -Original Message- From: Daron [mailto:[EMAIL PROTECTED] Sent: 18 July 2005 11:18 To: 'Tomcat Users List' Subject: RE: Preprocessing JSP pages Have you considered using the assertion facility in the Java 5.0 compiler? Daron. -Original Message- From: Edward Hibbert [mailto:[EMAIL PROTECTED] Sent: Monday, 18 July 2005 7:38 PM To: Tomcat Users List Subject: RE: Preprocessing JSP pages Our changes are things like diagnostic trace/logs, which we can't have permanently switched on for performance reasons. We might want to switch them on, occasionally, at a customer site. Indeed, we don't want to have them permanently present in the JSP at all (i.e. convert the pre-processing into a run-time check), also for performance reasons. That was the original motivation for making this stuff pre-processed. Edward. -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: 18 July 2005 10:58 To: 'Tomcat Users List' Subject: AW: Preprocessing JSP pages How about integrating it in your ant build script? This changes your preprocessing from runtime to compile time. Bernhard -Ursprüngliche Nachricht- Von: Edward Hibbert [mailto:[EMAIL PROTECTED] Gesendet: Montag, 18. Juli 2005 11:32 An: tomcat-user@jakarta.apache.org Betreff: Preprocessing JSP pages Perhaps you can help me. We have an application which used Tomcat v4, which I'm migrating to use 5.5.9. We made some changes to the Tomcat source to allow JSP pages to be preprocessed, so that we could strip out/add in certain code branches at runtime based on configuration. We did this by making changes to e.g. ParserController.java. In retrospect this wasn't a great idea, because it meant we had to ship our own version of Tomcat, so we're looking at removing these changes so that we can use a vanilla version of Tomcat. I can roll my own different version of this preprocessing, e.g. as part of starting Tomcat. But I'm wondering whether there's a way you're supposed to do something like this? E.g. is there a way you can register something to get invoked when Tomcat is loading JSP, without having to hack the code to do so? Thanks for any help, Edward Hibbert. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.0/50 - Release Date: 16/07/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.0/50 - Release Date: 16/07/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
I am still stuck with this one (shouldn't have posted it on a Saturday morning!). I don't think it is my web.xml giving the problem - I am looking into possible problems with missing or conflicting jar files Reading through the release notes again for Tomcat 5.5.9, there is a listing of the libraries included: = Bundled APIs: = A standard installation of Tomcat 5.5 makes all of the following APIs available for use by web applications (by placing them in common/lib or shared/lib): * commons-el.jar (Commons Expression Language 1.0) * commons-logging-api.jar (Commons Logging API 1.0.x) * jasper-compiler.jar (Jasper 2 Compiler) * jasper-compiler-jdt.jar (Eclipse JDT Java compiler) * jasper-runtime.jar (Jasper 2 Runtime) * jsp-api.jar (JSP 2.0 API) * naming-common.jar (JNDI Context implementation) * naming-factory.jar (JNDI object factories for J2EE ENC support) * naming-factory-dbcp.jar (DataSource implementation based on commons-dbcp) * naming-resources.jar (JNDI DirContext implementations) * servlet-api.jar (Servlet 2.4 API) I seem to be missing: commons-logging-api.jar (Commons Logging API 1.0.x) naming-common.jar (JNDI Context implementation) from my Tomcat installation (Windows 2000, I used the windows installer jakarta-tomcat-5.5.9.exe) Why should this be the case? Where can I download these files from? Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5.9 connection pooling
Hi! I am using Tomcat 5.5.9 and I have established a DataSource for database connection pooling where I can get connections from. But when I try to close the connection via myConnection.close(), always an exception is thrown. Is it right to close the connection this way or do I have to return the connection to the pool in another way? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.9 connection pooling
Can you attach the exception thrown ? Viorel Dragomir . .. --- - Original Message - From: [EMAIL PROTECTED] To: tomcat-user@jakarta.apache.org Sent: Monday, July 18, 2005 13:38 Subject: Tomcat 5.5.9 connection pooling Hi! I am using Tomcat 5.5.9 and I have established a DataSource for database connection pooling where I can get connections from. But when I try to close the connection via myConnection.close(), always an exception is thrown. Is it right to close the connection this way or do I have to return the connection to the pool in another way? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.9 connection pooling
Can you please write what exception do you get when you try to close the database connection? - Original Message - From: [EMAIL PROTECTED] To: tomcat-user@jakarta.apache.org Sent: Monday, July 18, 2005 4:38 PM Subject: Tomcat 5.5.9 connection pooling Hi! I am using Tomcat 5.5.9 and I have established a DataSource for database connection pooling where I can get connections from. But when I try to close the connection via myConnection.close(), always an exception is thrown. Is it right to close the connection this way or do I have to return the connection to the pool in another way? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Tomcat 5.5.9 connection pooling
Here is the exception that is thrown. As you can see my connection seems to be already closed. But why? Can this be configured somewhere? -Ursprüngliche Nachricht- Von: Viorel Dragomir [mailto:[EMAIL PROTECTED] Gesendet: Montag, 18. Juli 2005 14:46 An: Tomcat Users List Betreff: Re: Tomcat 5.5.9 connection pooling Can you attach the exception thrown ? Viorel Dragomir . .. --- - Original Message - From: [EMAIL PROTECTED] To: tomcat-user@jakarta.apache.org Sent: Monday, July 18, 2005 13:38 Subject: Tomcat 5.5.9 connection pooling Hi! I am using Tomcat 5.5.9 and I have established a DataSource for database connection pooling where I can get connections from. But when I try to close the connection via myConnection.close(), always an exception is thrown. Is it right to close the connection this way or do I have to return the connection to the pool in another way? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] java.sql.SQLException: Connection is closed. at org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.checkOpen(PoolingDataSource.java:174) at org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:179) at com.materna.buc.buildmanager.database.impl.BMDatabaseHandlerImpl.getUserList(Unknown Source) at com.materna.buc.buildmanager.actions.CreateLoginAction.execute(Unknown Source) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at com.materna.buc.buildmanager.controller.BMRequestProcessor.processPreprocess(Unknown Source) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:184) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:693) at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:660) at org.apache.struts.taglib.logic.ForwardTag.doForward(ForwardTag.java:121) at org.apache.struts.taglib.logic.ForwardTag.doEndTag(ForwardTag.java:105) at org.apache.jsp.index_jsp._jspx_meth_logic_forward_0(org.apache.jsp.index_jsp:88) at org.apache.jsp.index_jsp._jspService(org.apache.jsp.index_jsp:61) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at
Re: AW: Tomcat 5.5.9 connection pooling
Hi Peter, i've had this problem in a project long ago. I left the company befor i solved this, but meanwhile i am quite sure this was not a problem of Tomcat, but of using ResultSet wrong. Maybe this is your problem too. ResultSet is a connection to the database- if you iterate over ResultSet when the connection has allready be closed you get this error. Check for this errors: db.getConnection(); ResultSet rs = Statement... db.closeConnection(): while(rs.hasNext()) Hope this helps, Chris [EMAIL PROTECTED] wrote: Here is the exception that is thrown. As you can see my connection seems to be already closed. But why? Can this be configured somewhere? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: binary streaming / content-type problem with mod_jk
Hi all ! I've developed a servlet which does a binary stream of a mpeg video file which is created progressively (by another servlet/software/Unix command/... ) and finally read and played by Quicktime. I use Apache and Tomcat so I've installed mod_jk All work well but... : If I go on http://localhost:8080/my_test/BinaryStreaming it works well with QuickTime 7 and QuickTime 6 (6, 6.5, 6.5.2, ...). I have mod_jk so I can go on http://localhost/my_test/BinaryStreaming and here it still works well with QT7. But QT6 seems to wait that the video file is entirely created to start the viewing instead of starting to play the movie as soon as there is data in it. (- like it does with QT7 and QT6 with :8080 or without :8080 and when I use QT7). I think it's due to mod_jk but I've no idea to make it work I've found that another person had a similar problem, but no answer was given : http://www.junlu.com/msg/107218.html This message was posted in 09/2004 and it seems that Apache causes problems with pre-defined MIME-Types. Does someone have an answer or an idea ? :-) Thanks in advance. Regards, Jérôme - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache-like Deny/Allow directives
The deny directives in the httpd.conf are not respected when it comes to pages ending with either of the .jsp or .do extensions, and are therefore relayed to Tomcat which then gives the response to the browser. The Deny directives are not respected for these requests. But I know that Apache still respects those directives, because all I can access from outside of my .company.com domain is the plain html, without any images or any style sheet. This behavior is confirmed by the Apache access.log and error.log Finaly, to answer your question, my problem is not that I can't restrict access to areas, it is that my restrictions defined in httpd.conf are not respected when it comes to dynamic content. Luc Boudreau Université du Québec Canada -Message d'origine- De : Justin Crabtree [mailto:[EMAIL PROTECTED] Envoyé : 15 juillet 2005 10:02 À : Tomcat Users List Objet : Re: Apache-like Deny/Allow directives [EMAIL PROTECTED] wrote: Is there any way, with Tomcat, to block connections from domains and allow only certain ones, just like the Apache directive : Order Deny,Allow Deny from all Allow from .company.com I've setup my Apache server to do this, but since all the dynamic content is relayed to tomcat (jsp's), it is still accessible to the internet. Luc Boudreau Université du Québec Canada Is there a reason you can't use Apache directives on the areas you wish to restrict? -- Justin Crabtree Java Programmer Ozarks Technical Community College 447-7533 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
Hi, my Tomcat 5.5.9 has the commons-logging-api.jar in the bin directory. Did you look there, too? John Pedersen wrote: I am still stuck with this one (shouldn't have posted it on a Saturday morning!). I don't think it is my web.xml giving the problem - I am looking into possible problems with missing or conflicting jar files Reading through the release notes again for Tomcat 5.5.9, there is a listing of the libraries included: = Bundled APIs: = A standard installation of Tomcat 5.5 makes all of the following APIs available for use by web applications (by placing them in common/lib or shared/lib): * commons-el.jar (Commons Expression Language 1.0) * commons-logging-api.jar (Commons Logging API 1.0.x) * jasper-compiler.jar (Jasper 2 Compiler) * jasper-compiler-jdt.jar (Eclipse JDT Java compiler) * jasper-runtime.jar (Jasper 2 Runtime) * jsp-api.jar (JSP 2.0 API) * naming-common.jar (JNDI Context implementation) * naming-factory.jar (JNDI object factories for J2EE ENC support) * naming-factory-dbcp.jar (DataSource implementation based on commons-dbcp) * naming-resources.jar (JNDI DirContext implementations) * servlet-api.jar (Servlet 2.4 API) I seem to be missing: commons-logging-api.jar (Commons Logging API 1.0.x) naming-common.jar (JNDI Context implementation) from my Tomcat installation (Windows 2000, I used the windows installer jakarta-tomcat-5.5.9.exe) Why should this be the case? Where can I download these files from? Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
Phew! Solved. For those who find the same problem I had a copy of standard.jar in JAVA-HOME\lib\ext as well as in TOMCAT-HOME\web-apps\appName\WEB-INF\lib I think I tried putting it there a while ago, trying to fix something else, and must have forgotten to remove it. Thanks Cristoph... John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
This is what happens in JSPService.java around line 249:
try {
boolean precompile = preCompile(request);
serviceJspFile(request, response, jspUri, null, precompile);
} catch (RuntimeException e) {
throw e;
} catch (ServletException e) {
throw e;
} catch (IOException e) {
throw e;
} catch (Throwable e) {
throw new ServletException(e); line 249
}
You should get the Tomcat sources and set a breakpoint at line 249. When
you know the real throwable that is catched there, you will probably get
it clue what is happening.
Christoph
Christoph Kutzinski wrote:
Hi,
my Tomcat 5.5.9 has the commons-logging-api.jar in the bin directory.
Did you look there, too?
John Pedersen wrote:
I am still stuck with this one (shouldn't have posted it on a Saturday
morning!).
I don't think it is my web.xml giving the problem - I am looking into
possible problems with missing or conflicting jar files
Reading through the release notes again for Tomcat 5.5.9, there is a
listing of the libraries included:
=
Bundled APIs:
=
A standard installation of Tomcat 5.5 makes all of the following APIs
available
for use by web applications (by placing them in common/lib or
shared/lib):
* commons-el.jar (Commons Expression Language 1.0)
* commons-logging-api.jar (Commons Logging API 1.0.x)
* jasper-compiler.jar (Jasper 2 Compiler)
* jasper-compiler-jdt.jar (Eclipse JDT Java compiler)
* jasper-runtime.jar (Jasper 2 Runtime)
* jsp-api.jar (JSP 2.0 API)
* naming-common.jar (JNDI Context implementation)
* naming-factory.jar (JNDI object factories for J2EE ENC support)
* naming-factory-dbcp.jar (DataSource implementation based on
commons-dbcp)
* naming-resources.jar (JNDI DirContext implementations)
* servlet-api.jar (Servlet 2.4 API)
I seem to be missing:
commons-logging-api.jar (Commons Logging API 1.0.x)
naming-common.jar (JNDI Context implementation)
from my Tomcat installation (Windows 2000, I used the windows
installer jakarta-tomcat-5.5.9.exe)
Why should this be the case? Where can I download these files from?
Thanks,
John
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache-like Deny/Allow directives
Cant you use Location /my_secured_resource Order Deny,Allow Deny from all Allow from .company.com /Location Regards Guru -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 18 July 2005 14:30 To: tomcat-user@jakarta.apache.org Subject: Re: Apache-like Deny/Allow directives The deny directives in the httpd.conf are not respected when it comes to pages ending with either of the .jsp or .do extensions, and are therefore relayed to Tomcat which then gives the response to the browser. The Deny directives are not respected for these requests. But I know that Apache still respects those directives, because all I can access from outside of my .company.com domain is the plain html, without any images or any style sheet. This behavior is confirmed by the Apache access.log and error.log Finaly, to answer your question, my problem is not that I can't restrict access to areas, it is that my restrictions defined in httpd.conf are not respected when it comes to dynamic content. Luc Boudreau Université du Québec Canada -Message d'origine- De : Justin Crabtree [mailto:[EMAIL PROTECTED] Envoyé : 15 juillet 2005 10:02 À : Tomcat Users List Objet : Re: Apache-like Deny/Allow directives [EMAIL PROTECTED] wrote: Is there any way, with Tomcat, to block connections from domains and allow only certain ones, just like the Apache directive : Order Deny,Allow Deny from all Allow from .company.com I've setup my Apache server to do this, but since all the dynamic content is relayed to tomcat (jsp's), it is still accessible to the internet. Luc Boudreau Université du Québec Canada Is there a reason you can't use Apache directives on the areas you wish to restrict? -- Justin Crabtree Java Programmer Ozarks Technical Community College 447-7533 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat and your classpath
My current install of Tomcat 4.1.29 does not access my system classpath. I am using Windows 2000 Server. I would like Tomcat to access my classpath as I have a development package located in my %JAVA_HOME%\jre\lib\ext directory that I do not want to copy over to Tomcat\common\classes for my sites to access. I would like only one copy of this package located on my server and for standards reasons with my organization, it must be located in my lib\ext directory. Is there a way to add a path to Tomcat's classpath, or to even just add your entire classpath to Tomcat's classpath? Thanks! jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5.9: SAXParser error
I have the following configuration: JDK: 1.5.0_03 Apache Web Server: 2.0.52 Tomcat: 5.5.9 Connector: mod_jk 1.2.14 Server OS: Windows Server 2003 I encounter the following problem: Every time I update a JSP, then try to access it via a browser, I encounter: HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl could not be instantiated: java.lang.NullPointerException org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl could not be instantiated: java.lang.NullPointerException javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:152) org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:96) org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:750) org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1527) org.apache.jasper.compiler.Validator.validate(Validator.java:1495) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:157) org.apache.jasper.compiler.Compiler.compile(Compiler.java:286) org.apache.jasper.compiler.Compiler.compile(Compiler.java:267) org.apache.jasper.compiler.Compiler.compile(Compiler.java:255) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:556) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:293) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.9 logs. After seeing this message, I can restart Tomcat and the JSP functions normally. However, if I change the JSP, restart Tomcat before viewing the page, then view the page, I still get the error. For some reason, the error actually has to be thrown before restarting Tomcat fixes it. I know of no other fix. If I change two separate JSPs, I have to view the first page (throwing the error), restart Tomcat, then view the second page (throwing the error again), then restart Tomcat again. It is not enough to throw it once and restart to fix all pages; the error apparently tied to each page. I have discovered that I can make this error go away by applying the JDK 1.4.x compatibility patch, even though my JDK is version 1.5.0_03. This, however, caused me to get the error: java.lang.NoSuchMethodError: org.w3c.dom.Node.getTextContent()Ljava/lang/String; Presumably, the getTextContent() method was not present in JDK 1.4.x, thus the patch causes this error. When I remove the patch, the NoSuchMethodError is resolved, but the original error returns. I first posted this on Bugzilla (Bug 35720), where it was marked as invalid, and I was referred to this list. I posted the error here, and received no helpful information. When I learned of the compatibility patch fix, I reopened the bug on Bugzilla, but was told: We do not do user support. With Java 5, you're using the JAXP API as implemented by your vendor, so look in their docs.We also only support Tomcat on pristine JVM installations (no custom extensions). Please do not reopen the report. I haven't done anything to my JVM except install it directly from Sun. I've only customized Tomcat insofar as I have added the appropriate jars for JSTL and JavaMail. I don't know what the JAXP API is, nor who my vendor for it might be. I'm not even sure who I'm being told to ask about this anymore! Can somebody please at least steer me in the right direction with this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
Christoph,
I think there may be a little delay with the mailing list. The problem
is solved. For reference, yes, I too have the commons-logging-api.jar
in the bin directory! Wonder why it was put there - that seems a
little inconsistent, but I don't know enough about Tomcat to judge the
matter.
Putting a breakpoint in the source would have been a good and thorough
approach - I will try that next time!
Many thanks,
John
On 18/07/05, Christoph Kutzinski [EMAIL PROTECTED] wrote:
This is what happens in JSPService.java around line 249:
try {
boolean precompile = preCompile(request);
serviceJspFile(request, response, jspUri, null, precompile);
} catch (RuntimeException e) {
throw e;
} catch (ServletException e) {
throw e;
} catch (IOException e) {
throw e;
} catch (Throwable e) {
throw new ServletException(e); line 249
}
You should get the Tomcat sources and set a breakpoint at line 249. When
you know the real throwable that is catched there, you will probably get
it clue what is happening.
Christoph
Christoph Kutzinski wrote:
Hi,
my Tomcat 5.5.9 has the commons-logging-api.jar in the bin directory.
Did you look there, too?
John Pedersen wrote:
I am still stuck with this one (shouldn't have posted it on a Saturday
morning!).
I don't think it is my web.xml giving the problem - I am looking into
possible problems with missing or conflicting jar files
Reading through the release notes again for Tomcat 5.5.9, there is a
listing of the libraries included:
=
Bundled APIs:
=
A standard installation of Tomcat 5.5 makes all of the following APIs
available
for use by web applications (by placing them in common/lib or
shared/lib):
* commons-el.jar (Commons Expression Language 1.0)
* commons-logging-api.jar (Commons Logging API 1.0.x)
* jasper-compiler.jar (Jasper 2 Compiler)
* jasper-compiler-jdt.jar (Eclipse JDT Java compiler)
* jasper-runtime.jar (Jasper 2 Runtime)
* jsp-api.jar (JSP 2.0 API)
* naming-common.jar (JNDI Context implementation)
* naming-factory.jar (JNDI object factories for J2EE ENC support)
* naming-factory-dbcp.jar (DataSource implementation based on
commons-dbcp)
* naming-resources.jar (JNDI DirContext implementations)
* servlet-api.jar (Servlet 2.4 API)
I seem to be missing:
commons-logging-api.jar (Commons Logging API 1.0.x)
naming-common.jar (JNDI Context implementation)
from my Tomcat installation (Windows 2000, I used the windows
installer jakarta-tomcat-5.5.9.exe)
Why should this be the case? Where can I download these files from?
Thanks,
John
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5.9: SAXParser error
Here is the link to the JAXP (Java API for XML Processing) that is included with the Java 1.5.x sdk. There are specifications, documentation, FAQ's, etc available here. http://java.sun.com/xml/jaxp/index.jsp Sorry I couldn't help more than that :( jason -Original Message- From: Craig Dixon [mailto:[EMAIL PROTECTED] Sent: Monday, July 18, 2005 9:53 AM To: Tomcat Users List Subject: Tomcat 5.5.9: SAXParser error I have the following configuration: JDK: 1.5.0_03 Apache Web Server: 2.0.52 Tomcat: 5.5.9 Connector: mod_jk 1.2.14 Server OS: Windows Server 2003 I encounter the following problem: Every time I update a JSP, then try to access it via a browser, I encounter: HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl could not be instantiated: java.lang.NullPointerException org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl could not be instantiated: java.lang.NullPointerException javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:15 2) org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:96 ) org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImp l.java:750) org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1527 ) org.apache.jasper.compiler.Validator.validate(Validator.java:1495) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:157) org.apache.jasper.compiler.Compiler.compile(Compiler.java:286) org.apache.jasper.compiler.Compiler.compile(Compiler.java:267) org.apache.jasper.compiler.Compiler.compile(Compiler.java:255) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.ja va:556) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja va:293) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.9 logs. After seeing this message, I can restart Tomcat and the JSP functions normally. However, if I change the JSP, restart Tomcat before viewing the page, then view the page, I still get the error. For some reason, the error actually has to be thrown before restarting Tomcat fixes it. I know of no other fix. If I change two separate JSPs, I have to view the first page (throwing the error), restart Tomcat, then view the second page (throwing the error again), then restart Tomcat again. It is not enough to throw it once and restart to fix all pages; the error apparently tied to each page. I have discovered that I can make this error go away by applying the JDK 1.4.x compatibility patch, even though my JDK is version 1.5.0_03. This, however, caused me to get the error: java.lang.NoSuchMethodError: org.w3c.dom.Node.getTextContent()Ljava/lang/String; Presumably, the getTextContent() method was not present in JDK 1.4.x, thus the patch causes this error. When I remove the patch, the NoSuchMethodError is resolved, but the original error returns. I first posted this on Bugzilla (Bug 35720), where it was marked as invalid, and I was referred to this list. I posted the error here, and received no helpful information. When I learned of the compatibility patch fix, I reopened the bug on Bugzilla, but was told: We do not do user support. With Java 5, you're using the JAXP API as implemented by your vendor, so look in their docs.We also only support Tomcat on pristine JVM installations (no custom extensions). Please do not reopen the report. I haven't done anything to my JVM except install it directly from Sun. I've only customized Tomcat insofar as I have added the appropriate jars for JSTL and JavaMail. I don't know what the JAXP API is, nor who my vendor for it might be. I'm not even sure who I'm being told to ask about this anymore! Can somebody please at least steer me in the right direction with this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.9: SAXParser error
hihi, it seems the error is related to JSTL/Validator... what version of struts are you using? and have you properly installed them? are you upgrading your application from an older setup? (win2k,jdk 1.4, tc 4.x?) woodchuck --- Craig Dixon [EMAIL PROTECTED] wrote: I have the following configuration: JDK: 1.5.0_03 Apache Web Server: 2.0.52 Tomcat: 5.5.9 Connector: mod_jk 1.2.14 Server OS: Windows Server 2003 I encounter the following problem: Every time I update a JSP, then try to access it via a browser, I encounter: HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl could not be instantiated: java.lang.NullPointerException org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl could not be instantiated: java.lang.NullPointerException javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:152) org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:96) org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:750) org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1527) org.apache.jasper.compiler.Validator.validate(Validator.java:1495) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:157) org.apache.jasper.compiler.Compiler.compile(Compiler.java:286) org.apache.jasper.compiler.Compiler.compile(Compiler.java:267) org.apache.jasper.compiler.Compiler.compile(Compiler.java:255) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:556) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:293) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.9 logs. After seeing this message, I can restart Tomcat and the JSP functions normally. However, if I change the JSP, restart Tomcat before viewing the page, then view the page, I still get the error. For some reason, the error actually has to be thrown before restarting Tomcat fixes it. I know of no other fix. If I change two separate JSPs, I have to view the first page (throwing the error), restart Tomcat, then view the second page (throwing the error again), then restart Tomcat again. It is not enough to throw it once and restart to fix all pages; the error apparently tied to each page. I have discovered that I can make this error go away by applying the JDK 1.4.x compatibility patch, even though my JDK is version 1.5.0_03. This, however, caused me to get the error: java.lang.NoSuchMethodError: org.w3c.dom.Node.getTextContent()Ljava/lang/String; Presumably, the getTextContent() method was not present in JDK 1.4.x, thus the patch causes this error. When I remove the patch, the NoSuchMethodError is resolved, but the original error returns. I first posted this on Bugzilla (Bug 35720), where it was marked as invalid, and I was referred to this list. I posted the error here, and received no helpful information. When I learned of the compatibility patch fix, I reopened the bug on Bugzilla, but was told: We do not do user support. With Java 5, you're using the JAXP API as implemented by your vendor, so look in their docs.We also only support Tomcat on pristine JVM installations (no custom extensions). Please do not reopen the report. I haven't done anything to my JVM except install it directly from Sun. I've only customized Tomcat insofar as I have added the appropriate jars for JSTL and JavaMail. I don't know what the JAXP API is, nor who my vendor for it might be. I'm not even sure who I'm being told to ask about this anymore! Can somebody please at least steer me in the right direction with this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: ServletException: javax/servlet/jsp/tagext/TagLibraryValidator
John Pedersen wrote: Christoph, I think there may be a little delay with the mailing list. The problem is solved. For reference, yes, I too have the commons-logging-api.jar in the bin directory! Wonder why it was put there - that seems a little inconsistent, but I don't know enough about Tomcat to judge the matter. That is exactly what I thought when I found it in bin: What the h*ll does the jar do in here? ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TR: Apache-like Deny/Allow directives
It seems that the Location directive is the right one to use. I've been using the Directory directive and it didn't block the dynamic content. Now that I've added the Location directive, it works and more, it adds a supplemental security barrier. Thanks a lot for your ideas, it really helped Luc Boudreau Université du Québec Canada -Message d'origine- De : Raghupathy,Gurumoorthy [mailto:[EMAIL PROTECTED] Envoyé : 18 juillet 2005 10:02 À : 'Tomcat Users List' Objet : RE: Apache-like Deny/Allow directives Cant you use Location /my_secured_resource Order Deny,Allow Deny from all Allow from .company.com /Location Regards Guru -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 18 July 2005 14:30 To: tomcat-user@jakarta.apache.org Subject: Re: Apache-like Deny/Allow directives The deny directives in the httpd.conf are not respected when it comes to pages ending with either of the .jsp or .do extensions, and are therefore relayed to Tomcat which then gives the response to the browser. The Deny directives are not respected for these requests. But I know that Apache still respects those directives, because all I can access from outside of my .company.com domain is the plain html, without any images or any style sheet. This behavior is confirmed by the Apache access.log and error.log Finaly, to answer your question, my problem is not that I can't restrict access to areas, it is that my restrictions defined in httpd.conf are not respected when it comes to dynamic content. Luc Boudreau Université du Québec Canada -Message d'origine- De : Justin Crabtree [mailto:[EMAIL PROTECTED] Envoyé : 15 juillet 2005 10:02 À : Tomcat Users List Objet : Re: Apache-like Deny/Allow directives [EMAIL PROTECTED] wrote: Is there any way, with Tomcat, to block connections from domains and allow only certain ones, just like the Apache directive : Order Deny,Allow Deny from all Allow from .company.com I've setup my Apache server to do this, but since all the dynamic content is relayed to tomcat (jsp's), it is still accessible to the internet. Luc Boudreau Université du Québec Canada Is there a reason you can't use Apache directives on the areas you wish to restrict? -- Justin Crabtree Java Programmer Ozarks Technical Community College 447-7533 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The servlet that would not die.
Hi all, my configuration is based on Apache 1.3 using mod_jk connecting to an ajp13 thread on Tomcat 5.5. This is the connector port definition I am using in my server.xml: Connector port=8009 maxThreads=75 minSpareThreads=10 maxSpareThreads=15 enableLookups=false redirectPort=8443 protocol=AJP/1.3 disableUploadTimeout=false connectionTimeout=6/ My servlet (I do not own the source code) is randomly getting hung while servicing requests, but Tomcat will not timeout these threads. I am trying to get these threads to timeout so that the servlet can continue processing other requests. When one request fails, I can see all subsequent requests build up on the Tomcat servlet status page until the queue is full. They are all stuck in service status (Status S) and just sit there until I restart Tomcat. Any ideas? - NOTICE OF CONFIDENTIALITY - The information in this email, including attachments, may be confidential and/or privileged and may contain confidential health information. This email is intended to be reviewed only by the individual or organization named as addressee. If you have received this email in error please notify Spheris immediately--by return message to the sender or to [EMAIL PROTECTED] -- and destroy all copies of this message and any attachments. Confidential health information is protected by state and federal law, including, but not limited to, the Health Insurance Portability and Accountability Act of 1996 and related regulations. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache-like Deny/Allow directives
Welcome ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 18 July 2005 16:57 To: tomcat-user@jakarta.apache.org Subject: TR: Apache-like Deny/Allow directives It seems that the Location directive is the right one to use. I've been using the Directory directive and it didn't block the dynamic content. Now that I've added the Location directive, it works and more, it adds a supplemental security barrier. Thanks a lot for your ideas, it really helped Luc Boudreau Université du Québec Canada -Message d'origine- De : Raghupathy,Gurumoorthy [mailto:[EMAIL PROTECTED] Envoyé : 18 juillet 2005 10:02 À : 'Tomcat Users List' Objet : RE: Apache-like Deny/Allow directives Cant you use Location /my_secured_resource Order Deny,Allow Deny from all Allow from .company.com /Location Regards Guru -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 18 July 2005 14:30 To: tomcat-user@jakarta.apache.org Subject: Re: Apache-like Deny/Allow directives The deny directives in the httpd.conf are not respected when it comes to pages ending with either of the .jsp or .do extensions, and are therefore relayed to Tomcat which then gives the response to the browser. The Deny directives are not respected for these requests. But I know that Apache still respects those directives, because all I can access from outside of my .company.com domain is the plain html, without any images or any style sheet. This behavior is confirmed by the Apache access.log and error.log Finaly, to answer your question, my problem is not that I can't restrict access to areas, it is that my restrictions defined in httpd.conf are not respected when it comes to dynamic content. Luc Boudreau Université du Québec Canada -Message d'origine- De : Justin Crabtree [mailto:[EMAIL PROTECTED] Envoyé : 15 juillet 2005 10:02 À : Tomcat Users List Objet : Re: Apache-like Deny/Allow directives [EMAIL PROTECTED] wrote: Is there any way, with Tomcat, to block connections from domains and allow only certain ones, just like the Apache directive : Order Deny,Allow Deny from all Allow from .company.com I've setup my Apache server to do this, but since all the dynamic content is relayed to tomcat (jsp's), it is still accessible to the internet. Luc Boudreau Université du Québec Canada Is there a reason you can't use Apache directives on the areas you wish to restrict? -- Justin Crabtree Java Programmer Ozarks Technical Community College 447-7533 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: The servlet that would not die.
From: Nathan Roy [mailto:[EMAIL PROTECTED] Subject: The servlet that would not die. My servlet (I do not own the source code) is randomly getting hung while servicing requests, but Tomcat will not timeout these threads. You have a bug in the servlet, and you need to fix it, live with it, or stop using it. The timeout value is for a connection, not an active request. Once a request has been handed off to a thread to process, it's up to the application code to insure that the request finishes. There's nothing Tomcat can do for this. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Session Replication w/ Tomcat 5.0.30
I'm testing a clustered Tomcat (5.0.30) configuration on Windows XP Professional, behind Apache 2.0.54 with mod_jk as my load balancer. Load balancing works fine, as I can see sessions being dispatched to each Tomcat from mod_jk (sticky sessions is disabled.) The problem I have is that session replication between the Tomcat instances is failing. I've verified that the multicast 'heartbeats' are being sent (via Ethereal), but I never see any TCP traffic between the instances. This PC is NOT multi-homed (only have one network card), but I've been able to do similar setups in Linux (multiple instances on one server) without any problems. Does anyone have a suggestions on what I can try to do to get sessions to replicate? Thanks! Jerry Jalenak Software Engineer Netopia, Inc.
Re: osType is null
onSubmit=fillOS();
function fillOS()
{
document.logonform.osType.value = navigator.userAgent;
setCursor('wait');
}
This is not tomcat related i would daresay, but it's easily possible
(wtih firefox and opera) to manipulate
the userAgent in the browser. Everyone could leave the browser
identification empty.
Try
navigator.platform
too, if you want to get another chance to identify the os type of the user.
Chris.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
JAASRealm and Subject
Hi! I'm using the Tomcat 5 JAASRealm for authenticating users with my own LoginModule. In my LoginModule I am populating the Subject object delivered by the Realm with Principals, Role Principals and Credentials. The authentication and the mapping of my user defined roles to tomcat roles work fine, but I can´t get a reference to the Subject object in my servlets. I have tried: AccessControlContext context = AccessController.getContext(); Subject subject = Subject.getSubject(context); But it´s not working... subject = null; Can anybody help me, please ? Rogerio.
Request too long
Hello, I'm building a web application on tomcat 4.1.18 which is connected to apache 2 web server by ajp13 connector. I get the response : Server Error The following error occurred: [code=HTTP_REQUEST_TOO_LONG] The HTTP request is too long. Contact your system administrator. when I press the submit button of a form with an html textarea with large amount of text. When I reduce the amount of text in the textarea it works fine. I assume it's a tomcat response because the apache usually gives an error number. Does anyone know if there is a place, in the conf files, to rise the maximal length of the request accepted by tomcat? Or, does anyone know a solution for this problem? Thanks ahead, Yair.
Tomcat 5.5 changes in Log format
Hello. We run a webhosting environment, and in previous releases we were able to have separate logs for *each* virtual host by using something like this: Host name=mydomain.com ... ... Logger className=org.apache.catalina.logger.FileLogger prefix=domain.com_log. suffix=.txt directory=/home/melang timestamp=true/ ... /Host After we just upgraded to Tomcat 5.5, we see this support was removed, and are looking for ways to get around this and still provide seperate logging ability for each virtual host. Does anyone have any suggestions on how to set something like this up on Tomcat 5.5 ? We looked at log4j but it doesn't seem like the same thing. Kind Regards, Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAASRealm and Subject
Hi, I'm not 100% sure if this is applicable, but I just found this: Due to a design oversight in the JAAS 1.0, javax.security.auth.Subject.getSubject() does not return the Subject associated with the thread of execution inside a java.security.AccessController.doPrivileged() code block. This can present a inconsistent behavior that is problematic and causes undesirable effort. com.ibm.websphere.security.auth.WSSubject provides a work around to associate Subject to thread of execution. com.ibm.websphere.security.auth.WSSubject extends the JAAS authorization model to J2EE resources. in this thread: http://groups-beta.google.com/group/comp.lang.java.security/browse_thread/thread/3fbba23648cfb556/b736a3b0f27fc170?q=get+subject+loginmodulernum=21#b736a3b0f27fc170 If the above is applicable, then I don't know what the equivalent workaround would be for Tomcat? Jim ohaya wrote: Rogerio, I've been wrestling with this exact same problem, but haven't had any more success than you have had thus far, so if you find out the answer to this, can you please post a msg here? I'll do the same... Thanks, Jim Rogerio Baldini das Neves wrote: Hi! I'm using the Tomcat 5 JAASRealm for authenticating users with my own LoginModule. In my LoginModule I am populating the Subject object delivered by the Realm with Principals, Role Principals and Credentials. The authentication and the mapping of my user defined roles to tomcat roles work fine, but I can´t get a reference to the Subject object in my servlets. I have tried: AccessControlContext context = AccessController.getContext(); Subject subject = Subject.getSubject(context); But it´s not working... subject = null; Can anybody help me, please ? Rogerio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 changes in Log format
hihi, the default logging mechanism in TC 5.5 is java.util.logging. you need to place a separate logging.properties file in the class folder of each of your webapps that require separate logging (and of course make sure to name these logging files differently). details can be found here: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/logging.html woodchuck --- Robert Abbate [EMAIL PROTECTED] wrote: Hello. We run a webhosting environment, and in previous releases we were able to have separate logs for *each* virtual host by using something like this: Host name=mydomain.com ... ... Logger className=org.apache.catalina.logger.FileLogger prefix=domain.com_log. suffix=.txt directory=/home/melang timestamp=true/ ... /Host After we just upgraded to Tomcat 5.5, we see this support was removed, and are looking for ways to get around this and still provide seperate logging ability for each virtual host. Does anyone have any suggestions on how to set something like this up on Tomcat 5.5 ? We looked at log4j but it doesn't seem like the same thing. Kind Regards, Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making my servlet the default instead of what's in ROOT
On Sun, 2005-07-17 at 17:37 +0100, Mark Thomas wrote: Tomcat version? jakarta-tomcat-5.5.9 Chris Abajian wrote: More clues: We got it to work if you put Context path= docBase=webapps/our unpacked war file dir in the top-level server.xml file. It does NOT work if you put this context fragment in $CATALINA_HOME/conf/Catalina/localhost the documentation on auto-deployment is frustrating in a couple of points. My working hypothesis is that Catalina finds and parses the XML context fragment correctly, but then, when encountering the war file (or expanded directory) containing WEB-INF/web.xml it generates a new context automatically. The docs are vague on this, offering a warning that explicit contexts don't play well with autodeployed apps. Can anyone offer some insights into this? Is this the intended behavior? On Wed, 2005-07-13 at 13:13 -0700, Chris Abajian wrote: I want http://mylocal.tomcat.machine/ to run my servlet's hello world (instead of whatever's in ROOT) without having to put the servlet name in the path, i.e. I want it to be the front door for the domain. Can't make this work, no amount of futzing with Context path= or docBase= does it. This is a stupid question but I've been Googling and tweaking for a day now. Help? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request too long
Are you doing get or post? Yair Zohar wrote: Hello, I'm building a web application on tomcat 4.1.18 which is connected to apache 2 web server by ajp13 connector. I get the response : Server Error The following error occurred: [code=HTTP_REQUEST_TOO_LONG] The HTTP request is too long. Contact your system administrator. when I press the submit button of a form with an html textarea with large amount of text. When I reduce the amount of text in the textarea it works fine. I assume it's a tomcat response because the apache usually gives an error number. Does anyone know if there is a place, in the conf files, to rise the maximal length of the request accepted by tomcat? Or, does anyone know a solution for this problem? Thanks ahead, Yair. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat Connection Pooling - Future of?
Greetings, I am a student at the University of Delaware looking to do research on connection pooling. Currently I am analyzing the feasability of optimizing connection pooling. My hypothesis is that using a statistical analysis of the usage history to create a prediction of usage levels in the future, and adjusting the connection pool's settings based on usage level predictions will increase the throughput and decrease system requirements for websites with trends in user levels. does anyone know of any research that has been done / currently being done on this topic? Sincerely, Peter K. Steijn
Re: Request too long
At 12:28 PM 7/18/2005, Yair wrote: Server Error The following error occurred: [code=HTTP_REQUEST_TOO_LONG] The HTTP request is too long. Contact your system administrator. Just a wild guess here but it sounds like you are using the GET method for your form? There is a limit to the length of the URL for a GET. Try changing your form method to POST and see if that helps. _M_ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Deployment using WAR files
Hello, I have some questions about many people working in the same project and deploying using WAR file. I belong to a group that is developping a web application and use TOMCAT to test it. At the beginning the deployment was done by copying classes, jsp, and jar files etc to the folder of our web application into webapps subdirectory of TOMCAT. Then we decided to use a WAR file. However there are many people working in the same web application and deployment using a WAR means to undeploy and deploy the whole web application. We thought that one possible solution could be to copy the components of web application to the folder of web application as we used to do. But is that the correct way to do it ? How to could we deploy part of a web application using war files ? Is it possible to do it ? We wonder how people work in order to solve or minimize this situation. Thanks in advance for any help. Joaquim Roberto.
help getting a simple no dependency client working with tomcat
I am trying to get a simple zero dependency client to work with tomcat, at current it works with http://services.xmethods.net:80/soap/servlet/rpcrouter http://services.xmethods.net/soap/servlet/rpcrouter but not my home grown test web service http://localhost:8080/axis/services/fibonacci I have build a simple client using Apache dependencies that access the Fibonacci client so I know it works, but I'm utterly confused as to why my zero dependency client doesn't work. Well I shouldn't say my client since I took from an example article http://www-128.ibm.com/developerworks/xml/library/x-soapcl/ listing 1 has the source code http://www-128.ibm.com/developerworks/xml/library/x-soapcl/listing1.html The error I get follows (note I renamed the file LowClient.java): Exception in thread main java.io.IOException: Server returned HTTP response code: 500 for URL: http://localhost:8080/axis/services/fibonacci at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnec tion.java:800) at LowClient.main(LowClient.java:71) I don't understand why the client would break when targeting a tomcat service... I thought the whole point of web services is that they are all supposed to be a single client. The SOAP message file that LowClient is sending follows: ?xml version=1.0 encoding=UTF-8? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns1:calculateFibonacci soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; xmlns:ns1=urn:fibonacci in0 href=#id0/ /ns1:calculateFibonacci multiRef id=id0 soapenc:root=0 soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; xsi:type=xsd:int xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/;10/multiRef /soapenv:Body /soapenv:Envelope Thanks in advance for helping me understand this Tomcat Client interaction problem. NOTE: This message was send to the TomcatDev list which I have realized now was a mistake as it is for developers of Tomcat not for developing with Tomcat. For those on both lists I apologize for the dual send. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAASRealm and Subject
Rogerio, I've been wrestling with this exact same problem, but haven't had any more success than you have had thus far, so if you find out the answer to this, can you please post a msg here? I'll do the same... Thanks, Jim Rogerio Baldini das Neves wrote: Hi! I'm using the Tomcat 5 JAASRealm for authenticating users with my own LoginModule. In my LoginModule I am populating the Subject object delivered by the Realm with Principals, Role Principals and Credentials. The authentication and the mapping of my user defined roles to tomcat roles work fine, but I can´t get a reference to the Subject object in my servlets. I have tried: AccessControlContext context = AccessController.getContext(); Subject subject = Subject.getSubject(context); But it´s not working... subject = null; Can anybody help me, please ? Rogerio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
auto redeploy with context in server.xml
hi, in tomcat 5.5.9, is it possible to have a webapp, whose context is defined in server.xml, to be redeployed using the auto-deploy system? i have my ROOT webapp defined in server.xml: Host name=localhost appBase=webapps unpackWARs=false autoDeploy=true deployXML=false deployOnStartup=true Context path= reloadable=false docBase=/home/alex/webapp.war / /Host when i replace the .war file, i expect that tomcat should reload it, but nothing happens. i read a post that suggests this isn't possible because the context is staticly defined therefore it is not using the auto-deploy system. http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg152247.html if this is not possible, then how can i have a ROOT webapp that is auto redeployable? in tomcat 5.5.9, you can't specify a context with an empty path outside of server.xml, so this seems a bit like a catch-22. thanks. --alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk + CPU load
Hello everyone, I'm using Apache 2.043 + mod_jk 1.2.6 + Tomcat 4.03 (x2) + JDK 1.4.0 on Solaris 9 As load increases one of the tomcat instances takes up about 35% of CPU while the apache process takes another 30%. Tomcat Standalone didnt present this problem and it stayed always at 5% maximum. When load decreases the CPU usage is still there and doesnt go away until I restart apache. If i look into mod_jk.log I can see about 10 errors per hour like the following: [Thu Jul 14 20:50:22 2005] [jk_ajp_common.c (1146)]: ERROR sending data to client. Connection aborted or network problems [Thu Jul 14 20:50:22 2005] [jk_ajp_common.c (1462)]: ERROR: Client connection aborted or network problems My setup is exactly the same as described in the guide by Pascal Forget: http://raibledesigns.com/tomcat/ I had to go back to tomcat standalone because after about 3 hours of being in that state tomcat just stops servicing requests, but I would like to find the cause of it. The closest thing related to this is this bug in apache which wasn't after all: http://issues.apache.org/bugzilla/show_bug.cgi?id=27757 Hope someone can shed some light on this. Luis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat SSL Cipher Configuration
Jojo Paderes wrote: I'm looking for some decent documentation and technical reference on how to configure Tomcat's SSL cipher. Say for example I want Tomcat to support a specific SSL cipher suite like Triple DES. Hope someone has done something like this already. I'm using Tomcat 5.5 btw. See http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/http.html You want the ciphers attribute. The ciphers need to be named as per the cipher suites in JSSE. See http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.html Search the page for Supported Cipher Suites. Also, I am pretty sure they need to be comma separated. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat and SSL
Hello, I wanted to verify if I am understanding this right. The website has certain sections of it using HTTPS (secure) and certain sections use only HTTP (unsecure). 1. A new session resulting from a call to request.getSession(true) in a secure area of a website is invalidated automatically when the session transitions from the secure to an unsecure area of the website. 2. A new session resulting from a call to request.getSession(true) in an unsecure area of a website is untouched when the session transitions from the unsecure to a secure area of the website and from the unsecure to a secure area of the website. Am I understanding 1 and 2 right? Thanks, Mufaddal. -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. Consult your physician prior to the use of any medical supplies or product. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request too long
Mike Noel wrote: At 12:28 PM 7/18/2005, Yair wrote: Server Error The following error occurred: [code=HTTP_REQUEST_TOO_LONG] The HTTP request is too long. Contact your system administrator. Just a wild guess here but it sounds like you are using the GET method for your form? There is a limit to the length of the URL for a GET. Try changing your form method to POST and see if that helps. _M_ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Solved. Thanks a lot. Yair. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Refresh message.properties
I have found that I have to recycle the TC in order to bring up a updated version of a set of message.properties files. Is any other way to refresh the message.properties? Thanks for your inputs. Vernon Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAASRealm and Subject
Rogerio, Try taking a look at this page: http://www.kopz.org/public/documents/tomcat/jaasintomcat.html I read through this awhile ago, but as I was just re-reading it for maybe the 10th time, I think that I'm starting to see the light and understand what the page's author (Michiel Toneman) was trying to say, and the problem (with JAAS and Tomcat) that he was trying to describe and work around. In the 1st paragraph, he says: This is because the principals are used to denote the concepts of user and role, and are no longer available in the security context in which the webapp is executed. The result of the authentication is available only through request.getRemoteUser() and request.isUserInRole(). I think that what he is trying to say is that when you use JAAS normally with Tomcat (e.g., configure a JAASRealm), the only artifacts from the LoginModule that servlets and JSPs have access to are the user (via request.getRemoteUser()) and the user's roles (via calls to request.isUserInRole()). Putting it another way, I think that the author is saying that your JSPs and servlets under Tomcat simply cannot access things like the Subject, the Principals, etc. So, this page is about his proposed workaround for this. From what I can tell, the way that he does this is that he has a SecurityFilter, which gets invoked BEFORE the LoginModule, and this SecurityFilter populates the Subject into the HTTP session before creating the context and invoking the LoginModule. In other words, this SecurityFilter kind of wedges itself between Tomcat and the LoginModule, I think, and by doing that, the Subject, etc. are now no longer lost to being accessed by servlets/JSPs. If you have a chance, please take a look at the above link, and see if you read this page the same way that I do? Comments from anyone else would be greatly appreciated, as I am very curious about this. It's not so much that I can't seem to access the Subject, but it seems like with the Tomcat environment, any work that the LoginModule does to populate the Principals, etc. seems to be totally inaccessible to servlets and JSPs? Thanks, and apologies for the longish message... Jim ohaya wrote: Hi, I'm not 100% sure if this is applicable, but I just found this: Due to a design oversight in the JAAS 1.0, javax.security.auth.Subject.getSubject() does not return the Subject associated with the thread of execution inside a java.security.AccessController.doPrivileged() code block. This can present a inconsistent behavior that is problematic and causes undesirable effort. com.ibm.websphere.security.auth.WSSubject provides a work around to associate Subject to thread of execution. com.ibm.websphere.security.auth.WSSubject extends the JAAS authorization model to J2EE resources. in this thread: http://groups-beta.google.com/group/comp.lang.java.security/browse_thread/thread/3fbba23648cfb556/b736a3b0f27fc170?q=get+subject+loginmodulernum=21#b736a3b0f27fc170 If the above is applicable, then I don't know what the equivalent workaround would be for Tomcat? Jim ohaya wrote: Rogerio, I've been wrestling with this exact same problem, but haven't had any more success than you have had thus far, so if you find out the answer to this, can you please post a msg here? I'll do the same... Thanks, Jim Rogerio Baldini das Neves wrote: Hi! I'm using the Tomcat 5 JAASRealm for authenticating users with my own LoginModule. In my LoginModule I am populating the Subject object delivered by the Realm with Principals, Role Principals and Credentials. The authentication and the mapping of my user defined roles to tomcat roles work fine, but I can´t get a reference to the Subject object in my servlets. I have tried: AccessControlContext context = AccessController.getContext(); Subject subject = Subject.getSubject(context); But it´s not working... subject = null; Can anybody help me, please ? Rogerio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cluster problems: memberDisappeared errors
I'm using the cluster fix patch on 5.5.9 (from http://issues.apache.org/bugzilla/show_bug.cgi?id=34389) with 8 hosts clustered together. I was seeing alot of memberDisappeared errors before I applied this patch, now I'm still seeing them, but with more detail. Here's an example error from catalina.out: Jul 18, 2005 5:40:51 PM org.apache.catalina.cluster.tcp.SimpleTcpCluster memberDisappeared INFO: Received member disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://10.0.0.15:4002,10.0.0.15,4002, alive=1018550] Jul 18, 2005 5:40:51 PM org.apache.catalina.cluster.tcp.DataSender pushMessage INFO: resending 782 bytes to 10.0.0.15:4002 from 55784 java.net.SocketException: Socket closed at java.net.SocketInputStream.read(SocketInputStream.java:162) at java.net.SocketInputStream.read(SocketInputStream.java:182) at org.apache.catalina.cluster.tcp.DataSender.waitForAck(DataSender.java:542) at org.apache.catalina.cluster.tcp.DataSender.pushMessage(DataSender.java:504) at org.apache.catalina.cluster.tcp.FastAsyncSocketSender$FastQueueThread.run(FastAsyncSocketSender.java:401) A typical cluster config is: Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster name=hydraNation managerClassName=org.apache.catalina.cluster.session.DeltaManager expireSessionsOnShutdown=false useDirtyFlag=true notifyListenersOnReplication=true Membership className=org.apache.catalina.cluster.mcast.McastService mcastAddr=228.0.0.4 mcastPort=45564 mcastFrequency=700 mcastDropTime=5000/ Receiver className=org.apache.catalina.cluster.tcp.Jdk13ReplicationListener tcpListenAddress=10.0.0.12 compress=false tcpListenPort=4002 / Sender className=org.apache.catalina.cluster.tcp.ReplicationTransmitter replicationMode=fastasyncqueue compress=false doProcessingStats=true queueTimeWait=true maxQueueLength=1000 queueDoStats=true queueCheckLock=true ackTimeout=15000 waitForAck=true autoConnect=false keepAliveTimeout=@node.ackTimeout@ keepAliveMaxRequestCount=-1/ Valve className=org.apache.catalina.cluster.tcp.ReplicationValve filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ Deployer className=org.apache.catalina.cluster.deploy.FarmWarDeployer tempDir=/tmp/war-temp/ deployDir=/tmp/war-deploy/ watchDir=/tmp/war-listen/ watchEnabled=false/ /Cluster any ideas? I'm thinking there's something wrong with my multicast setup, but everything was working fine this morning... The servers are running RHEL3, all 2 way AMD64 machines with 4Gb ram each. They each have two network interfaces, each eth0 is connected to one gigabit switch, each eth1 to another (internal) gigabit switch. I don't think I should be hitting any network bottlenecks.. ? There is alot of load on the site being served in general, but no big jump in hits today. Should I be using a fastasyncqueue? What are the tradeoffs in Sender modes? Thanks in advance! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAASRealm and Subject
Is casting request.getUserPrincipal() to your custome-made Principal gonna help get what you want ? Jojada.- - Original Message - From: ohaya [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Tuesday, July 19, 2005 9:46 AM Subject: Re: JAASRealm and Subject Rogerio, Try taking a look at this page: http://www.kopz.org/public/documents/tomcat/jaasintomcat.html I read through this awhile ago, but as I was just re-reading it for maybe the 10th time, I think that I'm starting to see the light and understand what the page's author (Michiel Toneman) was trying to say, and the problem (with JAAS and Tomcat) that he was trying to describe and work around. In the 1st paragraph, he says: This is because the principals are used to denote the concepts of user and role, and are no longer available in the security context in which the webapp is executed. The result of the authentication is available only through request.getRemoteUser() and request.isUserInRole(). I think that what he is trying to say is that when you use JAAS normally with Tomcat (e.g., configure a JAASRealm), the only artifacts from the LoginModule that servlets and JSPs have access to are the user (via request.getRemoteUser()) and the user's roles (via calls to request.isUserInRole()). Putting it another way, I think that the author is saying that your JSPs and servlets under Tomcat simply cannot access things like the Subject, the Principals, etc. So, this page is about his proposed workaround for this. From what I can tell, the way that he does this is that he has a SecurityFilter, which gets invoked BEFORE the LoginModule, and this SecurityFilter populates the Subject into the HTTP session before creating the context and invoking the LoginModule. In other words, this SecurityFilter kind of wedges itself between Tomcat and the LoginModule, I think, and by doing that, the Subject, etc. are now no longer lost to being accessed by servlets/JSPs. If you have a chance, please take a look at the above link, and see if you read this page the same way that I do? Comments from anyone else would be greatly appreciated, as I am very curious about this. It's not so much that I can't seem to access the Subject, but it seems like with the Tomcat environment, any work that the LoginModule does to populate the Principals, etc. seems to be totally inaccessible to servlets and JSPs? Thanks, and apologies for the longish message... Jim ohaya wrote: Hi, I'm not 100% sure if this is applicable, but I just found this: Due to a design oversight in the JAAS 1.0, javax.security.auth.Subject.getSubject() does not return the Subject associated with the thread of execution inside a java.security.AccessController.doPrivileged() code block. This can present a inconsistent behavior that is problematic and causes undesirable effort. com.ibm.websphere.security.auth.WSSubject provides a work around to associate Subject to thread of execution. com.ibm.websphere.security.auth.WSSubject extends the JAAS authorization model to J2EE resources. in this thread: http://groups-beta.google.com/group/comp.lang.java.security/browse_thread/thread/3fbba23648cfb556/b736a3b0f27fc170?q=get+subject+loginmodulernum=21#b736a3b0f27fc170 If the above is applicable, then I don't know what the equivalent workaround would be for Tomcat? Jim ohaya wrote: Rogerio, I've been wrestling with this exact same problem, but haven't had any more success than you have had thus far, so if you find out the answer to this, can you please post a msg here? I'll do the same... Thanks, Jim Rogerio Baldini das Neves wrote: Hi! I'm using the Tomcat 5 JAASRealm for authenticating users with my own LoginModule. In my LoginModule I am populating the Subject object delivered by the Realm with Principals, Role Principals and Credentials. The authentication and the mapping of my user defined roles to tomcat roles work fine, but I can´t get a reference to the Subject object in my servlets. I have tried: AccessControlContext context = AccessController.getContext(); Subject subject = Subject.getSubject(context); But it´s not working... subject = null; Can anybody help me, please ? Rogerio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !DSPAM:42dc431c292681154681485!
Re: JAASRealm and Subject
Jo, Thanks for the hint. I think that your comment, along with the section labelled How can I access members of a custom Realm or Principal? here: http://wiki.apache.org/jakarta-tomcat/HowTo might allow the Principal to be allowed. I can get to request.getUserPrincipal().getName(), but I haven't tried the cast yet. If that works, that would at least allow me to get to the credentials, etc. that get populated by the LoginModule, if need be. I guess the Subject is inaccessible directly though, but I think that's suppose to be the same as request.getRemoteUser if the user has been authenticated, right? Jim Jo wrote: Is casting request.getUserPrincipal() to your custome-made Principal gonna help get what you want ? Jojada.- - Original Message - From: ohaya [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Tuesday, July 19, 2005 9:46 AM Subject: Re: JAASRealm and Subject Rogerio, Try taking a look at this page: http://www.kopz.org/public/documents/tomcat/jaasintomcat.html I read through this awhile ago, but as I was just re-reading it for maybe the 10th time, I think that I'm starting to see the light and understand what the page's author (Michiel Toneman) was trying to say, and the problem (with JAAS and Tomcat) that he was trying to describe and work around. In the 1st paragraph, he says: This is because the principals are used to denote the concepts of user and role, and are no longer available in the security context in which the webapp is executed. The result of the authentication is available only through request.getRemoteUser() and request.isUserInRole(). I think that what he is trying to say is that when you use JAAS normally with Tomcat (e.g., configure a JAASRealm), the only artifacts from the LoginModule that servlets and JSPs have access to are the user (via request.getRemoteUser()) and the user's roles (via calls to request.isUserInRole()). Putting it another way, I think that the author is saying that your JSPs and servlets under Tomcat simply cannot access things like the Subject, the Principals, etc. So, this page is about his proposed workaround for this. From what I can tell, the way that he does this is that he has a SecurityFilter, which gets invoked BEFORE the LoginModule, and this SecurityFilter populates the Subject into the HTTP session before creating the context and invoking the LoginModule. In other words, this SecurityFilter kind of wedges itself between Tomcat and the LoginModule, I think, and by doing that, the Subject, etc. are now no longer lost to being accessed by servlets/JSPs. If you have a chance, please take a look at the above link, and see if you read this page the same way that I do? Comments from anyone else would be greatly appreciated, as I am very curious about this. It's not so much that I can't seem to access the Subject, but it seems like with the Tomcat environment, any work that the LoginModule does to populate the Principals, etc. seems to be totally inaccessible to servlets and JSPs? Thanks, and apologies for the longish message... Jim ohaya wrote: Hi, I'm not 100% sure if this is applicable, but I just found this: Due to a design oversight in the JAAS 1.0, javax.security.auth.Subject.getSubject() does not return the Subject associated with the thread of execution inside a java.security.AccessController.doPrivileged() code block. This can present a inconsistent behavior that is problematic and causes undesirable effort. com.ibm.websphere.security.auth.WSSubject provides a work around to associate Subject to thread of execution. com.ibm.websphere.security.auth.WSSubject extends the JAAS authorization model to J2EE resources. in this thread: http://groups-beta.google.com/group/comp.lang.java.security/browse_thread/thread/3fbba23648cfb556/b736a3b0f27fc170?q=get+subject+loginmodulernum=21#b736a3b0f27fc170 If the above is applicable, then I don't know what the equivalent workaround would be for Tomcat? Jim ohaya wrote: Rogerio, I've been wrestling with this exact same problem, but haven't had any more success than you have had thus far, so if you find out the answer to this, can you please post a msg here? I'll do the same... Thanks, Jim Rogerio Baldini das Neves wrote: Hi! I'm using the Tomcat 5 JAASRealm for authenticating users with my own LoginModule. In my LoginModule I am populating the Subject object delivered by the Realm with Principals, Role Principals and Credentials. The authentication and the mapping of my user defined roles to tomcat roles work fine, but I can´t get a reference to the Subject object in my servlets. I have tried: AccessControlContext context =
how to update web.xml when using WAR file
I am following the instructions for configuring a DataSource so that I can use a MySQL databasae with my servlets. The instructions I am using can be found at: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jndi-datasource-examples-howto.html According to the instructions, I must update the web.xml file in my WEB-INF directory. How can I update this file if the vendor has only supplied a WAR file? Do I need to unpack the WAR file and update the web.xml file ? Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unable to use Python/CGI from Tomcat....
I'm attempting to set up our Tomcat server to run ViewCVS, which is a Python application. I've set up Python on my Solaris 8 box. I've noticed that to start python, I need to include a library (libgdbm.so.3) in my LD_LIBRARY_PATH. Which I do, and Python starts up fine. I've copied the cgi script into the appropriate directory in my Tomcat server. CGI is enabled, because we have other scripts being executed from within Tomcat. But whenever I attempt to call the new Python script, I get the error... 2005-07-19 14:14:32 cgi: runCGI (stderr):ld.so.1: /ct/ctapp/python241/bin/python: fatal: libgdbm.so.3: open failed: No such file or directory Which looks a lot like the error I get if that library is not in my LD_LIBRARY_PATH. I've mucked around with startup.sh to displayed that the processes starting the Tomcat JVM does have this library in it's environment. But whatever is executing the CGI script from within the JVM is not passing along the environment variables. The servlet definition in my web.xml looks like... servlet servlet-namecgi/servlet-name servlet-classorg.apache.catalina.servlets.CGIServlet/servlet-class init-param param-nameclientInputTimeout/param-name param-value100/param-value /init-param init-param param-namedebug/param-name param-value6/param-value /init-param init-param param-namecgiPathPrefix/param-name param-valuecgi-bin/param-value /init-param init-param param-nameexecutable/param-name param-value/usr/bin/ksh/param-value /init-param init-param param-namepassShellEnvironment/param-name param-valuetrue/param-value /init-param load-on-startup5/load-on-startup /servlet So, because passShellEnvironment is true, I expected the shell environment to be passed along to the cgi script. It doesn't seem to be. Am I missing something else? Surely I can't be the first one to come up against this? Thanks for any help, Ed Do you Yahoo!? Messenger 7.0 beta: Free worldwide PC to PC calls http://au.beta.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
