RE: [tomcat 7 migartion] cannot load images with jsession id in url
Thanks you were correct. It was my code. Though my code did work in tomcat 6 which I very surprising... Found the bug in my code... -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Thursday, June 23, 2011 2:54 AM To: Tomcat Users List Subject: Re: [tomcat 7 migartion] cannot load images with jsession id in url 2011/6/22 Guy Katz gk...@allot.com: Hi all; I am migrating to tomcat 7 from 6. In tomcat 6 urls like http://68.169.51.83:8080/gallery/wave_surfing_gallery_thumb_652.jpg;js es sionid=A859D830090798F238DABADC713C1327 would load an image but in tomcat 7 I get the following response: The Image . cannot be displayed because it contains errors First you will have to find, what the difference is. - corrupted file (e.g. by transferring a binary file as text over FTP, or using a Writer to serve binary data) - truncated file - wrong response headers E.g. with wget --save-headers If Tomcat 7 were not able to serve images it would have been noted a long ago. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org ## This message is intended only for the designated recipient(s).It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ## - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
On 22.06.2011 19:20, Jess Holle wrote: On 6/22/2011 10:16 AM, Jess Holle wrote: The only issue I found at this level is that both tomcat-juli-adapters.jar and tomcat-juli-adapters.jar are scanned. I'd think that all the Tomcat extras jars should be in Tomcat's out-of-the-box list of jars to be ignored -- unless they actually shouldn't be ignored, of course. That's a rather minor issue, though -- and presumably accounts for very, very little of the startup time. By coincidence I added them in 3 days ago (r1137541 and r1137754) :) Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Logging level change
Do i need to make any chnages in the logging.properties file? I tried making everything from FINE to WARNING and also i tried adding org.apache.catalina.level=WARNING in the logging.properties, it somehow worked. But Is this the way it should behave or we need to make changes in my java code as well using that LogManager etc. Could you help me? Konstantin Kolinko wrote: 2011/6/22 Roshni Basu roshni...@gmail.com: Tomcat version is 6.0.9. You know, 6.0.32 is out there... http://tomcat.apache.org/security-6.html Here is my snippet of code: LogManager logManager = LogManager.getLogManager(); EnumerationString e = logManager.getLoggerNames(); It won't work, because the LogManager implementation used by Tomcat (see docs for details) provides isolation for different webapps (class loaders). You code will affect only single webapp, and will have zero effect on anything else. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://old.nabble.com/Tomcat-Logging-level-change-tp31902405p31909658.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Logging level change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roshni, On 6/23/2011 4:49 AM, Roshni Basu wrote: Do i need to make any changes in the logging.properties file? That's typically how logging is configured. I tried making everything from FINE to WARNING and also i tried adding org.apache.catalina.level=WARNING in the logging.properties, it somehow worked. Did you read the documentation? The file itself is documented, somewhat, also. Remember that each logger can be configured differently. So, if you configure one logger to be level=WARN, other loggers may default to something else. But Is this the way it should behave or we need to make changes in my java code as well using that LogManager etc. Could you help me? I would do this at the configuration-file level. As Konstantin points out, webapps aren't allowed to change the logging configuration for the server. That would be a security problem, don't you think? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4DVIYACgkQ9CaO5/Lv0PDi2gCfbmaX2Y0yud3YXk16Y/db79Lr ZkQAn18f6dSmxGcMLM0YnZeUjcQRic+f =Ilci -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: crlFile and SunX509 algorithm in Tomcat 7.0.16
Can you confirm that the patches to apply to solve this issue are the following ones: r1138550 and r1138555? Martin On Wed, Jun 22, 2011 at 5:16 PM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 20:03, Martin Dubuc wrote: Mark, Thanks for looking into this and working to get the patch in for future versions. It will allow us to use later versions of Tomcat and not be stuck on 7.0.10. If you would like me to test the patch, I can rebuild from patched source and test locally. Please. It would be good to get confirmation that it is now working as intended. Mark Martin On Wed, Jun 22, 2011 at 12:46 PM, Mark Thomas ma...@apache.org wrote: Tomcat 6.0.x looks to be OK. There is a copy/paste problem in 7.0.x that I'll fixed shortly. If you are willing to build Tomcat 7.0.x from source (not hard) then it will be easy for you to test the patch. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: crlFile and SunX509 algorithm in Tomcat 7.0.16
On 23/06/2011 16:30, Martin Dubuc wrote: Can you confirm that the patches to apply to solve this issue are the following ones: r1138550 and r1138555? r1138550 is purely cosmetic. r1138555 is the patch that should fix this. Mark Martin On Wed, Jun 22, 2011 at 5:16 PM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 20:03, Martin Dubuc wrote: Mark, Thanks for looking into this and working to get the patch in for future versions. It will allow us to use later versions of Tomcat and not be stuck on 7.0.10. If you would like me to test the patch, I can rebuild from patched source and test locally. Please. It would be good to get confirmation that it is now working as intended. Mark Martin On Wed, Jun 22, 2011 at 12:46 PM, Mark Thomas ma...@apache.org wrote: Tomcat 6.0.x looks to be OK. There is a copy/paste problem in 7.0.x that I'll fixed shortly. If you are willing to build Tomcat 7.0.x from source (not hard) then it will be easy for you to test the patch. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Servlet input/output streams
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ronald, On 6/22/2011 11:23 AM, Ronald Albury wrote: My understanding is that I should *not* close the servlet input/output streams (if you don't open them - you shouldn't close them) That seems like good advice. But what if I have wrapped those streams inside other streams that I want to close? Let's say I have several layers of object streams, cipher streams, compression streams, etc. Will it be ok to call close on the outer-most stream, or do I need to rely on the 'flush' and 'finish' methods on these wrapping streams. Many stream decorators implement the close() method as an internal operation (digest.doFinal, for example) plus a call to the contained stream's close() method, resulting in the underlying stream being closed. The Javadoc for OutputStream.close says The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened.. That seems like most decorators should call inner.close() when their close methods are called. If you are using something like a CipherOutputStream, just make sure that you have flushed the stream and/or called any other finish methods as appropriate. What about the potential for memory leaks - or is that mostly just an issue on the inner-most stream that actually does the physical I/O? Any open stream should be closed at some point. It's the underlying stream that really consumes resources. As long as your decorator has flushed everything it had to the underlying stream, it will be GC'd at some point and you'll be okay. Let the code that opened the stream also close the stream. Those decorators aren't going to hurt you. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4DYdoACgkQ9CaO5/Lv0PDyTQCfeG09m8n3ul5bqqUOZZMYZlly DvYAnivBVP7/gXd+zgV+wD+qn0ITN84M =4frT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SSL received a record that exceeded the maximum permissible length
I'm trying to set up Tomcat6 for SSL. I created keystore and edited server.xml. When I try to access a page such as https://localhost:8443 I get following response in browser: SSL received a record that exceeded the maximum permissible length. Using Wireshark I can see that Tomcat responds with error 400 bad request in plain text. There no errors or warnings in Tomcat log file. What can be wrong? Thanks.
getAllClusterSessions gives OptionalDataException
Hi,
I have an exception when one on my Tomcat nodes restarts. The session are not
synced and user complain about being logged out. I was running 6.0.32 and had
the problem. Now I'm running a custom build of 6.0.33 from yesterday. I added a
little code which prints ' SEVERE: name=user'. The key on which the sync fails
while reading the value.
I looked into the java code in ObjectInputStream and it looks like some
inconsistency in the ObjectStream.
I have 4 nodes on Debian 5, sun-java6-jdk 6-22-0lenny1, seen the problem on
Tomcat 6.0.29, 6.0.32 and a custom build 6.0.33. I can't reproduce this (yet)
on my test environment, so debugging it is difficult without upset customers.
Engine name=Catalina defaultHost=xxx.xxx.xxx
Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase /
Cluster
className=org.apache.catalina.ha.tcp.SimpleTcpCluster
Channel
className=org.apache.catalina.tribes.group.GroupChannel
Membership
className=org.apache.catalina.tribes.membership.McastService port=47727 /
/Channel
/Cluster
Host name=xxx.xxx.xxx
appBase=/data/webapps/crm-LIVE/deployed
unpackWARs=true autoDeploy=false
xmlValidation=false xmlNamespaceAware=true
/Host
/Engine
Can I provide more information? Where should I look.
NB: In some previous mails about another problem I thought that might be the
reason for my logout problem, that is why I tried 6.0.33-dev.
Ronald.
Jun 23, 2011 5:49:47 PM org.apache.catalina.ha.session.DeltaManager
getAllClusterSessions
WARNING: Manager [crm.realworks.nl#], requesting session state from
org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, 0, 10,
110}:4000,{10, 0, 10, 110},4000, alive=45370885,id={-34 112 102 -93 -87 -88 77
18 -113 -30 62 8 62 -65 -112 -13 }, payload={}, command={}, domain={}, ]. This
operation will timeout if no session state has been received within 60 seconds.
Jun 23, 2011 5:49:47 PM org.apache.catalina.ha.session.DeltaManager
waitForSendAllSessions
INFO: Manager [crm.realworks.nl#]; session state send at 6/23/11 5:49 PM
received in 304 ms.
Jun 23, 2011 5:49:47 PM org.apache.catalina.ha.session.DeltaManager
getAllClusterSessions
WARNING: Manager [crm.realworks.nl#]: Drop message SESSION-ACCESSED inside
GET_ALL_SESSIONS sync phase start date 6/23/11 5:49 PM message date 6/23/11
5:49 PM
Jun 23, 2011 5:49:47 PM org.apache.catalina.ha.session.DeltaSession readObject
SEVERE: name=user.
Jun 23, 2011 5:49:47 PM org.apache.catalina.ha.session.DeltaManager
deserializeSessions
SEVERE: IOException while loading persisted sessions:
java.io.OptionalDataException
java.io.OptionalDataException
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at java.util.HashMap.readObject(HashMap.java:1029)
at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at
org.apache.catalina.ha.session.DeltaSession.readObject(DeltaSession.java:655)
at
org.apache.catalina.ha.session.DeltaSession.readObjectData(DeltaSession.java:481)
at
org.apache.catalina.ha.session.DeltaManager.deserializeSessions(DeltaManager.java:745)
at
org.apache.catalina.ha.session.DeltaManager.handleALL_SESSION_DATA(DeltaManager.java:1583)
at
org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1440)
at
org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1173)
at
org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:92)
at
org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:901)
at
org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:882)
at
org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:269)
at
Re: Apache/Tomcat_means...?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dennis, On 6/22/2011 12:26 PM, Dennis de Champeaux wrote: And someone else please explains better - at a high level: - the functionality where they overlap Both are high-performance HTTP servers. - the functionality where they differ Tomcat can run Java servlets while httpd cannot. httpd can be used as a proxy out-of-the-box while Tomcat cannot. httpd is more appropriate for certain solutions (Perl/PHP, CGI, etc.) than Tomcat. httpd has more authentication options than Tomcat. - what is to be done if they are to be integrated Use one of the proxying modules: mod_jk, mod_proxy_http, mod_proxy_ajp. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4DjSUACgkQ9CaO5/Lv0PA6XgCfQckzSymMKwKzM4XcE+1MVZ/F yFgAnRXKI5UfbU2ad+UN+tEnmCjIzYcU =emRA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Dreaded No Java compiler available
Greetings, I am launching an embedded Apache Tomcat 7.0.14, everything except JSPs are working fine (static resources, servlets, filters, etc). I have set JAVA_HOME to a location which does have bin/javac and lib/tools.jar, and otherwise does appear to be a fully working JDK. However, I take the following exception: SEVERE: Exception Processing ErrorPage[errorCode=404, location=/error-pages/404.jsp] Throwable occurred: org.apache.jasper.JasperException: java.lang.IllegalStateException: No Java compiler available at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:570) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:378) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:473) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:402) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:329) at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:466) at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:387) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:181) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919) at java.lang.Thread.run(Thread.java:736) Caused by: java.lang.IllegalStateException: No Java compiler available at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:231) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:586) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:344) ... 21 more My project has the following Apache Tomcat dependencies (all 7.0.14): dependency groupIdorg.apache.tomcat/groupId artifactIdtomcat-util/artifactId /dependency dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-core/artifactId /dependency dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-jasper/artifactId /dependency dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-logging-juli/artifactId /dependency I am not finding any corresponding jasper-compiler or jasper-compiler-jdt with the 7.x version scheme. Sorry, but what am I doing wrong? Thanks, -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fw: Re: Apache/Tomcat_means...?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dennis, On 6/23/2011 3:32 PM, Dennis de Champeaux wrote: Dear Christopher Schultz That happens to be my real name: no air quotes necessary :) I did not asked this for myself. Rather on behalf of the original poster which was 'send in the forest', likely, with the legalistic/ historic explanation. Ok. This mailing list could need some communication therapy - I believe There are actually more problems around ... Such as...? I solved the problem I raised last Friday. I got 3 responses. One was very helpful. The two others were true disasters. You get what you pay for. Anyone can join the list, and anyone can post anything (within reason). There are some known idiots that frequent the list, and those of us who know what we are talking about will generally reply to useless posts and indicate that they are useless. I'm sorry if someone steered you in the wrong direction. Would it make sense to post: - resources I found for the virtual host challenge Any time you solve an issue that you posted to the list, you should post-back with your solution. Then it makes it into the list archives and people can search them for answers (though they often do not). - an illustration what is wrong with the TC documentation using what it advices about virtual hosts Certainly. Tomcat is a community-build and community-supported product. If all anyone ever does is complain, nothing improves. Volunteering to identify specific problems and suggest fixes is how this community grows. I start to wonder whether architectural defects in TC start making life difficult for: -- volunteer/ developers because the code starts 'fighting back' and the documentation suffers Note that all developers are volunteers, though some have employers who pay them to be volunteers. It's kind of a cliche that OSS has crappy documentation, but let's face it: documentation is no fun, and nobody's paying anyone to do it. If you have suggestions for improvement, please make them. -- end users because the documentation is written from the perspepctive how it works instead of the purpose with clear snapshot examples True, most of the documentation has been written by the authors of the code, not by the end users. But you can change all that...! Developers are exasperated; users are baffled. I'm not sure the level of bafflement quite reaches as high as you suggest. My summary of a week of watching the show. I've been watching the show for years, and most people who come here get real help. Many of them stay and help others. Still others end up contributing directly to the project. You could be one of them. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4DmeUACgkQ9CaO5/Lv0PBzPACcDKeGO3SJweecvfEbiuWjcQcP eEIAnjVHlKgBU8s4A/8FrhrKNKuBR9z1 =cjoq -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Dreaded No Java compiler available
From: Jesse Farinacci [mailto:jie...@gmail.com] Subject: Dreaded No Java compiler available I am launching an embedded Apache Tomcat 7.0.14 JDK version? Platform? (Probably not relevant in this case, but it helps to know the full environment.) I have set JAVA_HOME to a location which does have bin/javac and lib/tools.jar, and otherwise does appear to be a fully working JDK. The default Tomcat JSP mechanism hasn't used the Java compiler from the JDK for several years now. Throwable occurred: org.apache.jasper.JasperException: java.lang.IllegalStateException: No Java compiler available Tomcat 7 JSP handling normally uses the Eclipse JDT compiler from lib/ecj-3.6.2.jar; is that jar accessible to the Tomcat classloader in your embedded environment? Are you trying to run this from an IDE? What happens if you execute the application directly? (IDEs often obfuscate the situation by choosing to use their own configuration settings.) - 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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Dreaded No Java compiler available
2011/6/23 Jesse Farinacci jie...@gmail.com: Greetings, I am launching an embedded Apache Tomcat 7.0.14, everything except JSPs are working fine (static resources, servlets, filters, etc). I have set JAVA_HOME to a location which does have bin/javac and lib/tools.jar, and otherwise does appear to be a fully working JDK. However, I take the following exception: (...) My project has the following Apache Tomcat dependencies (all 7.0.14): dependency groupIdorg.apache.tomcat/groupId artifactIdtomcat-util/artifactId /dependency dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-core/artifactId /dependency dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-jasper/artifactId /dependency dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-logging-juli/artifactId /dependency I am not finding any corresponding jasper-compiler or jasper-compiler-jdt with the 7.x version scheme. Sorry, but what am I doing wrong? They do not exist. (Have you looked into zip distribution?) Latest Tomcat 6 and Tomcat 7 do use the ecj compiler from Eclipse IDE project directly, without repacking it. If you are struggling with maven, some discussion of troubles with downloading ecj is here: https://issues.apache.org/bugzilla/show_bug.cgi?id=50604#c1 I think you can search for ecj in this mailing list archives and find several discussions there. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fw: Re: Apache/Tomcat_means...?
On Thu, Jun 23, 2011 at 12:54 PM, Christopher Schultz ch...@christopherschultz.net wrote: - an illustration what is wrong with the TC documentation using what it advices about virtual hosts True, most of the documentation has been written by the authors of the code, not by the end users. Though I can vouch that is not true of the virtual hosting how-to :-) In any case, non-specific references to documentation problems are not particularly helpful. Perhaps the OP would like to suppy details? As you say, this is a community effort. -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Dreaded No Java compiler available
Greetings, On Thu, Jun 23, 2011 at 4:37 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: Latest Tomcat 6 and Tomcat 7 do use the ecj compiler from Eclipse IDE project directly, without repacking it. If you are struggling with maven, some discussion of troubles with downloading ecj is here: https://issues.apache.org/bugzilla/show_bug.cgi?id=50604#c1 Thank you, Konstantin! Adding the following solved my issue: dependency groupIdorg.eclipse.jdt.core.compiler/groupId artifactIdecj/artifactId version3.5.1/version scoperuntime/scope /dependency I am now able to compile my JSPs on the fly, automatically, in Apache Tomcat. Despite Mark's comments about bulky downloads in the link you gave earlier, I find it adds only ~1.5Mb to the already dense ~25Mb executable jar which I'm building. Thank you, -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JULI prefix not recognized?
Hi Konstantin: I added the following argument to the Apache Tomcat Server Run Configuration: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager It worked just as you suggested it would; however, it requires the argument be placed in the VM arguments section. I have many small clients that on occassion share VMs with other Tomcat Servers. Is there a way to do the same without the Runtime Argument? Thanks much. TC Konstantin Kolinko wrote: 2011/6/23 throwsCode donmillho...@yahoo.com: I sure that is going to turnout to be a stupid question but I've played with it for two days and made no progress. I can create a JULI handler as long as I don't apply a prefix, here is the logging.properties file (keeping it as simple as possible): Can't load log handler 1pae.org.apache.juli.FileHandler java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler (...) at java.util.logging.LogManager.loadLoggerHandlers(Unknown Source) at java.util.logging.LogManager.initializeGlobalHandlers(Unknown Source) You are using wrong LogManager. You need to use org.apache.juli.ClassLoaderLogManager and not the default one. See how catalina.sh does it. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://old.nabble.com/JULI-prefix-not-recognized--tp31907205p31915598.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat failed to accept SSL connection in jvm mode
Hi, I start tomcat in jvm mode by 'Monitor Tomcat' UI,google chrome gets error: 107 (net::ERR_SSL_PROTOCOL_ERROR), IE 9.0 cannot open SSL connection too. In 'Startup' tab of 'Monitor Tomcat' UI, there are 2 different results: 1. when field 'mode' is set to 'jvm', browser cannot open SSL connection. 2. when field 'mode' is set to 'java', browser opened SSL connection successfully. %JAVA_HOME% points to IBM JRE, in 'java' mode, it can work, failed in jvm mode. all files in logs folder don't report exceptions/errors. in conf/server.xml, only updated all connectors to bind to 192.168.1.10:80/443/9009. is this a bug or settings related? thanks 2011-06-24 daniel.yeung.biz
Re: JULI prefix not recognized?
2011/6/24 throwsCode donmillho...@yahoo.com: Hi Konstantin: I added the following argument to the Apache Tomcat Server Run Configuration: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager It worked just as you suggested it would; however, it requires the argument be placed in the VM arguments section. I have many small clients that on occassion share VMs with other Tomcat Servers. Is there a way to do the same without the Runtime Argument? Embedding? I am afraid that there is no other way. This property configures java.util.logging implementation used by VM. IIRC in java.util.logging there exists a method that allows to reset logging configuration, but I think it only allows to reconfigure handlers, and does not support replacing LogManager at runtime. You can look into JRE sources to see at what time the value of java.util.logging.manager property is being read. (*) You may have better luck by configuring Tomcat to use log4j (see relevant section in our logging.html). With log4j you can go without ClassLoaderLogManager and without logging.properties, but there is one caveat: - Tomcat (using commons-logging) and webapps that use commons-logging will detect presence of log4j and use it instead of java.util.logging - Any web-applications that use java.util.logging will try to use default LogManager implementation, and will suffer from PermGen memory leaks during redeployments and restarts. Because default LogManager from JRE will keep their classes in memory. The (*) is theory. I have not tested it in practice. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat failed to accept SSL connection in jvm mode
2011/6/24 daniel.yeung.biz daniel.yeung@gmail.com: Hi, I start tomcat in jvm mode by 'Monitor Tomcat' UI,google chrome gets error: 107 (net::ERR_SSL_PROTOCOL_ERROR), IE 9.0 cannot open SSL connection too. Please read here, starting with When asking questions on the list, please ...: http://tomcat.apache.org/lists.html#tomcat-users In 'Startup' tab of 'Monitor Tomcat' UI, there are 2 different results: 1. when field 'mode' is set to 'jvm', browser cannot open SSL connection. 2. when field 'mode' is set to 'java', browser opened SSL connection successfully. %JAVA_HOME% points to IBM JRE, in 'java' mode, it can work, failed in jvm mode. Guessing about your OS and your environment I suspect you are running different JREs in the above cases. BTW, IIRC JAVA_HOME variable is not applicable at all, when Tomcat is run as a service. Launch 'Configure Tomcat' and see what JRE/JVM path is there. Anyway, you can enable debug logging in the service runner (on one of the pages in the 'Configure Tomcat' dialog). all files in logs folder don't report exceptions/errors. in conf/server.xml, only updated all connectors to bind to 192.168.1.10:80/443/9009. is this a bug or settings related? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
回复: Re: Tomcat failed to accept SSL connection in jvm mode
Hi, Version: Tomcat 5.5.33, O/S: Windows 7. 2011-06-24 daniel.yeung.biz From: Konstantin Kolinko knst.koli...@gmail.com Time: 2011-06-24 07:55 Subject: Re: Tomcat failed to accept SSL connection in jvm mode To: Tomcat Users List users@tomcat.apache.org 2011/6/24 daniel.yeung.biz daniel.yeung@gmail.com: Hi, I start tomcat in jvm mode by 'Monitor Tomcat' UI,google chrome gets error: 107 (net::ERR_SSL_PROTOCOL_ERROR), IE 9.0 cannot open SSL connection too. Please read here, starting with When asking questions on the list, please ...: http://tomcat.apache.org/lists.html#tomcat-users In 'Startup' tab of 'Monitor Tomcat' UI, there are 2 different results: 1. when field 'mode' is set to 'jvm', browser cannot open SSL connection. 2. when field 'mode' is set to 'java', browser opened SSL connection successfully. %JAVA_HOME% points to IBM JRE, in 'java' mode, it can work, failed in jvm mode. Guessing about your OS and your environment I suspect you are running different JREs in the above cases. BTW, IIRC JAVA_HOME variable is not applicable at all, when Tomcat is run as a service. Launch 'Configure Tomcat' and see what JRE/JVM path is there. Anyway, you can enable debug logging in the service runner (on one of the pages in the 'Configure Tomcat' dialog). all files in logs folder don't report exceptions/errors. in conf/server.xml, only updated all connectors to bind to 192.168.1.10:80/443/9009. is this a bug or settings related? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
TC 7.0.16 IllegalStateException thrown by pageContext.include
This was working under TC 6, but I have a tag that extends BodyTagSupport, and in my doStartTag() method I get my JspWRiter 'out' using pageContext.getOut(). I have a bunch of out.write() statements that all work fine. Then I have these: out.write(style type=\text/css\\n/* platform esf.css */\n); pageContext.include(/static/esf/esf.css,true); pageContext.include(docPage.context.getDocumentStyleIncludeUrl(),true); out.write(/style\n); out.write(script type=\text/javascript\\n); pageContext.include(/static/esf/esf.js,true); out.write(/script\n); But the exception IllegalStateException is thrown on the include of the esf.js file. The reason is null, so there's no more details. I find it odd in that the two prior includes works okay, but that third one fails. The file is definitely there (and has been working under TC 6.0 before). If I comment out that include, my tag works fine. What might be causing this? Thanks, David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getAllClusterSessions gives OptionalDataException
are there other versions of Apache Tomcat running in the same cluster?
Check the logs for what members are joining the cluster, then check what
version they are
best
Filip
On 6/23/2011 10:14 AM, Ronald Klop wrote:
Hi,
I have an exception when one on my Tomcat nodes restarts. The session are not synced and user complain about being logged out. I was
running 6.0.32 and had the problem. Now I'm running a custom build of 6.0.33 from yesterday. I added a little code which prints ' SEVERE:
name=user'. The key on which the sync fails while reading the value.
I looked into the java code in ObjectInputStream and it looks like some
inconsistency in the ObjectStream.
I have 4 nodes on Debian 5, sun-java6-jdk 6-22-0lenny1, seen the problem on Tomcat 6.0.29, 6.0.32 and a custom build 6.0.33. I can't
reproduce this (yet) on my test environment, so debugging it is difficult without upset customers.
Engine name=Catalina defaultHost=xxx.xxx.xxx
Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase /
Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
Channel className=org.apache.catalina.tribes.group.GroupChannel
Membership className=org.apache.catalina.tribes.membership.McastService
port=47727 /
/Channel
/Cluster
Host name=xxx.xxx.xxx
appBase=/data/webapps/crm-LIVE/deployed
unpackWARs=true autoDeploy=false
xmlValidation=false xmlNamespaceAware=true
/Host
/Engine
Can I provide more information? Where should I look.
NB: In some previous mails about another problem I thought that might be the
reason for my logout problem, that is why I tried 6.0.33-dev.
Ronald.
Jun 23, 2011 5:49:47 PM org.apache.catalina.ha.session.DeltaManager
getAllClusterSessions
WARNING: Manager [crm.realworks.nl#], requesting session state from org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, 0, 10,
110}:4000,{10, 0, 10, 110},4000, alive=45370885,id={-34 112 102 -93 -87 -88 77 18 -113 -30 62 8 62 -65 -112 -13 }, payload={}, command={},
domain={}, ]. This operation will timeout if no session state has been received within 60 seconds.
Jun 23, 2011 5:49:47 PM org.apache.catalina.ha.session.DeltaManager
waitForSendAllSessions
INFO: Manager [crm.realworks.nl#]; session state send at 6/23/11 5:49 PM
received in 304 ms.
Jun 23, 2011 5:49:47 PM org.apache.catalina.ha.session.DeltaManager
getAllClusterSessions
WARNING: Manager [crm.realworks.nl#]: Drop message SESSION-ACCESSED inside GET_ALL_SESSIONS sync phase start date 6/23/11 5:49 PM message
date 6/23/11 5:49 PM
Jun 23, 2011 5:49:47 PM org.apache.catalina.ha.session.DeltaSession readObject
SEVERE: name=user.
Jun 23, 2011 5:49:47 PM org.apache.catalina.ha.session.DeltaManager
deserializeSessions
SEVERE: IOException while loading persisted sessions:
java.io.OptionalDataException
java.io.OptionalDataException
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at java.util.HashMap.readObject(HashMap.java:1029)
at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at
org.apache.catalina.ha.session.DeltaSession.readObject(DeltaSession.java:655)
at
org.apache.catalina.ha.session.DeltaSession.readObjectData(DeltaSession.java:481)
at
org.apache.catalina.ha.session.DeltaManager.deserializeSessions(DeltaManager.java:745)
at
org.apache.catalina.ha.session.DeltaManager.handleALL_SESSION_DATA(DeltaManager.java:1583)
at
org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1440)
at
org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1173)
at
org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:92)
at
org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:901)
at
org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:882)
at
org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:269)
at
Re: TC 7.0.16 IllegalStateException thrown by pageContext.include
out.write(script type=\text/javascript\\n); pageContext.include(/static/esf/esf.js,true); out.write(/script\n); But the exception IllegalStateException is thrown on the include of the esf.js file. The reason is null, so there's no more details. I find it odd in that the two prior includes works okay, but that third one fails. The file is definitely there (and has been working under TC 6.0 before). When I change the code to use /static/esf/esf.javascript and rename the file to have the same suffix, the exception is not thrown. Is there anything special about the .js suffix on a file for pageContext.include()? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC 7.0.16 IllegalStateException thrown by pageContext.include
out.write(script type=\text/javascript\\n); pageContext.include(/static/esf/esf.js,true); out.write(/script\n); But the exception IllegalStateException is thrown on the include of the esf.js file. The reason is null, so there's no more details. I find it odd in that the two prior includes works okay, but that third one fails. The file is definitely there (and has been working under TC 6.0 before). When I change the code to use /static/esf/esf.javascript and rename the file to have the same suffix, the exception is not thrown. Is there anything special about the .js suffix on a file for pageContext.include()? Okay, I learned that this is because web.xml for TC 6 uses: mime-mapping extensionjs/extension mime-typetext/javascript/mime-type /mime-mapping But TC 7 uses: mime-mapping extensionjs/extension mime-typeapplication/javascript/mime-type /mime-mapping If I put the old TC 6 version in my app's web.xml, then it works again. Question: Is this to be expected? Is TC 7 doing the right thing here? Am I breaking something when I update my app's web.xml to say it's 'text' again? Seems like javascript is really text, and so treating as something else is not correct, even if the mime type is correctly supposed to be application/javascript. Maybe TC needs to know this particular mime type is text and not binary data? David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JULI prefix not recognized?
Thanks Konstantin: I appreciate all the great information. I'm going to look into log4j while I'm involved with logging. Hopefully by the end there will be a clear winner between java.util.logging, JULI, and log4j, based on our needs. Much Thanks. TC Konstantin Kolinko wrote: 2011/6/24 throwsCode donmillho...@yahoo.com: Hi Konstantin: I added the following argument to the Apache Tomcat Server Run Configuration: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager It worked just as you suggested it would; however, it requires the argument be placed in the VM arguments section. I have many small clients that on occassion share VMs with other Tomcat Servers. Is there a way to do the same without the Runtime Argument? Embedding? I am afraid that there is no other way. This property configures java.util.logging implementation used by VM. IIRC in java.util.logging there exists a method that allows to reset logging configuration, but I think it only allows to reconfigure handlers, and does not support replacing LogManager at runtime. You can look into JRE sources to see at what time the value of java.util.logging.manager property is being read. (*) You may have better luck by configuring Tomcat to use log4j (see relevant section in our logging.html). With log4j you can go without ClassLoaderLogManager and without logging.properties, but there is one caveat: - Tomcat (using commons-logging) and webapps that use commons-logging will detect presence of log4j and use it instead of java.util.logging - Any web-applications that use java.util.logging will try to use default LogManager implementation, and will suffer from PermGen memory leaks during redeployments and restarts. Because default LogManager from JRE will keep their classes in memory. The (*) is theory. I have not tested it in practice. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://old.nabble.com/JULI-prefix-not-recognized--tp31907205p31916749.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC 7.0.16 IllegalStateException thrown by pageContext.include
On 24.06.2011 03:47, David Wall wrote: out.write(script type=\text/javascript\\n); pageContext.include(/static/esf/esf.js,true); out.write(/script\n); But the exception IllegalStateException is thrown on the include of the esf.js file. The reason is null, so there's no more details. I find it odd in that the two prior includes works okay, but that third one fails. The file is definitely there (and has been working under TC 6.0 before). When I change the code to use /static/esf/esf.javascript and rename the file to have the same suffix, the exception is not thrown. Is there anything special about the .js suffix on a file for pageContext.include()? Okay, I learned that this is because web.xml for TC 6 uses: mime-mapping extensionjs/extension mime-typetext/javascript/mime-type /mime-mapping But TC 7 uses: mime-mapping extensionjs/extension mime-typeapplication/javascript/mime-type /mime-mapping If I put the old TC 6 version in my app's web.xml, then it works again. Question: Is this to be expected? Is TC 7 doing the right thing here? Am I breaking something when I update my app's web.xml to say it's 'text' again? Seems like javascript is really text, and so treating as something else is not correct, even if the mime type is correctly supposed to be application/javascript. Maybe TC needs to know this particular mime type is text and not binary data? We synced all mime types with the definitions from the Apache Web Server. Looking at the IANA MIME type registry http://www.iana.org/assignments/media-types/index.html you can verify, that they list text/javascript as obsolete and application/javascript without restriction. So from a standards point of view it is the right thing, maybe not for usability? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: crlFile and SunX509 algorithm in Tomcat 7.0.16
I can confirm that the patch works. We were able to get Tomcat up and running with the crlFile and the SunX509 algorithm configuration and were able to test that the CRL functionality was working as expected in a patched 7.0.16 version. Thanks, Martin On Thu, Jun 23, 2011 at 11:42 AM, Mark Thomas ma...@apache.org wrote: On 23/06/2011 16:30, Martin Dubuc wrote: Can you confirm that the patches to apply to solve this issue are the following ones: r1138550 and r1138555? r1138550 is purely cosmetic. r1138555 is the patch that should fix this. Mark Martin On Wed, Jun 22, 2011 at 5:16 PM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 20:03, Martin Dubuc wrote: Mark, Thanks for looking into this and working to get the patch in for future versions. It will allow us to use later versions of Tomcat and not be stuck on 7.0.10. If you would like me to test the patch, I can rebuild from patched source and test locally. Please. It would be good to get confirmation that it is now working as intended. Mark Martin On Wed, Jun 22, 2011 at 12:46 PM, Mark Thomas ma...@apache.org wrote: Tomcat 6.0.x looks to be OK. There is a copy/paste problem in 7.0.x that I'll fixed shortly. If you are willing to build Tomcat 7.0.x from source (not hard) then it will be easy for you to test the patch. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
