RE: Tomcat 7 sometime returns wrong IP address with request.getRemoteAddr()
> From: charlesk40 [mailto:charles...@yahoo.com] > Subject: Tomcat 7 sometime returns wrong IP address with > request.getRemoteAddr() > box1 makes a request to Tomcat7 server but the request.getRemoteAddr() > returns the IP address of box2 (or box n). This problem doesn't happen > all the time which making it more difficult to debug. This kind of thing is pretty much always an application error relating to scope of a variable. For example, storing a reference to the Request object in a ThreadLocal or an instance or static variable of a servlet can lead to this kind of erroneous behavior. Difficult to find other than by meticulous code inspection. - 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
Tomcat 7 sometime returns wrong IP address with request.getRemoteAddr()
Hi, We have just upgraded the Tomcat from 6 to 7. After the upgrade, we have noticed some IP address returned from request.getRemoteAddr() is not the as expected. In more detail, we have list of client boxes making a request. Lets say, box1, box2,.. box n. box1 makes a request to Tomcat7 server but the request.getRemoteAddr() returns the IP address of box2 (or box n). This problem doesn't happen all the time which making it more difficult to debug. I've searched the tomcat-users and bugzilla for any possible known issues but couldn't find it. I would appreciate any pointers on why this might be happening. Thanks -- View this message in context: http://old.nabble.com/Tomcat-7-sometime-returns-wrong-IP-address-with-request.getRemoteAddr%28%29-tp32503787p32503787.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: websphere 7.0 JAXWS webservice deployed in tomcat 6.0.32 not working
You are right. I meant to say Tomcat 7 On Wed, Sep 21, 2011 at 2:18 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Narahari 'n' Savitha [mailto:savith...@gmail.com] > > Subject: Re: websphere 7.0 JAXWS webservice deployed in tomcat 6.0.32 not > working > > > Tomcat7 can handle Servlet3 based classes. > > But Tomcat 6 can't, so perhaps you should retry using Tomcat 7. > > - 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: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
2011/9/21 BARRON, HAROLD H CTR DISA EE : > > Apache Tomcat AJP Protocol Security Bypass and Information Disclosure > Vulnerability - (CVE-2011-3190): > 1. Mitigation options are listed here: http://tomcat.apache.org/security-5.html http://tomcat.apache.org/security-6.html Both 5.5 and 6.0 have a connector implementation that is not vulnerable to this issue 2. 5.5.34 binaries are already available for testing and have good chances to be officially released in the following days. 6.0.34 release plans have not been discussed (with 6.0.33 being released not so 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
Re: Expected Release Date
On 21/09/2011 16:15, Wilde, Bruce R. wrote: > When is Tomcat version 6.0.34 expected to be released? There are no fixed release dates, but Tomcat 6 releases about 4 times per year. p signature.asc Description: OpenPGP digital signature
Re: default realm set to JAASRealm in StandardEngine
On 21/09/2011 15:54, Michael-O wrote: > Christopher, > > Christopher Schultz schrieb: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Mike, >> >> On 9/21/2011 3:52 AM, 1983-01...@gmx.net wrote: >>> I have removed the MemoryRealm from my server.xml in Tomcat 6.0.33 >>> and noticed that the StandardEngine creates a JAASRealm [1]: >>> 21.09.2011 09:14:58 org.apache.catalina.realm.JAASRealm >>> setContainer INFO: Set JAAS app name Catalina >>> >>> What is the reasoning behind this? >> >> Maybe it's easier and safer to have a dummy Realm than no realm at all. > > I don't consider the JAASRealm as a dummy realm. Maybe a NonRealm like > NonAuthenticator would make sense. > >>> I assume that any app will fail because I have never configured the >>> JAAS config file. >> >> If you never use authentication, I suspect you won't fail. >> >> Have you actually tried it? > > No, I did not yet but will do tomorrow and will report back. I guess it > will when an app needs authentication because at least the loginConf > "Catalina" won't be found. Straw man. If your app needs an auth realm, isn't it your responsibility to provide one? There's no problem with the message above, it's INFO. p signature.asc Description: OpenPGP digital signature
Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE Team, Since Tomcat 5.5.34 has not been made available for the current Apache Tomcat Injection Vulnerability=20 (IAVA 2011-B-0114), is there a workaround for this problem until the patch is out. This software is being used on a Windows 2003 Server and the current problem is stated below: Executive Summary:=20 Apache Software Foundation has addressed a vulnerability affecting various versions of Apache Tomcat. Apache Tomcat is an open source software implementation of the Java Servlet and JavaServer Pages technologies. To exploit this vulnerability, a remote attacker would create and send a malicious request to an affected system. If successfully exploited, this vulnerability would allow a remote attacker to bypass security restrictions and obtain access to sensitive information. Technical Overview: Apache Tomcat AJP Protocol Security Bypass and Information Disclosure Vulnerability - (CVE-2011-3190): Apache Tomcat supports the AJP protocol which is used with reverse proxies to pass requests and associated data about the request from the reverse proxy to Tomcat. The AJP protocol is designed so that when a request includes a request body, an unsolicited AJP message is sent to Tomcat that includes the first part (or possibly all) of the request body. In certain circumstances, Tomcat did not process this message as a request body but as a new request. This permitted an attacker to have full control over the AJP message permitting authentication bypass and information disclosure.=20 Again, is there a workaround or a temporary mitigation process that anyone knows of that can be implemented until that patch is made available for download. Thanks Harold Barron Classification: UNCLASSIFIED=20 Caveats: NONE Classification: UNCLASSIFIED Caveats: NONE - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: websphere 7.0 JAXWS webservice deployed in tomcat 6.0.32 not working
On 21/09/2011 19:18, Caldarale, Charles R wrote: >> From: Narahari 'n' Savitha [mailto:savith...@gmail.com] >> Subject: Re: websphere 7.0 JAXWS webservice deployed in tomcat 6.0.32 not >> working > >> Tomcat7 can handle Servlet3 based classes. > > But Tomcat 6 can't, so perhaps you should retry using Tomcat 7. The OP can try but it isn't going to work. @WebService is not part of the Servlet 3.0 specification. I suggest reading this: http://tomcat.apache.org/tomcat-7.0-doc/extras.html Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: websphere 7.0 JAXWS webservice deployed in tomcat 6.0.32 not working
> From: Narahari 'n' Savitha [mailto:savith...@gmail.com] > Subject: Re: websphere 7.0 JAXWS webservice deployed in tomcat 6.0.32 not > working > Tomcat7 can handle Servlet3 based classes. But Tomcat 6 can't, so perhaps you should retry using Tomcat 7. - 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: websphere 7.0 JAXWS webservice deployed in tomcat 6.0.32 not working
Thank You Chris for your time and help. I understand that I need WebServices Engine like AXIS2 or METRO or Apache CXF. Here is the deal. Websphere7 uses AXIS2 as the WebServices engine. I have my Webservices class with Annotation of @WebService. This is then compiled to WEB-INF\classes folder. Then the war is built. Remember uptil this point I have not made any web.xml changes. Then I deploy the war file (using ear) to a Websphere7 installation. Once the deployment of war happens, something inside of AXIS2 is processing all the annotation based classes and dynamically generating the web.xml and processing the WebServices. What is the equivalent of that in Tomcat7. Tomcat7 can handle Servlet3 based classes. So I thought it should have the mechanism to process Annotated Webservices as well. -Narahari On Wed, Sep 21, 2011 at 9:53 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Narahari, > > On 9/20/2011 11:15 PM, Narahari 'n' Savitha wrote: > > I have a JAXWS webservice developed in WebSphere 7.0. It is > > working there. The stack in Websphere is Axis2.0 > > > > I wrote a POJO Java class, annotated with the @WebService > > annotation and then I did a wsgen to generate the necessary > > artifacts and created the war file. > > > > The imp thing is that web.xml does NOT have any servlets in it or > > listeners defined. > > Tomcat only implements the servlet specification, so if you want to > deploy web services, you're going to have to find a way to get that > going using a helper library -- like Axis. > > > However when I deploy that war file to Tomcat 6.0.32 and then copy > > the axis2 jars to the WEB-INF\lib folder. > > Axis needs a servlet to be mapped in order to serve requests to your > web services. > > > When I restart Tomcat, the WebService does not work. > > > > What I am curious is, how come Websphere7, deploys the WebService > > on startup without any entires in web.xml but Tomcat refuses to do > > so ? > > Websphere is a J2EE application server while Tomcat is a servlet > container "only". Maybe you want to look into using JBoss or Apache > Geronimo if you need more than servlet-based services. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk557EwACgkQ9CaO5/Lv0PAIZwCeL2Gv2db8XdIoUV8xJdDSKG7T > tx4AoLcoVshb2HK4gXlVtX4TMF+mmSMy > =CsWK > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Expected Release Date
When is Tomcat version 6.0.34 expected to be released? Bruce
Re: default realm set to JAASRealm in StandardEngine
Christopher, Christopher Schultz schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike, On 9/21/2011 3:52 AM, 1983-01...@gmx.net wrote: I have removed the MemoryRealm from my server.xml in Tomcat 6.0.33 and noticed that the StandardEngine creates a JAASRealm [1]: 21.09.2011 09:14:58 org.apache.catalina.realm.JAASRealm setContainer INFO: Set JAAS app name Catalina What is the reasoning behind this? Maybe it's easier and safer to have a dummy Realm than no realm at all. I don't consider the JAASRealm as a dummy realm. Maybe a NonRealm like NonAuthenticator would make sense. I assume that any app will fail because I have never configured the JAAS config file. If you never use authentication, I suspect you won't fail. Have you actually tried it? No, I did not yet but will do tomorrow and will report back. I guess it will when an app needs authentication because at least the loginConf "Catalina" won't be found. Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Executor thread lifecycle
Chris, I do have one other webapp deployed alongside, but neither of them ever gets reloaded. We always do a full stop/start of tomcat to roll out new builds (which is about the only time we ever stop these apps). There's absolutely no performance penalty that I'm aware of. It was just the yet-unexplained recycling of threads. FWIW, we've got the pool based solution going now, so I'm off the whole ThreadLocal bandwagon (really really small wagon). This is uber low prio from my standpoint, in case you guys want to forget I ever brought it up. :-) Thanks, Dan On Wed, Sep 21, 2011 at 9:46 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Dan, > > On 9/20/2011 4:47 PM, Dan Checkoway wrote: > > Thanks Chris. Those threads are *never* idle in this app. :-) > > They're still getting recycled periodically, it looks like, despite > > lack of idle time. > > Hmm, that does sound weird. Do you have other webapps also deployed > alongside this one? If you reload those webapps, the threads in the > thread pool will be recycled after a webapp undeployment to flush-out > any nasty stuff that might be tied to them. You can try setting the > "threadRenewalDelay" to a negative number to disable this particular > kind of recycling. > > > Does that make sense or am I on crack? > > You might still be on crack. > > Are you observing a performance penalty for this, or are you just > trying to explain an as-yet-unexplained recycling of threads? > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk556q0ACgkQ9CaO5/Lv0PADgwCfYqXFN9SBljy1LbEMUw2wEHpZ > 7NsAoK/kACgQm3tx+k9Uy0Xa9XyWIjEn > =g84G > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Links in CSS vs JSPs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 9/20/2011 4:45 PM, André Warnier wrote: > Christopher Schultz wrote: >> You can't do this unless all your JSPs are at the same directory >> level, say, in "myapp". > > Why not ? Suppose all stylesheets are in > (tomcat_dir)/webapps/myapp/css/, and all images in > (tomcat_dir)/webapps/myapp/images/, then if you have this JSP in > e.g. (tomcat_dir)/webapps/myapp/level2/mypage.jsp, and it refers to > a stylesheet, the link should be "../css/mystyle.css", that's all. > And if you have this JSP in e.g. > (tomcat_dir)/webapps/myapp/level2/level3/mypage.jsp, and it refers > to a stylesheet, the link should be "../../css/mystyle.css", that's > all. (You always know where, *relative to your JSP*, the stylesheet > is.) The URLs are relative to the resource's URI, not the file. So, if you have one file include another file like this: main_page.jsp: <%include src="subdir/subpage.jsp" %> subdir/subpage.jsp: This presents a problem because the browser is looking at http://host/webapp/main_page.jsp and the CSS reference points to http://host/css/my.css instead of http://host/webapp/css/my.css. > And if any of these stylesheets refers to an image, it should do it > as "../images/image.jpg", because by the time the broser fetches > the stylesheet, the "base href" is the URL whence the stylesheet > came from Correct. That's nice, but only if you can get the stylesheet loaded properly in the first place. It's standard, common, and recommended practice to make all URLs relative to the webapp by using the tools provided by the servlet spec to effectively build all URLs like this: All JSP tags, etc. use the same technique and it's more consistent to use those tools to build all URLs instead of special-casing all .css resources or whatever. This also avoids the problem of multi-directory-level file inclusion. > The doubt comes only in a (contrived) case like the following : > Imagine you have a JSP containing a link to a stylesheet as follows > :
Re: Availability of Apache Tomcat 6.0.34?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shanti, On 9/21/2011 1:39 AM, Yajnik, Shanti wrote: > Thanks Chris. Do you know when 6.0.34 version of Tomcat will be > available for download? Note that there is a simple workaround with affected versions: use mod_jk's "secret" setting on all your workers and on the JK connector in Tomcat and you should be safe from this attack. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk557cMACgkQ9CaO5/Lv0PCGqwCgvlHcsgojgZa45yhkEgpIwgZQ vRcAn0YawIl3VQVAD7uabMLFxeVdj72T =jeZx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Availability of Apache Tomcat 6.0.34?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shanti, On 9/21/2011 1:39 AM, Yajnik, Shanti wrote: > Thanks Chris. Do you know when 6.0.34 version of Tomcat will be > available for download? Nope. It will ship whenever the devs decide it's time for another release. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk557WwACgkQ9CaO5/Lv0PAkqgCcC0jBWW/m8/ZmRY9bGM+2h92V zhoAmweeXSAV66OcQVhUkqQw5MqTHRhL =ohdc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: default realm set to JAASRealm in StandardEngine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike, On 9/21/2011 3:52 AM, 1983-01...@gmx.net wrote: > I have removed the MemoryRealm from my server.xml in Tomcat 6.0.33 > and noticed that the StandardEngine creates a JAASRealm [1]: > 21.09.2011 09:14:58 org.apache.catalina.realm.JAASRealm > setContainer INFO: Set JAAS app name Catalina > > What is the reasoning behind this? Maybe it's easier and safer to have a dummy Realm than no realm at all. > I assume that any app will fail because I have never configured the > JAAS config file. If you never use authentication, I suspect you won't fail. Have you actually tried it? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk557M4ACgkQ9CaO5/Lv0PBgpgCdFtS71bDSLdfkmoZ3gyK/yYi5 HSAAnRCSUWy3xXB7IAKT7qj6ToNhP0Ls =uz6n -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: websphere 7.0 JAXWS webservice deployed in tomcat 6.0.32 not working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Narahari, On 9/20/2011 11:15 PM, Narahari 'n' Savitha wrote: > I have a JAXWS webservice developed in WebSphere 7.0. It is > working there. The stack in Websphere is Axis2.0 > > I wrote a POJO Java class, annotated with the @WebService > annotation and then I did a wsgen to generate the necessary > artifacts and created the war file. > > The imp thing is that web.xml does NOT have any servlets in it or > listeners defined. Tomcat only implements the servlet specification, so if you want to deploy web services, you're going to have to find a way to get that going using a helper library -- like Axis. > However when I deploy that war file to Tomcat 6.0.32 and then copy > the axis2 jars to the WEB-INF\lib folder. Axis needs a servlet to be mapped in order to serve requests to your web services. > When I restart Tomcat, the WebService does not work. > > What I am curious is, how come Websphere7, deploys the WebService > on startup without any entires in web.xml but Tomcat refuses to do > so ? Websphere is a J2EE application server while Tomcat is a servlet container "only". Maybe you want to look into using JBoss or Apache Geronimo if you need more than servlet-based services. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk557EwACgkQ9CaO5/Lv0PAIZwCeL2Gv2db8XdIoUV8xJdDSKG7T tx4AoLcoVshb2HK4gXlVtX4TMF+mmSMy =CsWK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Executor thread lifecycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan, On 9/20/2011 4:47 PM, Dan Checkoway wrote: > Thanks Chris. Those threads are *never* idle in this app. :-) > They're still getting recycled periodically, it looks like, despite > lack of idle time. Hmm, that does sound weird. Do you have other webapps also deployed alongside this one? If you reload those webapps, the threads in the thread pool will be recycled after a webapp undeployment to flush-out any nasty stuff that might be tied to them. You can try setting the "threadRenewalDelay" to a negative number to disable this particular kind of recycling. > Does that make sense or am I on crack? You might still be on crack. Are you observing a performance penalty for this, or are you just trying to explain an as-yet-unexplained recycling of threads? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk556q0ACgkQ9CaO5/Lv0PADgwCfYqXFN9SBljy1LbEMUw2wEHpZ 7NsAoK/kACgQm3tx+k9Uy0Xa9XyWIjEn =g84G -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: manager and host-manager have 401.jsp that is not used
On 21/09/2011 01:03, Manger, James H wrote: >> On 20/09/2011 08:31, Manger, James H wrote: >>> The manager and host-manager apps included with Tomcat 7.0.21 are both: >>> * configured to use BASIC authentication; and >>> * configured with a custom error page for 401 (unauthenticated) error codes. >>> However, the customer error page is never used by Tomcat. >>> >> ... >>> The 401.jsp file has lots of useful information that would be helpful to >>> display to a user if they cancel their browser's BASIC login prompt. > >> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml >> >> Currently the 4th entry for 7.0.22 >> >> Mark > > Great! > I confirmed 401.jsp is being used properly in 7.0.20. > > I couldn't find any release schedule for 7.0.22 (with the fix) at the Tomcat > web site. Are tentative release dates listed anywhere? Tomcat releases appear > to be frequent enough (about monthly, thanks!!) that a date for the next > release is not too crucial, but it would be nice to have an estimate now that > I know it includes a fix I want. Tomcat releases happen as the need arises and as the committers (who are volunteers after all) have time to generate them. As the current Tomcat 7 release manager, I have been producing a Tomcat 7 release at roughly the beginning of each month since the first release. I have no plans at the moment to change this cycle so I'll start the next release around the beginning of October and if all goes well it should be available a week or so later. As with any such plans they may slip if life and/or work need me to spend my time elsewhere. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
default realm set to JAASRealm in StandardEngine
Hi folks, I have removed the MemoryRealm from my server.xml in Tomcat 6.0.33 and noticed that the StandardEngine creates a JAASRealm [1]: 21.09.2011 09:14:58 org.apache.catalina.realm.JAASRealm setContainer INFO: Set JAAS app name Catalina What is the reasoning behind this? I assume that any app will fail because I have never configured the JAAS config file. Mike [1] http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardEngine.java?view=markup#l153 -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
