IRC log for #tomcat on 20090515

00:03.20*** join/#tomcat MHSL (i=Linux@cm15.eta6.maxonline.com.sg)
01:24.30*** join/#tomcat khapa (n=khapa@innovax.com.sg)
02:15.07*** join/#tomcat perr0 (n=dalanis@c-75-72-9-167.hsd1.mn.comcast.net)
02:59.04*** join/#tomcat barkbarkmeow1 (n=barkbark@Pf706.p.pppool.de)
03:07.32*** join/#tomcat Internat (n=nf@123-243-184-161.static.tpgi.com.au)
03:24.18*** join/#tomcat acidjnk (i=acid@pD950A3C6.dip0.t-ipconnect.de)
03:41.44*** join/#tomcat Liam (n=chatzill@penblp2lic8.penb.aber.ac.uk)
03:42.41LiamWTF
05:46.51*** join/#tomcat Mike_L (n=leonhard@shevek.tamale.net)
05:47.04Mike_Llooks around
05:48.26*** join/#tomcat sluimers (n=hello@82-171-16-94.ip.telfort.nl)
05:53.12Mike_Lis there some trick to getting Tomcat to automatically fix urls to add a missing slash?
05:53.44deeboerm missign slash from?
06:03.09sluimerstomcat6.0.18, Ubuntu-server 9.04, java6
06:04.15Mike_Llike www.foo.com?blahblah used to work but now we have to do www.foo.com/?blahblah
06:05.54sluimersI'm trying to Deploying a Web Application using a context fragment, but after making one in webapps, how does one deploy the war file? without restarting tomcat?
06:25.18sluimersnever mind, I figured something out
06:33.10*** join/#tomcat dvayanu (n=another@ppp-88-217-60-113.dynamic.mnet-online.de)
07:32.44*** join/#tomcat a4akba (n=chatzill@62.215.44.27)
07:33.22a4akbaHi
07:34.15*** join/#tomcat IBM_USER (n=chatzill@210.82.83.1)
07:34.34IBM_USERhi
07:52.11*** join/#tomcat shashi_ (n=shashi@122.181.1.158)
08:53.18*** join/#tomcat dvayanu (n=another@host-62-245-224-138.customer.m-online.net)
09:08.34*** part/#tomcat khapa (n=khapa@innovax.com.sg)
09:15.25*** join/#tomcat dvayanu_ (n=another@host-62-245-224-138.customer.m-online.net)
09:40.23*** join/#tomcat Vanuatoo (n=Vanuatoo@92.54.192.70)
09:50.06*** join/#tomcat acidjnk (i=acid@pD950A3C6.dip0.t-ipconnect.de)
10:20.49*** join/#tomcat unlord (i=ptolemy@pool-173-73-173-234.washdc.fios.verizon.net) [NETSPLIT VICTIM]
10:22.02*** join/#tomcat ignition (n=kvirc@dslb-084-058-046-148.pools.arcor-ip.net)
10:47.12*** join/#tomcat Mike_v_V (n=mike_v_v@surfbureau-router.Customer.surf.net)
11:11.44ignitionhi! i have to move tomcat 5.5.23 from one server (old hardware) to a new server (new hardware).
11:12.00ignitionit should be just the same setup, less one webapp.
11:13.17ignitioni've copied over the tomcat files in the directories where i think they belog and tomcat starts, but it can't find the webapps. i'm getting a 404 response code when trying to access them.
11:13.46ignitiondo you know in what file i have to check if the paths are set correctly?
11:35.09*** join/#tomcat CarstenP2 (n=asdf@78.110.224.68)
11:36.26CarstenP2Hi! I am using tomcat 5.5.27 on an ubuntu 8.04 system with java 1.6.07.
11:38.35CarstenP2i am currently experimenting with clustering and with mod_jk, and it looks like everything works. in the catalina out i can see when replication members are added, and i can see, when member disappear. but i have some general questions.
11:40.25CarstenP2first of all, if i would deactivate the clustering configuration elements on both tomcats, i would assume that the apache http server would with modjk would still loadbalance on both tomcats, right?
11:41.53*** join/#tomcat dvayanu (n=another@host-62-245-224-138.customer.m-online.net)
11:51.25*** join/#tomcat bblfish (n=bblfish@nat/sun/x-e0a903fd7e86563d)
11:52.03bblfishhi I am trying to get the ssl session manager. There used to be an attribute javax.servlet.request.ssl_session_mgr
11:52.20bblfishbut it no longer seems to be in the trunk of 6.0
11:52.37bblfishI need this to break the ssl session
11:53.51bblfish(org.apache.tomcat.util.net.SSLSessionManager) request.getAttribute("javax.servlet.request.ssl_session_mgr"); mgr.invalidateSession(); response.setHeader("Connection", "close");
11:54.18bblfishis some code that I found that I am looking to implement
12:16.29*** join/#tomcat down (n=down@217.74.211.34)
12:23.28*** join/#tomcat perr0 (n=dalanis@206.55.176.26)
12:26.18*** join/#tomcat bokal (n=bokal@unaffiliated/bokal)
12:31.06*** join/#tomcat barkbarkmeow (n=barkbark@g224152137.adsl.alicedsl.de)
12:40.44bokalTC: 5.5.26, Java: 1.6.0_10-b33, OS: Linux (Ubuntu 8.10) 2.6.27-14 I have a problem with UTF-8 chars getting displayed wrong in browsers, does anybody know if there might be an isue? I have res.setCharacterEncoding("utf-8"); in my servlet (where res is the HttpServletResponse)
12:46.15bblfishI am looking at the tomcat http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk
12:46.43bblfishit looks like https://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/net/ has the https://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/net/SSLSessionManager.java
12:47.53*** join/#tomcat ramteid (n=ramteid@83-64-52-210.fadingerstrasse.xdsl-line.inode.at)
12:48.09bblfishmhh indeed it does
12:48.23bblfishSo this is perhaps a Tomcat 7 feature I am looking for....
12:48.44*** join/#tomcat ramteid (n=ramteid@83-64-52-210.fadingerstrasse.xdsl-line.inode.at)
12:50.10ramteidI just wonder if anyone here had success using Tomcat 5.5.26 with SSL under AIX with IBM Java5 implementation. (It doesn't work, I get "SSL handshake errors", however, with Java 1.4.1 it works fine.)
12:54.26ramteid(it works with Java5 under Mac OS X, so, I'm rather sure it's a problem with IBMs JVM)
13:05.14*** join/#tomcat azlev (n=ze@200.234.206.72)
13:37.18bblfishI am looking for more info on Tomcat 7
13:40.17bblfishcan't find a wiki page on tomcat7. Is there some place one can find out what changes are being worked on?
13:56.11*** join/#tomcat jasonb (n=jasonb@adsl-66-124-73-250.dsl.sntc01.pacbell.net)
14:02.03bblfishas I am trying to get tomcat 7 working, and I am working with maven, and ideas how to get the servlet 3?
14:07.05MHSLwhy do you even need to use servlet 3?
14:07.41MHSLtomcat should include servlet-api and jsp-api jar files as usual
14:08.32MHSLand utf-8 has nothing to do with servlet/jsp version
14:09.25MHSLbblfish, try to set URIEncoding and/or useBodyEncodingForURI http://tomcat.apache.org/tomcat-5.5-doc/config/http.html
14:09.44bblfishMHSDL, hi
14:10.47bblfishMHSL I need tomcat 7, because I want to close an ssl session ant I can do it like this I think:
14:10.47bblfishTo terminate an SSL session, use:
14:10.47bblfish/ Standard HTTP session invalidation session.invalidate(); // Invalidate the SSL Session org.apache.tomcat.util.net.SSLSessionManager mgr = (org.apache.tomcat.util.net.SSLSessionManager) request.getAttribute("javax.servlet.request.ssl_session_mgr"); mgr.invalidateSession(); // Close the conection since the SSL session will be active until the connection // is closed response.setHeader("Connection", "close"); Note that this code is Tomcat speci
14:11.20*** join/#tomcat randrew (n=raj@dyn-128-59-53-15.dyn.columbia.edu)
14:11.21MHSLbblfish, use pastebin pls
14:12.52bblfishMHSL: http://pastebin.com/f3bbc11c6
14:13.52MHSLfrom what i know, session.invalidate is sufficient, although i may be wrong
14:14.15bblfishis this new for Tomcat 7?
14:14.26MHSLwhat is?
14:14.31MHSLnoone is using tomcat 7
14:14.43bblfishsession.invalidate() to close an ssl session?
14:15.14*** join/#tomcat clajo04_ (n=clajo04_@cpe-67-243-136-111.nyc.res.rr.com)
14:15.19MHSLi dont see why you need to worry whether it's ssl or not, a session is a session, as per the api, you should simply use HttSession class to manage your sessions
14:15.26bblfishI did not try session.invalidate() to close a ssl session, but I saw a lot of mails, and nobody seemed to suggest that as a solution
14:15.46MHSLwell, i really dont know where you get this kind of idea
14:15.51bblfishWell, we are using client certificates
14:15.54MHSLbut i've never seen it myself
14:16.03MHSLic
14:16.19bblfishand you can imagine that someone logs in with one certificate, then wishes to use another
14:16.28MHSLin that case then i'm not too sure, but if it's fundamental, i dont see why tomcat 5 or 6 dont have this
14:16.45bblfishwell, very few people use client certificates
14:16.54MHSLyou may want to wait for jasonb to get online or pfn or others
14:17.47bblfishWe are developing a protocol, which does what OpenId does but is much easier to use for the end user, requires much less connections, is secure, and happens to work with existing browsers
14:17.53bblfishHere is the latest paper on it: http://blogs.sun.com/bblfish/entry/foaf_ssl_restful_authentication_for
14:19.27MHSLic, ok i have no experience in this, may want to wait for jasonb or pfn
14:19.41bblfishyep will do thanks
14:20.45CarstenP2I use tomcat 5.5.27 on ubuntu 8.04 with java 1.6 . I use two clustered tomcats on different ports on localhost with different jvmroutes (node01, and node02) i activated in node01 the farmdeployer and configured it to pathoflocaltomcat01/temp/war-listen ... etc. i developed a small test WAR that has the distributable entry in the web.xml. but when i copy the file in the war-listen folder, nothing happens. what am i doing wrong?
14:22.32MHSLfarmdeployer and configured it to pathoflocaltomcat01/temp/war-listen -> are you talking about farm war deployer temp directory?
14:22.45MHSLthat is usually the farm war deployer temp directory not the directory where you deploy your webapp
14:23.29jasonbbblfish: MHSL is correct that session.invalidate() is sufficient for ending an HTTPS session, and that compliant servlet containers like Tomcat must treat all sessions alike when the Servlet API is being used.
14:24.31bblfishmhh, ok, let me try that. I wonder then why that SSLSessionManager is in tomcat 7
14:25.56CarstenP2MHSL, i configured tempDir="temp/war-temp/" deployDir="temp/war-deploy" and watchDir="temp/war-listen"
14:25.57jasonbbblfish: It's a class in the Tomcat 7 container system that manages all of the SSL sessions.
14:27.12bblfishjasonb: ok but then it is also odd that it appears in Globals     public static final String SSL_SESSION_MGR_ATTR = "javax.servlet.request.ssl_session_mgr";
14:29.10bblfishtesting on trunk of tomcat 6 request.getSession().invalidate();
14:48.38CarstenP2okay, i still dont get it. i found out that the paths that you enter in ther server.xml for the FarmDeployer should be absolute.
14:49.48CarstenP2when i now copy my war file into the war-listen folder, i see a file Modified, then installing webapp, and in the same second a "cluster wide" remove of web app....
14:52.50*** join/#tomcat unlord (i=ptolemy@pool-173-73-173-234.washdc.fios.verizon.net)
15:08.32bblfishjasonb: I don't think that works. It would only work if every time one created a client ssl session, an http session were also created
15:11.05jasonbbblfish: In all compliant Java Servlet containers, the Servlet session is one and the same as the SSL session.. they are never separate.  So, it works -- if you invalidate the Servlet session, then at that time you're invalidating the SSL session.
15:12.43bblfishjasonb: is that written somwhere? Because it does not seem to be working with tomcat 6 - on my version at least. I connect via https, the server asks for the client certificate, but I don't have web session - perhaps a bug of mine...
15:13.28*** join/#tomcat sgojgini (n=sgojgini@174.7.91.10)
15:16.37jasonbbblfish: With HTTPS, the client side of the connection does not have an HTTPS session ID until the HTTPS connection is established.  On the server side of the connection, the Servlet session ID (which is an HTTPS session ID) is only available once the HTTPS connection is established, but no servlets nor filters could run before that's complete anyway.
15:19.53sgojginiwhere do I find logs for SSL failure with tomcat 5.5 on windows xp and jdk 1.4
15:45.46*** part/#tomcat CarstenP2 (n=asdf@78.110.224.68)
15:56.23bblfishwell I quite clearly have an https session, and no http session.  request.getSession(false); returns null
15:59.20pfnwhat are you trying to accomplish?
15:59.25pfnif you want to use another client cert
15:59.32pfnissue a request with a different client cert
15:59.35pfnwhat's the problem?
15:59.45pfnyou obviously aren't using container auth here
16:07.49bblfishpfn: I am creating an Identity provider http://blogs.sun.com/bblfish/entry/a_simple_foaf_ssl_identity
16:09.57bblfishpfn: so I need to find a way to break the ssl session from the server, because there is no way to do this from the browser
16:10.14bblfishso that the user can log in with a different certificate
16:10.17*** join/#tomcat arreyder (n=arreyder@unaffiliated/arreyder)
16:10.27bblfishI am going to try the tomcat 7 and see if that helps
16:10.39bblfishif it does, then that will help the discussion
16:10.45*** join/#tomcat harbulot (n=harbulot@mirabelle.rcs.manchester.ac.uk)
16:11.11bblfishpfn: harbulot here understands a lot more than I do about ssl
16:13.12harbulotSorry, I missed the beginning of the conversation here.
16:13.23harbulotWe're not using container authentication, indeed.
16:13.53*** join/#tomcat dmulter (n=dmulter@adsl-76-201-174-14.dsl.pltn13.sbcglobal.net)
16:14.11pfnwhat do you mean by "break the session"
16:14.18pfneach connection is an individual *ssl* session
16:14.53pfndo you mean HTTP session or the SSL connection?
16:15.31pfnsession.invalidate won't close the connection, but Connection: close will
16:15.41pfnonce that's done, the next request can be initiated using a different client cert
16:17.00bblfishpfn: you mean connection.close as in :          if (sess!=null) sess.invalidate(); response.setHeader("Connection", "close");
16:17.02bblfish?
16:17.03sgojginiis there a difference starting tomcat standlone and from inside eclipse
16:17.17pfnif your browser isn't prompting you for a new certificate when you initiate a new connection, it's the browser's fault
16:17.18harbulotWe're talking of the SSL session, specifically to "log out" the user who's using a client certificate. Invalidating the SSL session should be sufficient.
16:17.25pfnit's caching the association of the certificate with the given site/uri
16:17.30sgojginimy https connection works when I start it from inside eclipse
16:18.06harbulotIt's not necessarily caching the association, but the browser usually keeps the connection alive until the SSL session expires.
16:18.55pfnthe close response header is good enough to get around that
16:19.43bblfishok. so either this is a browser bug, as the browser keeps sening the same key, or it's something else
16:20.09pfnyou can verify this quite simply:  check open ssl connections after sending the connection-close header
16:20.32pfnif you're using firefox, use the headerspy addon so that you can be sure that the header is actually set
16:20.49pfnonce you verify these things, then you can proceed to the next step
16:20.49harbulotLast time I tried "Connection: close", Firefox didn't close the connection. It's just a warning from the server that the server is going to close the connection, but I don't think it necessarily does it, thus the browser may or may not close it itself.
16:21.17bblfishthis is the the code I was testing: http://pastebin.com/fd8f275
16:21.41bblfishmy sessions were always null
16:22.27pfnharbulot, well, verify the items I mentioned first
16:22.37bblfisheven though the server keeps being able to access the client certificate
16:22.39harbulotSomeone said earlier that closing the servlet session implied closing the SSL session. Any reference for this?
16:22.58pfnshrugs
16:23.10pfnI doubt it, check SessionManager code on what it does for invalidate
16:27.59*** part/#tomcat lgbr (n=Name@laserbunny.net)
16:38.51harbulotI've only had a brief look, but I don't see anything in the code that would invalidate the underlying SSL session. I can't see anything about it in the Servlet spec either.
16:39.32pfnstop calling it the underlying ssl session
16:39.36pfnit's the connection
16:39.59pfndoes the connection get closed or not
16:40.02pfnthat's all there is to it
16:40.15pfnif not, then investigate on how you could close the connection
16:40.29pfne.g. by using a valve that detects Connection: close and then forcefully closing
16:40.54pfncalling it a "session" in this context is very confusing, you keep looking to HttpSession.invalidate
16:40.59pfnwhich really is unrelated
16:41.29pfnall invalidate *MUST* do is clear the jsessionid "cookie" of any state and make said cookie invalid
16:43.39harbulotOK, but how should I call it then?
16:43.46pfnthe ssl connection
16:43.53pfnat least in relation with http
16:43.59pfnor java in this case
16:44.07pfnso that you don't confuse the meaning of "session"
16:45.43pfnwhich seems to be the case here
16:45.50harbulotYes, but Tomcat is able to invalidate the SSL session without closing the connection when doing renegotiation to ask for cert when one hadn't been asked for in the first place. This hasn't much to do with the servlet session indeed, but both are used. What we're trying to do is to renegotiate the other way around (i.e. invalidate, re-handshake and not present a certificate), which can indeed be achieved more simply by closing the connect
16:46.17*** join/#tomcat dvayanu (n=another@ppp-88-217-60-113.dynamic.mnet-online.de)
16:46.25pfnI wouldn't think tomcat will offer any easy way for you to renegotiate the ssl connection
16:46.35harbulotit does
16:46.45harbulot(at least from no cert to asking for a cert)
16:47.25pfnit lets you do this at a point other than the beginning of the transaction?
16:47.42pfndoubts again
16:47.53pfn&
16:48.26harbulotif your connector is configured for 'want' a certificate and if your webapp requires CLIENT-CERT, this will trigger a renegotiation when you go to that particular servlet
16:49.56harbulothttps://grizzly.dev.java.net/issues/show_bug.cgi?id=416
16:50.18harbulot(there's some packet analysis using wireshark for Tomcat and Grizzly)
16:51.21harbulotNot all containers support this (in particular there's this bug with Grizzly/Glassfish, and I don't think there's any support in Jetty.
17:16.03*** join/#tomcat relachs (n=relachs@f048252252.adsl.alicedsl.de)
17:28.49*** join/#tomcat azlev (n=ze@200.234.206.72)
17:40.55*** join/#tomcat jasonb (n=jasonb@75-144-23-117-SFBACA.hfc.comcastbusiness.net)
18:01.07sgojginidoes eclipse start tomcat differently than windows launcher ?
18:21.25*** join/#tomcat magentar (n=magentar@94.79.154.7)
18:35.45bblfishpfn: ok I got it working with tomcat 7
18:35.48*** join/#tomcat relachs (n=relachs@f051021216.adsl.alicedsl.de)
18:36.08bblfishI'll wrap it up and write up a review to tomcat dev
18:37.19*** join/#tomcat trifon (n=chatzill@78.90.231.138)
18:56.33pfndoesn't read tomcat-dev
19:12.24*** join/#tomcat oxli (n=oxi@unaffiliated/oxi)
19:33.48*** join/#tomcat fubada (n=fubada@ool-4b7faf03.static.optonline.net)
19:33.54fubadahey anyone using syslog with log4j
19:33.56fubada?
19:34.28pfnwhat about it
19:34.40fubadaim trying to get it going but no dfice
19:34.42fubadadice
19:34.50fubadalocal3.* not writing any output
19:34.56pfnwhat version of syslog are you using?
19:35.00fubadado i need to have my syslog listening on UDP 514?
19:35.04fubadaim using rsyslog
19:35.05pfnof course
19:35.10pfnhow else is it going to receive messages
19:35.13fubadabut, its on the same box
19:35.20pfndoesn't matter
19:35.23fubadawhy cant it use unix sockets or whatever
19:35.27fubadalike the rest of the apps
19:35.41pfnbecause unix sockets aren't supported by java
19:35.51fubadaok so is TCP suported?
19:35.59pfnof course
19:36.24fubadalast i checked log4j only does udp
19:36.26fubadaare you sure?
19:36.34pfnudp is not unix sockets
19:36.42fubadai know this
19:36.59fubadaim asking you if log4j is able to reach syslog on 514/tcp
19:37.17fubadafrom the apache wiki its only capable pf 514/udp
19:37.29pfnwhy do you have syslog listening on 514/tcp?
19:37.40fubadai have a central rsyslog server working over tcp
19:37.51fubadafor reliable delivery and queing if logging server is down
19:37.55fubadaudp doesnt allow for that
19:38.08pfntcp won't either
20:00.48*** join/#tomcat meng (n=kymeng@adsl-99-173-26-232.dsl.pltn13.sbcglobal.net)
20:01.23menghi, does tomcat juli logger support log rotation?
20:04.20*** join/#tomcat agemo (n=jovdmeer@igwe16.vub.ac.be)
20:12.13fubadahey is this ledgit
20:12.14fubadalog4j.rootLogger=INFO, logfile
20:12.14fubadalog4j.rootLogger=ERROR, SYSLOG
20:12.20fubadatwo rootLogger entries like that
20:30.39perr0anybody have freetype2 installed?
20:33.53*** join/#tomcat oxi (n=oxi@unaffiliated/oxi)
20:35.31agemocan anyone tell me where a "400: no host matches server name host.domain.foo" comes from?
20:35.39agemoand especially how to solve it :)
20:35.52randrewagemo: default error when request doesn't map to a servlet context.
20:37.24agemorandrew: thanks, that gives me something to go on :)
20:37.27agemoI might be back ;)
20:37.51randrewyou must study server.xml until you can see why the request isn't going where you think it should be.  : )
20:40.15*** part/#tomcat randrew (n=raj@dyn-128-59-53-15.dyn.columbia.edu)
20:46.11agemomy context is /foo, but as the app is in alpha stage, i had a foo-alpha.xml in which this context was defined...
20:46.38agemoI renamed that file to foo.xml and now it works :s why does the name of that file matter, exactly?
20:47.06agemoafter all, in the file the context is correctly defined as "/foo"
20:47.18agemooh well, at least it works :)
20:49.39fubadahi
20:50.10fubadahow come when i set a log4j.appender.Threshold to be "WARN", (the logger is INFO), it doesnt show only WARN in that destination
20:50.12fubadabut shows INFO
20:54.54*** join/#tomcat oxi (n=oxi@dyn.144-85-222-028.dsl.vtx.ch)
20:57.03agemofubada: because INFO is lower than WARN
20:57.16fubadaoh
20:57.18agemoif you set a logging level, then everything below that level is shown
20:57.19fubadawhat do i want then
20:57.24fubadaoh
20:57.32fubadai need WARN and higher
20:57.46fubadais there such a thing in appender?
20:58.44agemowait, now i'm not sure if what i've said is correct
21:03.02*** join/#tomcat dvayanu (n=another@ppp-88-217-60-113.dynamic.mnet-online.de)
21:15.51fubadaum
21:15.52fubadalog4j.appender.SYSLOG.layout.ConversionPattern
21:15.59fubadathis doesnt pass hostname to syslogd
21:16.03fubadaat all
21:17.13fubada:P
21:17.17fubadahello there
21:17.20fubadahow do i get this log4j.appender.SYSLOG.layout.ConversionPattern
21:17.23fubadato spit out hostname
21:17.28fubadain syslog entry
21:17.33fubadatheres no %h
21:38.46*** join/#tomcat a4akba (n=chatzill@62.215.39.217)
21:43.03a4akbaHola
21:43.24*** join/#tomcat bblfish (n=bblfish@nat/sun/x-cb11c89c416b1def)
21:44.07a4akbaibot boo
21:44.08ibotfor heaven's sake, a4akba, don't do that!
21:44.41a4akbaIt is good to be back.
23:32.56*** join/#tomcat Internat (n=nf@123-243-184-161.static.tpgi.com.au)
23:44.21*** part/#tomcat agemo (n=jovdmeer@igwe16.vub.ac.be)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.