How to set the session pool size?
Hi, I met a strange problem , that it seems that when the session pool size reaches 25 , exception will throw and my application have to restart then it can be work again.
Re: Reading Data Form MS -execel 2003- in java
yeah , definally POI On 2/23/06, Bill Barker <[EMAIL PROTECTED]> wrote: > > <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > > Hi Forum, > > Did anyone used java program to read data from microsoft excel ? > > Can any one give me pointers where to look for this ?? > > http://jakarta.apache.org/poi/ > > > thanks > > Birendar Singh Waldiya > > Tata Consultancy Services Limited > > Mailto: [EMAIL PROTECTED] > > Website: http://www.tcs.com > > > > > > Notice: The information contained in this e-mail message and/or > > attachments to it may contain confidential or privileged information. If > > you are not the intended recipient, any dissemination, use, review, > > distribution, printing or copying of the information contained in this > > e-mail message and/or attachments to it are strictly prohibited. If you > > have received this communication in error, please notify us by reply > > e-mail or telephone and immediately and permanently delete the message and > > any attachments. Thank you > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
tomcat-users.xml
Hello all and all, I can not reach a "host-manager webapp" where is the mistake my tomcat-users.xml file : < > vincent
What does the number preceding the catalina.org.apache.juli.AsyncFileHandler in Tomcat's conf/logging.properties mean?
Hi, community When I configured Tomcat logs, I found the following configuration in logging.properties 1catalina.org.apache.juli.AsyncFileHandler 2localhost.org.apache.juli.AsyncFileHandler 3manager.org.apache.juli.AsyncFileHandler 4host-manager.org.apache.juli.AsyncFileHandler I am not sure what the numbers in front of them mean? I checked the Tomcat documentation > Logging chapter and found no relevant instructions. I also searched the Tomcat source code repository on Github, and only found document-related content. Can someone explain this please? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What does the number preceding the catalina.org.apache.juli.AsyncFileHandler in Tomcat's conf/logging.properties mean?
Thank you so much. I am ashamed that I did not read the documentation carefully. On Thu, Mar 14, 2024 at 7:46 PM Mark Thomas wrote: > > On 14/03/2024 11:36, Vincent Daniel wrote: > > Hi, community > > > > When I configured Tomcat logs, I found the following configuration in > > logging.properties > > > > 1catalina.org.apache.juli.AsyncFileHandler > > 2localhost.org.apache.juli.AsyncFileHandler > > 3manager.org.apache.juli.AsyncFileHandler > > 4host-manager.org.apache.juli.AsyncFileHandler > > > > I am not sure what the numbers in front of them mean? > > > > I checked the Tomcat documentation > Logging chapter and found no > > relevant instructions. I also searched the Tomcat source code > > repository on Github, and only found document-related content. > > > > Can someone explain this please? > > https://tomcat.apache.org/tomcat-11.0-doc/logging.html > > Search for the word "prefix". > > 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: What does the number preceding the catalina.org.apache.juli.AsyncFileHandler in Tomcat's conf/logging.properties mean?
:) On Thu, Mar 14, 2024 at 7:53 PM Mark Thomas wrote: > > On 14/03/2024 11:51, Vincent Daniel wrote: > > Thank you so much. > > I am ashamed that I did not read the documentation carefully. > > No problem. It is only a single line in the docs and it helps a lot if > you know what you are looking for. > > Mark > > > > > On Thu, Mar 14, 2024 at 7:46 PM Mark Thomas wrote: > >> > >> On 14/03/2024 11:36, Vincent Daniel wrote: > >>> Hi, community > >>> > >>> When I configured Tomcat logs, I found the following configuration in > >>> logging.properties > >>> > >>> 1catalina.org.apache.juli.AsyncFileHandler > >>> 2localhost.org.apache.juli.AsyncFileHandler > >>> 3manager.org.apache.juli.AsyncFileHandler > >>> 4host-manager.org.apache.juli.AsyncFileHandler > >>> > >>> I am not sure what the numbers in front of them mean? > >>> > >>> I checked the Tomcat documentation > Logging chapter and found no > >>> relevant instructions. I also searched the Tomcat source code > >>> repository on Github, and only found document-related content. > >>> > >>> Can someone explain this please? > >> > >> https://tomcat.apache.org/tomcat-11.0-doc/logging.html > >> > >> Search for the word "prefix". > >> > >> 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 > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat / Oracle JDBC OracleTimeoutPollingThread memory leak?
Our Tomcat instance is configured to create a heap dump on out of memory conditions, and we often see a large amount of memory allocated to OracleTimeoutPollingThread. For example, here is once such instance: 465,922Kb (57.4%) Object tree for GC root(s) Java Static oracle.jdbc.driver.OracleTimeoutThreadPerVM.watchdog Leak candidate(s) found Root object oracle.jdbc.driver.OracleTimeoutPollingThread@c492d2c0oracle<https://forums.oracle.com/ords/apexds/user/c492d2c0oracle>.jdbc.driver.OracleTimeoutPollingThread(name : "OracleTimeoutPollingThread", priority : 10, threadQ : null, eetop : 392972288, single_step : false, daemon : true, stillborn : false, target : null, group : j.l.ThreadGroup@c02fa828<mailto:j.l.ThreadGroup@c02fa828>, contextClassLoader : org.apache.catalina.loader.ParallelWebappClassLoader@c02fb4c8<https://forums.oracle.com/ords/apexds/user/c02fb4c8>, inheritedAccessControlContext : java.security.AccessControlContext@c492d448<mailto:java.security.AccessControlContext@c492d448>, threadLocals : null, inheritableThreadLocals : j.l.ThreadLocal$ThreadLocalMap(size: 2), stackSize : 0, nativeParkEventPointer : 0, tid : 119, threadStatus : 225, parkBlocker : null, blocker : null, blockerLock : Object@c492d660, uncaughtExceptionHandler : null, threadLocalRandomSeed : 0, threadLocalRandomProbe : 0, threadLocalRandomSecondarySeed : 0, knownTimeouts : oracle.jdbc.driver.OracleTimeoutThreadPerVM[](size: 32), count : 20, sleepMillis : 1000) 1. oracle.jdbc.driver.OracleTimeoutPollingThread ↘465,922Kb (57.4%), self 136b (< 0.1%), 1 object(s) I came across the following note: Oracle JDBC driver, at least in some versions (such as ojdbc6), have a timeout detection thread, _oracle.jdbc.driver.OracleTimeoutPollingThread_, that according to reports has as its context classloader the classloader of the web application from which the first JDBC connection is requested, even if the driver itself resides on the server level. It seem this can be prevented by loading the class _oracle.jdbc.driver.OracleTimeoutThreadPerVM_ using the system classloader before any JDBC connections are opened, which can be achieved in _contextInitialized()_ of our _ServletContextListener_<https://java.jiderhamn.se/2012/01/01/classloader-leaks-ii-find-and-work-around-unwanted-references/#cleanup>. (Thanks to Hal Deadman for the report!) Ref: https://java.jiderhamn.se/category/classloader-leaks/ Is the above GC root, an example of the above condition? We are using the following: Oracle JDBC driver version 18.3.0.0.0 Tomcat 9.0.60. If so, can this be mitigated using the JreMemoryLeakPreventionListener, as illustrated in the Tomcat documentation, here -- https://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html#JreMemoryLeakPreventionListener_Examples? Thank you, Vincent
Tomcat Native 1.2.30 -- Windows 2016 TLSv1.3 support?
Hello all, We have an application packaged with Tomcat Native 1.2.30, which, per the following, the Windows binaries were built using OpenSSL 1.1.1k: https://www.mail-archive.com/dev@tomcat.apache.org/msg152993.html However, per Microsoft, Windows 2016 does not support TLSv1.3: https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp- Do Tomcat Native or OpenSSL depend upon support for TLSv1.3 in the underlying OS? Thank you, Vincent
RE: [External] Re: Tomcat Native 1.2.30 -- Windows 2016 TLSv1.3 support?
Ok -- makes sense. Thank you, Vincent -Original Message- From: Christopher Schultz Sent: Tuesday, April 25, 2023 10:28 AM To: users@tomcat.apache.org Subject: [External] Re: Tomcat Native 1.2.30 -- Windows 2016 TLSv1.3 support? WARNING: This message has originated from an External Source. This may be a phishing email that can result in unauthorized access to Honeywell systems. Please use proper judgment and caution when opening attachments, clicking links or responding. Vincent, On 4/25/23 05:14, Mark Thomas wrote: > On 24/04/2023 20:15, Ragosta, Vincent wrote: >> Hello all, >> >> We have an application packaged with Tomcat Native 1.2.30, which, per >> the following, the Windows binaries were built using OpenSSL 1.1.1k: >> >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >> .mail-archive.com%2Fdev%40tomcat.apache.org%2Fmsg152993.html&data=05% >> 7C01%7CVincent.Ragosta%40honeywell.com%7C70f0a3eb5dc94a74900708db4599 >> 4f40%7C96ece5269c7d48b08daf8b93c90a5d18%7C0%7C0%7C638180297054464718% >> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I >> k1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=q0CbLjS0uMiZz1xCezTSXQMr9 >> xEiDPwaBZubhLa4XkE%3D&reserved=0 >> >> However, per Microsoft, Windows 2016 does not support TLSv1.3: >> >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flea >> rn.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fsecauthn%2Fprotocols-in- >> tls-ssl--schannel-ssp-&data=05%7C01%7CVincent.Ragosta%40honeywell.com >> %7C70f0a3eb5dc94a74900708db45994f40%7C96ece5269c7d48b08daf8b93c90a5d1 >> 8%7C0%7C0%7C638180297054464718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj >> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C& >> sdata=7HQSNFGjhMN%2B%2FMY6awtM7jtZdtTLK%2FNEQdRk1F7q%2B3o%3D&reserved >> =0 >> >> >> Do Tomcat Native or OpenSSL depend upon support for TLSv1.3 in the >> underlying OS? > > No. :) To be more specific, OpenSSL *is an implementation of SSL/TLS and the underlying cryptographic primitives*. The whole point is that it is not dependent upon whatever the operating system supports. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
LoginModule JAAS and Tomcat (initialize method is not called)
Hello, I developped my own LoginModule which is very simple for the moment. I wanted to know if I have to create the JAAS configuration file ? If yes where you I locate it ? When I start Tomcat, the constructor of the LoginModule is well called but Tomcat failed before the initialize method. Tomcat launch an exception : "Arguments type error". Do you have any idea ? Thanks for all !!
Re: LoginModule JAAS and Tomcat (initialize method is not called)
I start Tomcat with the following option :
set
JVM_OPTS=-Djava.security.auth.login.config=D:/Appl/eclipse/workspace2/testAppli/jaas.conf
(in the catalina.bat)
My jaas.conf is :
/** Login Configuration for the JAAS **/
MyLoginModule {
com.gcatrans.testappli.MyLoginModule required debug=true app=testAppli;
};
The error message is :
15 fÚvr. 2006 19:14:25 org.apache.commons.digester.Digester endElement
GRAVE: End event threw exception
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.jav
a:252)
at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:256)
at org.apache.commons.digester.Rule.end(Rule.java:276)
at org.apache.commons.digester.Digester.endElement(Digester.java:1058)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source
)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(
Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
Dispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
known Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.commons.digester.Digester.parse(Digester.java:1548)
at org.apache.catalina.startup.Catalina.start(Catalina.java:420)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:350)
at org.apache.catalina.startup.Catalina.process(Catalina.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:156)
Catalina.start using D:\Appl\Tomcat 4.1\conf\server.xml: java.lang.IllegalArgume
ntException: argument type mismatch
java.lang.IllegalArgumentException: argument type mismatch
at org.apache.commons.digester.Digester.createSAXException(Digester.java
:2540)
at org.apache.commons.digester.Digester.createSAXException(Digester.java
:2566)
at org.apache.commons.digester.Digester.endElement(Digester.java:1061)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source
)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(
Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
Dispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
known Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> Message du 15/02/06 à 17h51
> De : "Vincent Delhommois"
> A : users@tomcat.apache.org
> Copie à :
> Objet : LoginModule JAAS and Tomcat (initialize method is not called)
>
> Hello,
> I developped my own LoginModule which is very simple for the moment. I wanted
> to know if I have to create the JAAS configuration file ? If yes where you I
> locate it ?
> When I start Tomcat, the constructor of the LoginModule is well called but
> Tomcat failed before the initialize method. Tomcat launch an exception :
> "Arguments type error".
> Do you have any idea ?
> Thanks for all !!
RE: LoginModule JAAS and Tomcat (initialize method is not called)
Thanks for your answer.
You are right.I tried several positions. I'm sure that the conf file is used.
In my conf file :
MyLoginModule {
com.gcatrans.testappli.MyLoginModule required debug=true app=testAppli;
};
I don't know where is made the mapping between the realm name and the conf
file...
> Message du 15/02/06 à 19h29
> De : "Caldarale, Charles R"
> A : "Tomcat Users List" , [EMAIL PROTECTED]
> Copie à :
> Objet : RE: LoginModule JAAS and Tomcat (initialize method is not called)
>
> > From: Vincent Delhommois [mailto:[EMAIL PROTECTED]
> > Subject: Re: LoginModule JAAS and Tomcat (initialize method
> > is not called)
> >
> > I start Tomcat with the following option :
> > set
> > JVM_OPTS=-Djava.security.auth.login.config=D:/Appl/eclipse/wor
> > kspace2/testAppli/jaas.conf (in the catalina.bat)
>
> Do you mean JAVA_OPTS? JVM_OPTS is not used in the distributed scripts,
> unless you've modified them.
>
> - 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.
>
>
JAAS /Tomcat : Which Realm should I use with my custom LoginModule ?
Hello, I had a problem implementing JAAS with Tomcat and I found my error, I was specifying my custum loginModule in the (I want to create a index.jsp page with 2 fields (login, pwd) and use the j_security_check). Thanks again
JAAS : HTTP 400 Invalid direct reference to form login ... (JAAS + Filter + j_security_check)
Hello, I implements a solution with JAAS and userfilter on Tomcat. the loginmodule return always 'true' eventhough the password is wrong. I do that to be able to return detail error messages to the login.jsp. (I use the role principal to display messages). The filter is used to dispatch to the application pages or back to the login.jsp page if the authentification failed. The error : " Etat HTTP 400 - Référence directe à la form de connexion (form login page) invalide " OR "HTTP 400 : Invalid direct reference to form login ..." is displayed when I first logon with a wrong password and then I relog with the correct password. It seems I didnot invalidate correctly the jaas or the session after the failure. Do you have any idea ? Thanks
Re: JAAS : HTTP 400 Invalid direct reference to form login ... (JAAS + Filter + j_security_check)
Thanks for the answer. You are right, I will check this solution with the ThreadLocal pattern (i don't know at all). I used the filter and the loginModule returns always 'true' beacuse it's not easy to pass some messages 'wrong password', 'validity perdio expired', etc... to the login.jsp in case of a wrong authentification. Thanks PS : Do you have any example of a solution with threadlocal ? > Message du 23/02/06 à 10h19 > De : "David Delbecq" > A : "Tomcat Users List" > Copie à : > Objet : Re: JAAS : HTTP 400 Invalid direct reference to form login ... (JAAS > + Filter + j_security_check) > > Login module should return false if not authenticated. If you need to > store messages for the user, i'll suggest you pass them another way > (like by using a ThreadLocal pattern) > > Vincent Delhommois a écrit : > > >Hello, I implements a solution with JAAS and userfilter on Tomcat. > >the loginmodule return always 'true' eventhough the password is wrong. I do > >that to be able to return detail error messages to the login.jsp. (I use the > >role principal to display messages). > >The filter is used to dispatch to the application pages or back to the > >login.jsp page if the authentification failed. > >The error : " Etat HTTP 400 - Référence directe à la form de connexion (form > >login page) invalide " OR "HTTP 400 : Invalid direct reference to form login > >..." is displayed when I first logon with a wrong password and then I relog > >with the correct password. > >It seems I didnot invalidate correctly the jaas or the session after the > >failure. > >Do you have any idea ? > >Thanks > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >
2 sessions different instead of one wished !!!
Hello, I use JAAS and filter (security-filter) of Tomcat with the j_security_check. So here is the context : - the user try to access to the ActionServlet?action=welcome As the user is not authenticates, it loads the login.jsp page : - login.jsp submit the username and password through the j_security_check. - My custom LoginModule is called to authenticates with JAAS (commit() method is called ssuccessfullly if login and password are OK) - Then it should call the ActionServlet?action=welcome. As i describe a filter in the web.xml, before that call, it execute my UserFilter code. Here is the problem : In my UserFilter, I get a session objet (internal id = 150 for example) To terminate the UserFilter, I do a : chain.doFilter(request, response); In my ActionServlet, I get a session objet (internal id = 999 for example) !!! It's not the same session I don't know why and what's wrong and what I do not understand. Thanks > Message du 24/02/06 à 06h03 > De : "Sathish Sathyan" > A : "Tomcat Users List" > Copie à : > Objet : Re: context path ignored in Context.xml > > > Hi Robert, > > To counter such a problem, try giving the absolute path in the 'appBase' > parameter of the HostName tag in server.xml. > > My server.xml is something like this: > > > maxThreads="150" minSpareThreads="25" maxSpareThreads="75" > enableLookups="true" redirectPort="8443" > acceptCount="10" debug="0" connectionTimeout="2" > disableUploadTimeout="true" /> > > > > debug="0" resourceName="UserDatabase" /> > > > > > > > After making these changes, the error didn't appear for me. > > Thanks, > Sathish > > On Thu, 2006-02-23 at 08:29 -0500, Robert Taylor wrote: > > Greetings, > > > > I'm using Tomcat 5.5.15 on Win2k in development. > > I start Tomcat through a target in my Ant build and pass it a server.xml > > file. > > > > My web app is deployed to a directory named "webapp" (the docbase) and > > contains a /META-INF/context.xml file which has a context path, "/test". > > > > When I start tomcat and attempt to access my web app using the context > > path of /test, I get a strange 400 error. > > > > > > HTTP/1.x 400 No Host matches server name localhost > > > > > > > > > > When I access the webapp using /webapp as the context path, tomcat > > serves up the content. > > > > Therefore, it appears that Tomcat is ignoring the context path I have > > defined and using the docbase directory in name by default. > > > > I have been pouring over the online docs for a couple days and haven't > > been able to figure this one out. > > > > Any help would be appreciated. > > > > /robert > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > This e-mail and any files transmitted with it are for the sole use of the > intended recipient(s) and may contain confidential and privileged information. > If you are not the intended recipient, please contact the sender by reply > e-mail and destroy all copies of the original message. > Any unauthorised review, use, disclosure, dissemination, forwarding, printing > or copying of this email or any action taken in reliance on this e-mail is > strictly > prohibited and may be unlawful. > > Visit us at http://www.cognizant.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >
[JAAS] HTTP 400 : Référence directe à la f orm de connexion (form login page) invalide
Hello, I implements successfully a JAAS authentification but an error sometimes appends : The process is : First I logon the application ssuccessfully (JAAS OK => LoginModule return true) => My application JSP page is weel displayed Then I disconnect (session.invalidate()) Then I try to reconnect with a password error => Logon failed and the login page is displayed (that's normal) Here is the problem : When I typed the correct password => Tomcat try to display my application JSP page but the following error page is displayed : -- In french Etat HTTP 400 - Référence directe à la form de connexion (form login page) invalide type Rapport d''état message Référence directe à la form de connexion (form login page) invalide description La requête envoyée par le client était syntaxiquement incorrecte (Référence directe à la form de connexion (form login page) invalide). -- In English HTTP 400 - Direct reference to a login form (form login page) invalid Request description : The sended request by the client was incorrect (syntax incorrect) -- In debug mode, the login() and commit() methods are well executed and return true. Thanks for your help !!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
j_security_check and JAAS => GOOD or BAD ?
Hello,
When I look all the JAAS example, I see that you have to use the following code
to use the LoginModule, etc...
LoginContext lc = new LoginContext("MyExample");
try {
lc.login();
} catch (LoginException) {
// Authentication failed.
}
The "MyExample" is the name that you can retrieve in the jaas.conf.
What is the link between the j_security_check and JAAS ?
Is that a good thing to use j_security_check and my custom LoginModule ? Right
works fine exept I don't use the LoginContext lc = new
LoginContext("MyExample");
Thanks for your comments.
Web.xml - mime-type definition for file without extension
Hello, Here is my situation: I have audio files that are not named "foo.wav" but "foo". As a consequence, Tomcat does not define a content-type for these files as "audio/x-wav" since they are not matching with the extension ".wav". Finally, they are not correctly interpreted by the client. I have tried to define the following mime-mapping in this way, but it does not work: audio/x-wav wav audio/x-wav Is there a way to define the content-type in Tomcat config files to say files without extension have a mime-type set to "audio/x-wav"? (If possible, I'd like to avoid using a servlet to set the mime-type for files without extension). Your advice are very welcomed! Thanks in advance. Vincent ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Comet in tomcat
Hi all, I'm working on server side pushing integration in Wicket, and I saw Tomcat6 implements comet : http://tomcat.apache.org/tomcat-6.0-doc/aio.html Have you got a complete example of an application using cometProcessor? How can I use NIO connector? Is there an implemantation of the Bayeux protocol? Cheers -- Vincent http://www.demay-fr.net/blog/ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 6 serious issues on AIX 5.3
We ran our web app on Tomcat 4 on an AIX 5.3 box Java 5_64 with no issues for 2 years. We recently upgraded to Tomcat 6 and we are seeing some unusual problems. 1) After working for 2-3 days with heavy load One of our functions errors with java.sql.SQLException: java.io.IOException: java.net.SocketException: There is no process to read data written to a pipe. 2) Jsp classes that were working properly start throwing Exceptions like ClassCastException Resolution is only by clearing cache and re-starting. We are thinking maybe the OS needs and upgrade and we need to be on Java 1.6 Would appreciate if anyone else had similar experience - what was resolution. Vincent If you are not the intended addressee, please inform us immediately that you have received this e-mail in error, and delete it. We thank you for your cooperation.
Re: Tomcat 6 serious issues on AIX 5.3
Chris, I do understand the lack of information like stack trace etc and that is precisely my problem. In my past experience a version incompatibility could cause severe headaches and the symtoms don't point to much. Some more details about our env: For the upgrade, the server.xml was re-created based on the template provided. Please note that the migration was first fully tested and them deployed to production. Moreover the app runs for 2-3 days with no errors and under heavy load. It is then that the errors start showing up. There is no consistency which makes debugging most difficult. I am thinking that the problem is happening with the JVM interaction with the OS that is why I want to make sure that we are current with the OS and the Java - change to 1.6. The Catalina dir under /work is always deleted before re-start. This may help - we have several servers with different memory and on machines with lower memory we've experienced crashes. We are trying to capture the core files (we have an incomplete core file because of file space constraints but have increased it now). On machines with higher memory Tomcat does not crash but as I indicated we get SocketException: [2012-09-25 12:13:35,700] ERROR com.*Action - System Error java.sql.SQLException: java.io.IOException: java.net.SocketException: There is no process to read data written to a pipe. at com.ashna.jturbo.driver.x.e(x.java) at com.ashna.jturbo.driver.x.a(x.java) at com.ashna.jturbo.driver.y.execute(y.java) at org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:172) at org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:172) ch...@christopherschultz.net 09/28/2012 10:21 AM Please respond to users@tomcat.apache.org To users@tomcat.apache.org cc Subject Re: Tomcat 6 serious issues on AIX 5.3 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vincent, On 9/28/12 12:47 PM, vincent.soo...@daimler.com wrote: > We ran our web app on Tomcat 4 on an AIX 5.3 box Java 5_64 with no > issues for 2 years. Great. > We recently upgraded to Tomcat 6 and we are seeing some unusual > problems. How did you upgrade? Please be very specific: lots of people think they can just re-use their existing configuration (e.g. server.xml) from prior Tomcat versions and things will just work. They won't. > 1) After working for 2-3 days with heavy load One of our functions > errors with java.sql.SQLException: java.io.IOException: > java.net.SocketException: There is no process to read data written > to a pipe. Full stack trace? > 2) Jsp classes that were working properly start throwing Exceptions > like ClassCastException Again, full stack trace? Do you precompile JSPs? Did you clean-out Tomcat's 'work' directory after the upgrade and before you restarted Tomcat? > Resolution is only by clearing cache and re-starting. What cache are you clearing? > We are thinking maybe the OS needs and upgrade and we need to be on > Java 1.6 Well, Tomcat 6 only requires Java 1.5, but Oracle no longer supports Java 1.5 so it's probably time to move up. What versions of everything are you running? > Would appreciate if anyone else had similar experience - what was > resolution. You haven't really described your situation other than "things sometimes break". If you give more information, we might be able to give you better feedback. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBl21MACgkQ9CaO5/Lv0PBpGQCgkvWHLKcxHKhcwFF4LHnIvI8R paAAoLWab7aS1tZZziGtOWPjeY/vXJir =D/q1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org If you are not the intended addressee, please inform us immediately that you have received this e-mail in error, and delete it. We thank you for your cooperation.
RE: Tomcat 6 serious issues on AIX 5.3
No, It could be Tomcat 6 / AIX OS 5.3 / Java 1.5 We reverted to Tomcat 4 - identical code base identical DB config and the app works like a charm (has been working for 2 years) The reason to upgrade is 2 fold - to stay current and to use Tomcat's Realm LDAP authentication mechanism. chuck.caldar...@unisys.com 09/28/2012 10:54 AM Please respond to users@tomcat.apache.org To users@tomcat.apache.org cc Subject RE: Tomcat 6 serious issues on AIX 5.3 > From: vincent.soo...@daimler.com [mailto:vincent.soo...@daimler.com] > Subject: Re: Tomcat 6 serious issues on AIX 5.3 > On machines with higher memory Tomcat does not crash but as I indicated we > get SocketException: > [2012-09-25 12:13:35,700] ERROR com.*Action - System Error > java.sql.SQLException: java.io.IOException: java.net.SocketException: > There is no process to read data written to a pipe. > at com.ashna.jturbo.driver.x.e(x.java) Which means Tomcat isn't in the game. It appears the database server on the other end of the pipe has gotten bored and decided to stop listening. You should consult the documentation for the jturbo driver to see if can be configured to be more resilient. You may be able to configure Tomcat's DB connection pool to recover from this situation, assuming the DB server is still alive. Post your DBCP configuration and let's see what can be done with it. - 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 If you are not the intended addressee, please inform us immediately that you have received this e-mail in error, and delete it. We thank you for your cooperation.
Tomcat 7 SSL Session ID
Hey, I'm doing some research about the SSL session tracking / SSL Session id's. Now I'm having some problems when requests are send to the server in quick succession, I notice the problem is fixed or at least less occuring when the keepAlive server setting is set to 0.. When the keepAliveTimeout is not set to "0" I can see in the SSL debug logs the SSL session get's invalidated after some requests with a Broken Pipe exception. Is this because there are too many open connections during the keepAliveTimeout? It also only happens when processing the requests takes some time (fe. storing items in database) or when I put the threat to sleep for testing purpose. When inspecting the traffic I see some tcp-rst packages (problem is here?) from previous connections while the current one is being processed. My question is why these SSL Sessions get invalidated after alot of quick requests to the server since this gives a problem with my SSL Session tracking since the id changes then. I can provide a sample jsp project where the Invalidation occurs if wanted.. PS. I'm running Tomcat 7 on a mac osx Lion 10.7.4 server.xml settings: Thanks in advance, Vincent Goelen
Re: Tomcat 7 SSL Session ID
Hey, thanks for the help! To be clear, I do not want a 0ms timeout... I'm doing research about how "usable" the SSL session tracking option is for session management... With the standard settings it seems very unstable to me, when sending alot of parallel requests I get a broken socket error invalidating the ssl session and making the session with this id disappear. In this case it would seem to me that it's easy to create Denial of Service attacks by just sending alot of requests so the user loses his session. By playing with the timeouts I found out this problem doesn't occur when I set the timeout to 0, just by playing with the settings. Perhaps because this disables the possibility of too many parallel connections? I can't find the reason of this in the Tomcat or SSL specs... I've added a screenshot of a capture where things go wrong without setting a keepAlive.. So I send alot of requests to the server, the first clientHello (pck 38943) and the following packets everything goes ok, when the application data is being send I get a tcp rst from port 54195 (this is the connection that was used for the transactions before the current one) ... At this moment my session gets invalidates making the next SSL handshake a full one with new ID (pckt 40361, ...) 2012/11/29 Christopher Schultz > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Vincent, > > On 11/28/12 3:14 AM, Vincent Goelen wrote: > > When the keepAliveTimeout is not set to "0" I can see in the SSL > > debug logs the SSL session get's invalidated after some requests > > with a Broken Pipe exception. Is this because there are too many > > open connections during the keepAliveTimeout? > > It's probably because of your pathological keepAliveTimeout. 0ms > seems, er, low. Why did you choose 0ms? > > I haven't looked at the code, so I'm not sure if the elapsed timer > starts when the last request is completed (which seems reasonable) or > when the last request started. I suspect the latter. 0ms is awfully > short. Are you sure that your client is capable of accepting the > response to the previous request and turn-around and make another > request across the same channel before 0ms passes? > > > It also only happens when processing the requests takes some time > > (fe. storing items in database) or when I put the threat to sleep > > for testing purpose. > > So if you have a trivial request (say, HEAD for a static resource), > you can never get a failure? > > > When inspecting the traffic I see some tcp-rst packages (problem is > > here?) from previous connections while the current one is being > > processed. > > When you say "current one" what do you mean? If you are using a single > connection with HTTP keepalive, then there is only one connection to > talk about: you can't get RSTs from "previous connections". You may be > getting TCP RST as the server closes the connection while the client > is trying to write. Is that what you are experiencing? > > > My question is why these SSL Sessions get invalidated after alot of > > quick requests to the server since this gives a problem with my SSL > > Session tracking since the id changes then. > > Maybe if you can explain why you want a 0ms keepalive timeout it would > be helpful. If you want to disable keep alives, set > maxKeepAliveRequests="1". If you want to allow an infinite timeout, > try using keepAliveTimeout="-1" as the documentation states. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iEYEARECAAYFAlC3w6YACgkQ9CaO5/Lv0PDX/QCfcPmdRD/FSyDB51QdOqgqwGbI > tLwAmweVvlGCGqU2eAdYtrzezwkEPhZF > =J7dz > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 SSL Session ID
Thanks again for the fast response, sorry for being unclear about some
parts.. First time using the mailing list
I'm using Apache Tomcat Version 7.0.32 on a mac os x 10.7.5, I've tested it
on linux Virtual machine too, got same problems. I'm using JDK 1.6 (don't
think it has any importance here)
Alot is kind of variable, depends on how long the processing of the request
takes, for example when I put a sleep of 1 sec in my jsp code the problem
occurs after about 6 requests, in another test example where I just write
some things to a database it takes more requests, sometimes about 100,
sometimes less it's not really a fixed number I can put on it.
To be clear, it's indeed the SSL session that gets invalidated, not the
httpsession... But by the invalidation, the httpsession's identifier (which
is the SSL session id) is gone so the httpsession becomes useless as well..
http://users.telenet.be/goelenv/Archief.zip
In this zip file you can find 3 files:
- a log which is the ssl debug log from tomcat, there you can find an
example of the invalidation at line 2592 (log mislopen.log)
- a wireshark capture file where things go wrong are captured
(Capture_TomcatSSLFout) => here things go wrong at packet 40361 you can
best filter on "tcp.port == 8443" to filter traffic between server and
client
- a screenshot of where things go wrong in case you can't open the
wireshark capture (Schermafbeelding 2012-12-04 om 15.09.56)
Again many thanks!
Vincent
2012/12/4 Christopher Schultz
> -----BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Vincent,
>
> On 12/4/12 9:15 AM, Vincent Goelen wrote:
> > To be clear, I do not want a 0ms timeout... I'm doing research
> > about how "usable" the SSL session tracking option is for session
> > management... With the standard settings it seems very unstable to
> > me, when sending alot of parallel requests I get a broken socket
> > error invalidating the ssl session and making the session with this
> > id disappear. In this case it would seem to me that it's easy to
> > create Denial of Service attacks by just sending alot of requests
> > so the user loses his session.
>
> Forgive me, but it sounded like you set timeout=0 and then started
> getting weird behavior. I would have totally expected weird behavior
> with timeout=0 so that's why I was asking.
>
> You are going to need to provide a lot more detail about the
> session-invalidation (you're talking about *SSL session* invalidation,
> not HttpSession invalidation, right?) you are observing if you want to
> get any help. Lots of technical details, logs, explicit configuration
> (even if it is the default), specific version numbers ("Tomcat 7"
> isn't good enough), etc.
>
> You should also try it on a couple of different platforms. What
> happens on Linux? Windows? Solaris? Whatever you've got laying around.
>
> > I've added a screenshot of a capture where things go wrong without
> > setting a keepAlive.
>
> Attachments get stripped from this list: please post the file
> somewhere else and provide a link.
>
> > So I send alot of requests to the server,
>
> How many is a lot? Serial or parallel? How many parallel threads? Be
> specific.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlC+IQEACgkQ9CaO5/Lv0PBqwACgrkEoqbtzM/jlPiy2SFKhqlIB
> PzkAoIMGBHJickA7JynoX81B0GarvYzd
> =SAlr
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Tomcat 7 SSL Session ID
Hey, I'm completely aware that a RST always terminates a TCP connections.. But in my case, there's an TCP rst from a connection thats already finished it's job causing problems for the active connection! At least that's what I think is going on here.. As you can see in the screenshot of my wireshark capture, the TCP rst there is not from the connection that's writing application data.. The session get's invalidates here because of an unexpected close of the connection which is completely normal regarding the SSL specs. grts, Vincent 2012/12/5 Esmond Pitt > Vincent > > RST always terminates a TCP connection. The question is really why was it > *sent.* The usual reason is writing to a connection that has already been > closed by the peer. Is there an incoming close_notify higher up in the SSL > log? I suppose not otherwise an SSLException would have been thrown. > > Re loss of the SSL session, I suppose it is plausible that SSL discards it > on security grounds because of the broken connection. > > EJP > > _ > > From: Vincent Goelen [mailto:goel...@gmail.com] > Sent: Wednesday, 5 December 2012 9:19 PM > To: Esmond Pitt > Subject: Re: Tomcat 7 SSL Session ID > > > > http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 32 > http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 432 > http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 32 > http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 976 > http-bio-8443-exec-20, handling exception: java.net.SocketException: Broken > pipe > %% Invalidated: [Session-1, TLS_RSA_WITH_AES_256_CBC_SHA] > http-bio-8443-exec-20, SEND TLSv1 ALERT: fatal, description = > unexpected_message > http-bio-8443-exec-20, WRITE: TLSv1 Alert, length = 32 > http-bio-8443-exec-20, Exception sending alert: java.net.SocketException: > Broken pipe > http-bio-8443-exec-20, called closeSocket() > http-bio-8443-exec-20, called close() > http-bio-8443-exec-20, called closeInternal(true) > > > This is what I get in the SSL debug logs.. It seems to happen when the tcp > connection is closed while the application data is being sent.. I think > this > is a security thing to prevent SSL truncation attacks which sounds quite > normal to me. > > The issue is, why does my tcp connection close there: > > http://users.telenet.be/goelenv/Schermafbeelding%202012-12-04%20om%2015.09.5 > 6.png<http://users.telenet.be/goelenv/Schermafbeelding%202012-12-04%20om%2015.09.56.png> > > The screenshot above is one from where things go wrong when I analyse the > traffic, the tcp rst is one from the connection that was used by the > previous request.. But why can that rst packet terminate the current active > tcp connection? > > > 2012/12/5 Esmond Pitt > > > Yes but he *already has* an SSL session which he states is being > invalidated. To the limited extent to which I could make sense of your > incomprehensible post, it appears to be 100% irrelevant. > > > -Original Message- > From: Martin Gainty [mailto:mgai...@hotmail.com] > Sent: Wednesday, 5 December 2012 11:27 AM > To: Tomcat Users List; goel...@gmail.com > Subject: RE: Tomcat 7 SSL Session ID > > > > yes but he needs to achieve a reliable connection between himself and the > SSLServer (at least until key negotiation has completed) broken pipe(s) are > a bear to debug but you have a few tools available to you: > > netstat SSLServerIP > -- if you see ANY intervening nodes hanging more than 4 sec drop from arp > cache generally by arp -d ServerIP > assuming your ServerIP is is 157.55.85.212 and the physical address of the > network you want to connect to is 00-aa-00-62-c6-09 (check with net-admin > for the physical-address or eth-addr to use) > arp -s 157.55.85.212 > 00-aa-00-62-c6-09 Adds a static entry. > > arp -a Displays the arp table. > route print will display the routes between you and the SSLServer if you > dont see a route referencing the server you may want to add in your own > route with > route add DESTINATION MASK Mask METRIC NoOfHops Interface > > InterfaceNumbercheck with net-admin DESTINATION is generally the > dotted.quad.of.SSLServercheck with net-admin generally Mask =255.255.255.0 > will docheck with net admin about which Interface to use..avoid 127.0.0.1 > (unless testing locally)check with net admin on NoOfHops param ..generally > > the lower the better use curl (command line url) to check the validity of > > the certificate, keys and passwordscurl -1 --cacert [file] --key > > PrivateKey.jks --pass PrivateKeyPass --key-type PEM --pubkey > PublicKey.jks-1 > > says use TLSv1check the type of key most
Re: Tomcat 7 SSL Session ID
There are no 2 different webapps to be clear.. It's one app that gives problems when there are parallel connections with the same client.. 2012/12/6 Martin Gainty > > can you split the 2 webapps to run on 2 completely different Tomcat > instances running on 2 completely different configured in > server.xml The connection causing the TCP RST is on one tomcat instance and > doesnt enable or use the other connections (and does not cause a Session > Invalidate) as SSLConnection is disable > > the second webapp enables the SSLConnection and does not interact with any > other TCP connections as any other TCP or HTTP connections are not enabled > in the second TC instance > if you run the simple curl script implementing the keys, password and > CACert do you see a key exchange? > (that is the behaviour you want to emulate in your Servlet code) > Martin > __ > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht > dient lediglich dem Austausch von Informationen und entfaltet keine > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le > destinataire prévu, nous te demandons avec bonté que pour satisfaire > informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie > de ceci est interdite. Ce message sert à l'information seulement et n'aura > pas n'importe quel effet légalement obligatoire. Étant donné que les email > peuvent facilement être sujets à la manipulation, nous ne pouvons accepter > aucune responsabilité pour le contenu fourni. > > > Date: Thu, 6 Dec 2012 11:12:26 +0100 > > Subject: Re: Tomcat 7 SSL Session ID > > From: goel...@gmail.com > > To: users@tomcat.apache.org > > > > Hey, > > I'm completely aware that a RST always terminates a TCP connections.. > > But in my case, there's an TCP rst from a connection thats already > finished > > it's job causing problems for the active connection! At least that's > what I > > think is going on here.. > > As you can see in the screenshot of my wireshark capture, the TCP rst > there > > is not from the connection that's writing application data.. > > > > The session get's invalidates here because of an unexpected close of the > > connection which is completely normal regarding the SSL specs. > > > > grts, > > Vincent > > > > 2012/12/5 Esmond Pitt > > > > > Vincent > > > > > > RST always terminates a TCP connection. The question is really why was > it > > > *sent.* The usual reason is writing to a connection that has already > been > > > closed by the peer. Is there an incoming close_notify higher up in the > SSL > > > log? I suppose not otherwise an SSLException would have been thrown. > > > > > > Re loss of the SSL session, I suppose it is plausible that SSL > discards it > > > on security grounds because of the broken connection. > > > > > > EJP > > > > > > _ > > > > > > From: Vincent Goelen [mailto:goel...@gmail.com] > > > Sent: Wednesday, 5 December 2012 9:19 PM > > > To: Esmond Pitt > > > Subject: Re: Tomcat 7 SSL Session ID > > > > > > > > > > > > http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 32 > > > http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 432 > > > http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 32 > > > http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 976 > > > http-bio-8443-exec-20, handling exception: java.net.SocketException: > Broken > > > pipe > > > %% Invalidated: [Session-1, TLS_RSA_WITH_AES_256_CBC_SHA] > > > http-bio-8443-exec-20, SEND TLSv1 ALERT: fatal, description = > > > unexpected_message > > > http-bio-8443-exec-20, WRITE: TLSv1 Alert, length = 32 > > > http-bio-8443-exec-20, Exception sending alert: > java.net.SocketException: > > > Broken pipe > > > http-bio-8443-exec-20, called closeSocket() > > > http-bio-8443-exec-20, called close() > > > http-bio-8443-exec-20, called closeInternal(true) > > > > > > > > > This is what I get in the SSL debug logs
Re: Tomcat 7 SSL Session ID
Hey, http://users.telenet.be/goelenv/SSLTomcat.zip in this link you can find a netbeans project that will generate the fault.. The index.html page will send requests to the index.jsp page, the thread sleep is just to emulate a long process of a request (like database things, etc) Kind regards, Vincent 2012/12/10 Christopher Schultz > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Martin, > > On 12/10/12 10:22 AM, Martin Gainty wrote: > > we need to get your architect into this discussion > > > > Why is your code implementing 2 different Connections to > > accomplish this functionality when one Connection at a time will > > suffice? > > You have no idea what you are talking about. There is only one > connection. There is only one connector. The OP is reporting that his > SSL session id expires long before he is expecting it to expire. > > This has nothing to do with webapps and connectors except he happens > to have a connector and a webapp. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iEYEAREIAAYFAlDGXhIACgkQ9CaO5/Lv0PDwtQCgk63c5ZUVojVhdgVpHpF5IMkX > 3lYAoKPCpNeo8lEquukN/BRxPjuFfl1E > =tdIg > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat 7 SSL Session ID
If you run the test.jsp page.. When you send a request and interrupt it
while it's processing.. For example by pressing the stop loading button
immediatly after sending the request or by pressing the refresh button fast
enough..
When you look what happens then: the SSL connection sends close notifies
which should make sure no more data is sent over the connection..
This does happen, the client has sent it's TCP close packet and after that
it receives application data from the server while it shouldn't do that
according to the ssl specs.. When the client receives this application data
after the connection is already closed, it sends a TCP rst packet causing
an invalidate of the server...
This problem has nothing to do with not using the exception handling but
seems to me more a problem of Tomcat's priority of TCP specs in front of
SSL specs
2012/12/17 Martin Gainty
>
> Session.SessionTrackingModelListener.java contains
> context.setSessionTrackingModes(modes); with no exception handling /**
> * @param sessionTrackingModes
> * @throws IllegalArgumentException
> * If sessionTrackingModes specifies
> * {@link SessionTrackingMode#SSL} in combination with any
> other
> * {@link SessionTrackingMode}
> * @throws IllegalStateException
> * If the context has already been initialised
> * @throws UnsupportedOperationException
> * @since Servlet 3.0 TODO SERVLET3 - Add comments
> */
>
> public void setSessionTrackingModes(Set
> sessionTrackingModes) throws IllegalStateException,
> IllegalArgumentException;
> Moral of the story..always catch declared Exceptions
> where is the jsp you test with?
> Martin
> __ Please do not alter or
> otherwise disrupt this communication..thank you
> > Date: Mon, 17 Dec 2012 09:47:09 +0100
> > Subject: Re: Tomcat 7 SSL Session ID
> > From: goel...@gmail.com
> > To: users@tomcat.apache.org
> >
> > Hey,
> >
> > http://users.telenet.be/goelenv/SSLTomcat.zip
> >
> > in this link you can find a netbeans project that will generate the
> fault..
> > The index.html page will send requests to the index.jsp page, the thread
> > sleep is just to emulate a long process of a request (like database
> things,
> > etc)
> >
> > Kind regards,
> > Vincent
> >
> > 2012/12/10 Christopher Schultz
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > Martin,
> > >
> > > On 12/10/12 10:22 AM, Martin Gainty wrote:
> > > > we need to get your architect into this discussion
> > > >
> > > > Why is your code implementing 2 different Connections to
> > > > accomplish this functionality when one Connection at a time will
> > > > suffice?
> > >
> > > You have no idea what you are talking about. There is only one
> > > connection. There is only one connector. The OP is reporting that his
> > > SSL session id expires long before he is expecting it to expire.
> > >
> > > This has nothing to do with webapps and connectors except he happens
> > > to have a connector and a webapp.
> > >
> > > - -chris
> > > -BEGIN PGP SIGNATURE-
> > > Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> > > Comment: GPGTools - http://gpgtools.org
> > > Comment: Using GnuPG with undefined - http://www.enigmail.net/
> > >
> > > iEYEAREIAAYFAlDGXhIACgkQ9CaO5/Lv0PDwtQCgk63c5ZUVojVhdgVpHpF5IMkX
> > > 3lYAoKPCpNeo8lEquukN/BRxPjuFfl1E
> > > =tdIg
> > > -END PGP SIGNATURE-
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> > >
>
>
Fwd: Error Message on Apache
Hi Good evening, My Application does not load from browser. I got the attached Apache error. Please kindly help with possible solutions. Thanks. -- Vincent Ogundu for:Easiglobe Messaging Ltd 85a Owukori Crescent, Alaka Estate, Surulere Lagos. Tel:234-1-7388983 /4. E-mail:vincentogu...@gmail.com -- Vincent Ogundu for:Easiglobe Messaging Ltd 85a Owukori Crescent, Alaka Estate, Surulere Lagos. Tel:234-1-7388983 /4. E-mail:vincentogu...@gmail.com HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Cannot open connection org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:382) org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:371) org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:316) org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:105) org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202) $Proxy60.executeSimpleQuery(Unknown Source) com.primovision.ussd.services.AuthenticationServiceImpl.findRolesForURL(AuthenticationServiceImpl.java:58) com.primovision.ussd.core.spring.CustomSecureResourceFilter.getAttributes(CustomSecureResourceFilter.java:40) org.springframework.security.access.intercept.AbstractSecurityInterceptor.beforeInvocation(AbstractSecurityInterceptor.java:171) org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:106) org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83) org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355) org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:97) org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355) org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:187) org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355) org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:105) org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355) org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:79) org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355) org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:149) org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237) org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167) org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.doFilterInternal(OpenEntityManagerInViewFilter.java:113) org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) root cause javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Cannot open connection org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1235) org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1168) org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1245) org.hibernate.ejb.TransactionImpl.begin(TransactionImpl.java:63) org.springframework.orm.jpa.DefaultJpaDialect.beginTransaction(DefaultJpaDialect.java:70) org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:55) org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:332) org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:371) org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:316
Tomcat 6.0.26 64 bits = CPU 100%
Hi everybody, We have several virtual machines on Windows 2008 server with Tomcat 6.0.26 64 bits (JDK 1.6 64 bits). The servers have 6 Go of RAM and we declare 4 Go for the Tomcat. Our application works fine except some days. On these days, the CPU are stuck at 100% and doesn't decrease. Do you have any idea ? Thanks Vincent - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6.0.26 64 bits = CPU 100%
Hi everybody, We have several virtual machines on Windows 2008 server with Tomcat 6.0.26 64 bits (JDK 1.6 64 bits). The servers have 6 Go of RAM and we declare 4 Go for the Tomcat. Our application works fine except some days. On these days, the CPU are stuck at 100% and doesn't decrease. Do you have any idea ? Thanks Vincent - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Encoding issues with Tomcat 7.0.69+ and 8.0.33+
Hi guys, I work on the XWiki project (http://xwiki.org) and we’ve had several reports of users telling us that XWiki is not working anymore with versions of Tomcat > 7.0.69 and > 8.0.33. It works perfectly well with those versions and lower. The issue is described in more detail at http://jira.xwiki.org/browse/XWIKI-13556 In short, I’ve tracked down one of the issues and here’s the problem we have: * We use context.getRequest().getRequestDispatcher(path).forward(…). * We are url-encoding the path. For example:path = /bin/view/Main/test%20with%20space * With Tomcat > 7.0.69 and > 8.0.33 (I’m testing with versions 8.0.36 and 7.0.59 to be precise) this generates an incoming URL of .../bin/view/Main/test%2520with%2520space in our code * With Tomcat <= 7.0.69 and <= 8.0.33 it was generating an incoming URL of .../bin/view/Main/test%20with%20space in our code Also note that with Jetty 9.2.13.v20150730 if we don’t url-encode the path passed to getRequestDispatcher(path) then Jetty generates an incoming URL of .../bin/view/Main/test with space in our code, which is of course invalid and fails. So I wanted to ask you two questions: * Would someone know the change in Tomcat that brought this difference from previous versions? * Who’s right? :) Thanks for any help -Vincent XWiki Committer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Encoding issues with Tomcat 7.0.69+ and 8.0.33+
Ok I’ve found the issue that is causing the problem: https://bz.apache.org/bugzilla/show_bug.cgi?id=59317 Specifically it says: “ Async and non-async behaviours are currently the same. • Both expect the path used to obtain the dispatcher to be decoded. This behavior was confirmed with the Servlet EG. • Both return the unencoded URI for req.getRequestURI(). That strikes me as wrong. " And “ The restriction the the request dispatcher (or the async dispatch) must be obtained with a decoded path has not changed. However, I have applied a fix that ensures that the result of the call to getRequestURI() after the dispatch returned an encoded URI. “ It would be nice to have more information about " This behavior was confirmed with the Servlet EG.". The Servlet spec doesn't mention anything and this makes Tomcat have a different behavior than other servlet containers (Jetty for example). I believe this change is dangerous and is going to cause regression to lots of applications out there who used to work with an encoded dispatcher path and that are now going to not work anymore (as is the case with XWiki, see http://jira.xwiki.org/browse/XWIKI-13556). Could someone from the Tomcat dev team please comment on this? Thanks -Vincent > On 08 Jul 2016, at 22:00, Vincent Massol wrote: > > Hi guys, > > I work on the XWiki project (http://xwiki.org) and we’ve had several reports > of users telling us that XWiki is not working anymore with versions of Tomcat > > 7.0.69 and > 8.0.33. It works perfectly well with those versions and lower. > > The issue is described in more detail at > http://jira.xwiki.org/browse/XWIKI-13556 > > In short, I’ve tracked down one of the issues and here’s the problem we have: > > * We use context.getRequest().getRequestDispatcher(path).forward(…). > * We are url-encoding the path. For example:path = > /bin/view/Main/test%20with%20space > * With Tomcat > 7.0.69 and > 8.0.33 (I’m testing with versions 8.0.36 and > 7.0.59 to be precise) this generates an incoming URL of > .../bin/view/Main/test%2520with%2520space in our code > * With Tomcat <= 7.0.69 and <= 8.0.33 it was generating an incoming URL of > .../bin/view/Main/test%20with%20space in our code > > Also note that with Jetty 9.2.13.v20150730 if we don’t url-encode the path > passed to getRequestDispatcher(path) then Jetty generates an incoming URL of > .../bin/view/Main/test with space in our code, which is of course invalid and > fails. > > So I wanted to ask you two questions: > * Would someone know the change in Tomcat that brought this difference from > previous versions? > * Who’s right? :) > > Thanks for any help > > -Vincent > XWiki Committer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Encoding issues with Tomcat 7.0.69+ and 8.0.33+
Hi Mark,
> On 11 Jul 2016, at 22:32, Mark Thomas wrote:
>
> On 10/07/2016 22:24, Vincent Massol wrote:
>> Ok I’ve found the issue that is causing the problem:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=59317
>>
>> Specifically it says:
>>
>> “
>> Async and non-async behaviours are currently the same.
>> • Both expect the path used to obtain the dispatcher to be decoded.
>> This behavior was confirmed with the Servlet EG.
>> • Both return the unencoded URI for req.getRequestURI(). That strikes
>> me as wrong.
>> "
>>
>> And
>>
>> “
>> The restriction the the request dispatcher (or the async dispatch) must be
>> obtained with a decoded path has not changed. However, I have applied a fix
>> that ensures that the result of the call to getRequestURI() after the
>> dispatch returned an encoded URI.
>> “
>>
>> It would be nice to have more information about " This behavior was
>> confirmed with the Servlet EG.". The Servlet spec doesn't mention anything
>> and this makes Tomcat have a different behavior than other servlet
>> containers (Jetty for example).
>>
>> I believe this change is dangerous and is going to cause regression to lots
>> of applications out there who used to work with an encoded dispatcher path
>> and that are now going to not work anymore (as is the case with XWiki, see
>> http://jira.xwiki.org/browse/XWIKI-13556).
>>
>> Could someone from the Tomcat dev team please comment on this?
>
> This is the change in question (note the corrected version numbers):
>
> Tomcat 8.0.x for 8.0.34 onwards:
> http://svn.apache.org/viewvc?view=revision&revision=1741019
>
> Tomcat 7.0.x for 7.0.70 onwards:
> http://svn.apache.org/viewvc?view=revision&revision=1741024
>
> This change ensured that a call to HttpServletRequest.getRequestURI()
> returned an encoded URL rather than a decoded one if called from within
> a dispatched request. The Javadoc for getRequestURI() is clear that the
> returned value is not decoded so I am confident that this change was
> correct.
>
> Tomcat has required that a decoded path is used to obtain a
> RequestDispatcher for as long as I can remember. I went back through svn
> and this dates back to at least Tomcat 4.1.x.
As I mentioned in my first mail this is what I see:
* With Tomcat > 7.0.69 and > 8.0.33,
…getRequestDispatcher("/bin/view/Main/test%20with%20space").forward(…) leads to
.../bin/view/Main/test%2520with%2520space (note that the precent is encoded to
%25).
* With Tomcat <= 7.0.69 and <= 8.0.33
…getRequestDispatcher("/bin/view/Main/test%20with%20space").forward(…) leads to
.../bin/view/Main/test%20with%20space (which is correct)
Since you say that Tomcat has required a decoded path since at least Tomcat
4.1.x the only thing I can think of is that before 7.0.70 and 8.0.34 Tomcat was
simply using the path as is without doing any encoding on it and starting with
the new versions you’re now encoding it.
In any case, this change is bringing an important behavior change from the
usage of Tomcat POV (and is breaking XWiki).
> Jetty (confirmed with 9.3.10) decodes the path provided to the
> RequestDispather.
>
> The Servlet spec has never been clear on which paths are encoded and
> which are decoded. I have been trying to get this fixed for a number of
> years (e.g. [1]) but unfortunately, the way Oracle runs the Servlet EG
> the only changes that are made to the spec are the ones Oracle wants to
> make.
>
> The clarification from the EG (linked from a related bug report, [2])
> the was more around the behaviour of AsyncContext.dispatch(). It implied
> paths used with a RequestDispatcher were decoded but was not explicit.
>
> Having spent a fair chunk of today thinking about this, I'm leaning
> towards Tomcat being wrong not to decode the paths passed to the
> RequestDispatcher. My reasoning is as follows:
>
> Section 9.1.1 of the Servlet spec includes this example:
>
> String path = “/raisins.jsp?orderno=5”;
> RequestDispatcher rd = context.getRequestDispatcher(path);
> rd.include(request, response);
>
>
> It is clear from that example and the surrounding text that a query
> string can be provided with the path. What if the JSP was called
> "foo?bar.jsp" ? It is an odd name for a JSP but not an invalid one and
> names like this are often useful for exploring edge cases. The only way
> to dispatch to that JSP is to encode the '?' character. Therefore, the
> RD is going to have to decode the path.
>
> The above argument suggests that Tomcat has been handling requests for a
> Re
Re: Encoding issues with Tomcat 7.0.69+ and 8.0.33+
Hi Mark,
I’ve seen your mail on the devs list. IMO you have only 2 choices:
* Option 1: decode the path passed to RD
* Option 2: revert the changes brought by
http://svn.apache.org/viewvc?view=revision&revision=1741019 and
http://svn.apache.org/viewvc?view=revision&revision=1741024 (or at least part
of it) so that the path passed to RD is not encoded (i.e. same as before).
Any other choice will result in Tomcat having an important regression compared
to before and XWiki won’t be able to use those new Tomcat versions (and I
suspect a lot of others webapps will be in the same situations).
Now I understand the problem with option 1. Users who were passing undecoded
paths to RD will get broken too. However if they were doing since Tomcat was
not encoding the path, I believe that they would have resulted in invalid URLs
generated by the forward(), no? So maybe it’s not an issue after all.
Thanks
-Vincent
> On 12 Jul 2016, at 09:09, Vincent Massol wrote:
>
> Hi Mark,
>
>> On 11 Jul 2016, at 22:32, Mark Thomas wrote:
>>
>> On 10/07/2016 22:24, Vincent Massol wrote:
>>> Ok I’ve found the issue that is causing the problem:
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=59317
>>>
>>> Specifically it says:
>>>
>>> “
>>> Async and non-async behaviours are currently the same.
>>> • Both expect the path used to obtain the dispatcher to be decoded.
>>> This behavior was confirmed with the Servlet EG.
>>> • Both return the unencoded URI for req.getRequestURI(). That strikes
>>> me as wrong.
>>> "
>>>
>>> And
>>>
>>> “
>>> The restriction the the request dispatcher (or the async dispatch) must be
>>> obtained with a decoded path has not changed. However, I have applied a fix
>>> that ensures that the result of the call to getRequestURI() after the
>>> dispatch returned an encoded URI.
>>> “
>>>
>>> It would be nice to have more information about " This behavior was
>>> confirmed with the Servlet EG.". The Servlet spec doesn't mention anything
>>> and this makes Tomcat have a different behavior than other servlet
>>> containers (Jetty for example).
>>>
>>> I believe this change is dangerous and is going to cause regression to lots
>>> of applications out there who used to work with an encoded dispatcher path
>>> and that are now going to not work anymore (as is the case with XWiki, see
>>> http://jira.xwiki.org/browse/XWIKI-13556).
>>>
>>> Could someone from the Tomcat dev team please comment on this?
>>
>> This is the change in question (note the corrected version numbers):
>>
>> Tomcat 8.0.x for 8.0.34 onwards:
>> http://svn.apache.org/viewvc?view=revision&revision=1741019
>>
>> Tomcat 7.0.x for 7.0.70 onwards:
>> http://svn.apache.org/viewvc?view=revision&revision=1741024
>>
>> This change ensured that a call to HttpServletRequest.getRequestURI()
>> returned an encoded URL rather than a decoded one if called from within
>> a dispatched request. The Javadoc for getRequestURI() is clear that the
>> returned value is not decoded so I am confident that this change was
>> correct.
>>
>> Tomcat has required that a decoded path is used to obtain a
>> RequestDispatcher for as long as I can remember. I went back through svn
>> and this dates back to at least Tomcat 4.1.x.
>
> As I mentioned in my first mail this is what I see:
>
> * With Tomcat > 7.0.69 and > 8.0.33,
> …getRequestDispatcher("/bin/view/Main/test%20with%20space").forward(…) leads
> to .../bin/view/Main/test%2520with%2520space (note that the precent is
> encoded to %25).
>
> * With Tomcat <= 7.0.69 and <= 8.0.33
> …getRequestDispatcher("/bin/view/Main/test%20with%20space").forward(…) leads
> to .../bin/view/Main/test%20with%20space (which is correct)
>
> Since you say that Tomcat has required a decoded path since at least Tomcat
> 4.1.x the only thing I can think of is that before 7.0.70 and 8.0.34 Tomcat
> was simply using the path as is without doing any encoding on it and starting
> with the new versions you’re now encoding it.
>
> In any case, this change is bringing an important behavior change from the
> usage of Tomcat POV (and is breaking XWiki).
>
>> Jetty (confirmed with 9.3.10) decodes the path provided to the
>> RequestDispather.
>>
>> The Servlet spec has never been clear on which paths are encoded and
>> which are decoded. I have been trying to get this fixed for a number of
>> years (e.g. [1])
Re: tomcat-users.xml
Thank you all. Thank you for the time I personally do not see anything abnormal in files next log : 27-Sep-2016 12:36:49.410 INFO [localhost-startStop-1] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. 27-Sep-2016 12:36:49.476 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory /var/lib/tomcat8/webapps/ROOT has finished in 15,797 ms 27-Sep-2016 12:36:49.510 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"] 27-Sep-2016 12:36:49.606 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 95961 ms thank you for last time. regards, vincent 2016-09-27 9:14 GMT+02:00 André Warnier (tomcat) : > On 27.09.2016 03:36, vincent wrote: > >> Hello all and all, >> >> I can not reach a "host-manager webapp" >> where is the mistake >> >> my tomcat-users.xml file : >> >> >> >> >> >> < *** where does this "<" come from ? >> > > >> >> >> >> >> >> >> >> >> >> >> >> > *** and this ">" ? >> > > >> >> > and what does the tomcat logfile say ? > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: tomcat-users.xml
Thank you, it is works : regards vincent 2016-09-27 13:23 GMT+02:00 André Warnier (tomcat) : > Hi. > > It is difficult to be sure, with the extra quoting done by the email > clients, but it seems that you have an extra pair of < > inside the > tomcat-users.xml file. > > Look between the initial and the first . > From your initial post, it looks like this : > > > < >... >... > > > > > If so, the extra "<" before the first , and the extra ">" after the > last , should not be there. > I am surprised that it does not cause an error in the log, though. > > > > On 27.09.2016 13:07, Vincent Hardy wrote: > >> Thank you all. Thank you for the time >> I personally do not see anything abnormal in files >> next log : >> >> 27-Sep-2016 12:36:49.410 INFO [localhost-startStop-1] >> org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was >> scanned >> for TLDs yet contained no TLDs. Enable debug logging for this logger for a >> complete list of JARs that were scanned but no TLDs were found in them. >> Skipping unneeded JARs during scanning can improve startup time and JSP >> compilation time. >> 27-Sep-2016 12:36:49.476 INFO [localhost-startStop-1] >> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web >> application directory /var/lib/tomcat8/webapps/ROOT has finished in 15,797 >> ms >> 27-Sep-2016 12:36:49.510 INFO [main] >> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler >> ["http-nio-8080"] >> 27-Sep-2016 12:36:49.606 INFO [main] >> org.apache.catalina.startup.Catalina.start Server startup in 95961 ms >> >> thank you for last time. >> regards, >> vincent >> >> 2016-09-27 9:14 GMT+02:00 André Warnier (tomcat) : >> >> On 27.09.2016 03:36, vincent wrote: >>> >>> Hello all and all, >>>> >>>> I can not reach a "host-manager webapp" >>>> where is the mistake >>>> >>>> my tomcat-users.xml file : >>>> >>>> >>>> >>>> >>>> >>>> < *** where does this "<" come from ? >>>> >>>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> > *** and this ">" ? >>>> >>>> >>> >>> >>>> >>>> >>>> and what does the tomcat logfile say ? >>> >>> >>> >>> - >>> 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 > >
Filter Help!
Hello everyone,
If this is not the right place to post this could you please let me know
where. I have searched the forums and Google and cannot find an answer.
I have a Servlet filter that checks to see the content length of the
request.
long contentLength = request.getContentLength();
If contentLength is greater than some configurable size, I would like to
stop the request and send back a response saying that the request is to
large.
This is being used for a file upload Everything is working, except it
seems like the ENTIRE request (or file) is sent BEFORE my redirect is
happening.
My logs are showing the correct information at the appropriate times,
but the entire request is being processed before I can send a request
back.
Is there a way to immediately cut off the request and return a
response? Is there a better way to do this?
Request Size Filter: REQUEST LENGTH=401458785
Request Size Filter: CONTENT TYPE=multipart/form-data;
boundary=---85421569618919
Request Size Filter: REQUEST = /jaxpathwi/imageAction.do
Request Size Filter: REFERER =
http://deva2231:8080/jaxpathwi/imageAction.do?dispatch=setup&mouseKey=1&diagnosisKey=1
Request Size Filter: Request is to be filtered and checked for size
Request Size Filter: REQUEST LENGTH [401458785] >= ALLOWABLE CONTENT
LENGTH [500]
Request Size Filter: NOT Allowing request
Request Size Filter: Redirecting to ->
http://deva2231.8080/jaxpathwi/imageAction.do?dispatch=setup&mouseKey=1&diagnosisKey=1
I have posted a modified version of my code to show you.
Thanks!
Matt
package filters;
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class RequestSizeFilter implements Filter {
public static final String REDIRECT = "redirect";
public static final String LENGTH = "length";
private FilterConfig filterConfig = null;
private static boolean bInitialized = false;
private String strRedirectURL = null;
private long lContentLength = -1l;
private boolean bRedirect = false;
public void init(FilterConfig config)
throws ServletException {
this.filterConfig = config;
ServletContext servletContext = filterConfig.getServletContext();
String strRedirect = filterConfig.getInitParameter(REDIRECT);
String strLength = filterConfig.getInitParameter(LENGTH);
if ((strLength != null) && (strLength.length() > 0)) {
bInitialized = true;
}
// configure the redirect URL
if ((strRedirect != null) && (strRedirect.length() > 0)) {
strRedirectURL = new String(strRedirect);
// configure redirect or forward
bRedirect = strRedirect.startsWith("HTTP://") ||
strRedirect.startsWith("HTTPS://") ||
strRedirect.startsWith("http://";) ||
strRedirect.startsWith("https://";);
} else {
bRedirect = true;
}
// configure the content length
try {
lContentLength = Long.parseLong(strLength);
} catch (NumberFormatException nfe) {
bInitialized = false;
nfe.printStackTrace();
}
}
public void destroy() {
this.filterConfig = null;
}
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
throws IOException, ServletException {
long lRequestLength = request.getContentLength();
log("REQUEST LENGTH=" + lRequestLength);
String strRequestURI =
((HttpServletRequest)request).getRequestURI();
String strReferer =
((HttpServletRequest)request).getHeader("Referer");
log("REQUEST = " + strRequestURI);
log("REFERER = " + strReferer);
String strURL = strReferer;
if ((strRedirectURL != null) && (strRedirectURL.length() > 0)) {
strURL = strRedirectURL;
}
if (lRequestLength >= lContentLength) {
if(bRedirect) {
HttpServletResponse httpResponse =
(HttpServletResponse)response;
httpResponse.sendRedirect(strURL);
} else {
RequestDispatcher dispatcher =
filterConfig.getServletContext().getRequestDispatcher(strURL);
dispatcher.forward(request, response);
}
} else {
chain.doFilter(request, response);
}
}
private void log(String strMessage) {
if (strMessage != null) {
StringBuffer sb = new StringBuffer("Request Size Filter: ");
sb.append(strMessage);
this.filterConfig.getServletContext().log(sb.toString());
System.out.println(sb.toString());
sb = null;
}
}
}
-
To unsubscribe, e-mail: [EMAI
Setup Issue tomcat 6 SLES 11 SSL
Hi, I have setup tomcat 6 on SLES 11 and secured the instance with an external certificate if authority. The following is occurring from the same machine using both IE and Firefox: http://servername.wooster.edu:8080works for both IE11 and Firefox 29 and displays the index.html https://servername.wooster.edu:8443 works for Firefox 29 and displays the index.html https://servername.wooster.edu:8443 does not work for IE11v displays "This page can't be displayed" I have changed the logging level to finest and do not see any errors in the catalina.out. Thoughts? I have the same setup on another server and I believe the files and permission levels are set the same.
RE: Setup Issue tomcat 6 SLES 11 SSL
Terence, I poked around in the configuration file and knew it was something I did to screw it up. I just scrapped the install and started from fresh. Thanks for the reply Vince DiScipio Director of Digital Infrastructure The College of Wooster P - 330-263-2612 F - 330-263-2666 -Original Message- From: Terence M. Bandoian [mailto:tere...@tmbsw.com] Sent: Wednesday, April 30, 2014 3:01 PM To: Tomcat Users List Subject: Re: Setup Issue tomcat 6 SLES 11 SSL On 4/30/2014 9:02 AM, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Vincent, > > On 4/29/14, 4:24 PM, Vincent T. DiScipio wrote: >> I have setup tomcat 6 on SLES 11 and secured the instance with an >> external certificate if authority. The following is occurring from >> the same machine using both IE and Firefox: >> >> http://servername.wooster.edu:8080works for both IE11 and >> Firefox 29 and displays the index.html >> >> https://servername.wooster.edu:8443 works for Firefox 29 and >> displays the index.html >> >> https://servername.wooster.edu:8443 does not work for IE11v displays >> "This page can't be displayed" >> >> I have changed the logging level to finest and do not see any errors >> in the catalina.out. >> >> Thoughts? I have the same setup on another server and I believe the >> files and permission levels are set the same. > What does your SSL configuration look like? > > You could also use either sslscan from the CLI or go to > https://www.ssllabs.com/ssltest/ and use their online tool to examine > the site from the outside. > > Perhaps you have a combination of protocols and ciphers that MSIE > can't handle. > > - -chris If the option is available, you might also try disabling the IE "friendly" error messages. I'm not sure about IE 11, but it seems like previous versions displayed an error message with a reddish background if they were unable to authenticate a server with a given SSL certificate. Was a certificate authority bundle supplied with the SSL certificate? If so, is it installed and configured? Were the SSL certificates on the both servers issued by the same company? -Terence Bandoian - 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
Xls mime problem
> Hello, I have this weird problem. > > I want to get tomcat to correctly set the mime type for xls files. So > I added > > > xls > application/vnd.ms-excel > > > To the conf/web.xml file. > > The odd thing is that wen I access an xls file using the browser with > the following url: > http:/localhost/filename.xls it works fine. > > When I use > http:/servname.com/filename.xls it doesn't. I just get the binary > contents of the file. > > Did anyone else have this problem? I something set up incorrectly? > > Regards, > > Vincent > If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
