bug 33463: realy fixed?
Hi, I've just wrote a unit test to verify this bug has fixed (http://issues.apache.org/bugzilla/show_bug.cgi?id=33463). But looking at the code in StandardContext: 4276 // Stop our application listeners 4277 listenerStop(); 4278 4279 // Clear all application-originated servlet context attributes 4280 if (context != null) 4281 context.clearAttributes(); I doubt it will works since in listenerStop, we set all the listeners to null: 3711 setApplicationEventListeners(null); 3712 setApplicationLifecycleListeners(null); 3713 3714 return (ok); So when we call clearAttributes in ApplicationContext: 691 // Notify interested application event listeners 692 Object listeners[] = context.getApplicationEventListeners(); 693 if ((listeners == null) || (listeners.length == 0)) 694 return; 695 ServletContextAttributeEvent event = 696 new ServletContextAttributeEvent(context.getServletContext(), 697 name, value); The listeners[] are always null. Should the clearAttributes be called before? It was like that before but I don't understand why we moved the call after listenerStop(). Also, there is a couple of Catalina's private attributes available to the listener that should'nt be in StandardContext: 4072 // We put the resources into the servlet context 4073 if (ok) 4074 getServletContext().setAttribute 4075 (Globals.RESOURCES_ATTR, getResources()); Should we add: context.setAttributeReadOnly(Globals.RESOURCES_ATTR); so this way the listener doesn't get notified with those read only attribute? Thanks -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ByteBufferAccessLogValve.java mbeans-descriptors.xml
Remy Maucherat wrote: Jean-Francois Arcand wrote: Without access log valve, we are 20% faster. With the ByteBuffer one, 13%. There are 3 access log valves ;) Maybe you should give a chart. I did formally benchmark + FastCommonAccessLogValve + ByteBufferAccessLogValve I didn't bother about AccessLogValve. I did a lot of exploration: + use a ByteBuffer, call ByteBuffer.asCharBuffer() and then use CharBuffer.put() (no StringBuffer/ThreadLocal). Works fine except there is some garbage in the log since when a CharBuffer view buffer is used against a ByteBuffer or using ByteBuffer.putChar(char x) will result in '^' (control) characters and null characters to be written to the ByteBuffer. These '^' (control) characters then get written to the access log. + StringBuffer without a ThreadLocal. + CharBuffer.allocate() with a ByteBuffer.allocateDirect() I did also try to synchronize the valve invoke method and use the current thread to write the log (instead of using a background thread/writter thread). I'll do my byte based improvements (to be able to save on char to byte) in your implementation. The buffer isn't big enough. 16k will hold 500 requests maximum. If you were afraid of doing one I/O operations, it's bad, as you'll end up doing a lot of I/O synchronously. Can we allow the buffers to grow ? Yes, but growing a direct byte buffer is very bad. I did put 16k as a baseline. Using a 128k will gives better results, but 256k didn't. At least they would need to be a lot bigger otherwise (we could reinvest the memory saved from not having a background thread :) ). Another trick if you want to tweak the interval inside the valve, you can use an integer that you increment and do a modulo (i % n). I do that for the manager checks (one check every 6 invocations of backgroundProcess). Yes, I can explore that. I will re-add the writerThread for now since the current implementation doesn't work since the byteBuffer will never be flushed. This is temporary. Again, consider this valve as exploration. -- Jeanfrancois Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ByteBufferAccessLogValve.java mbeans-descriptors.xml
Remy Maucherat wrote: Jean-Francois Arcand wrote: Yes, I can explore that. I will re-add the writerThread for now since the current implementation doesn't work since the byteBuffer will never be flushed. This is temporary. Again, consider this valve as exploration. I do agree to some extent with the rest (except your benchmark results, which look wrong) Well, I do trust my performance team :-) , but I cannot agree to this. If you want to play with something on your own, then don't contribute it or place it in an experimental folder. Fine. I will remove it. -- Jeanfrancois Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ByteBufferAccessLogValve.java mbeans-descriptors.xml
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2004/11/19 08:46:27 Modified:catalina/src/conf server.xml catalina/src/share/org/apache/catalina/valves mbeans-descriptors.xml Added: catalina/src/share/org/apache/catalina/valves ByteBufferAccessLogValve.java Log: Add an asynchronous byte buffer based access log valve. The valve use a direct byte buffer to store and save the log. I didn't use the backgroundProcess since it's affect all components, but this should be revisited. Benchmarking this valve using jservlet (scalabilty) and trade2 (throughput) demonstrated a 13% improvement over the current access log valves. Increasing the writerInterval improve performance too. Note: I've tried to use a direct CharBuffer instead of a StringBuffer, and its slower that the current approach (and the log contains garbage, thank to a bug in NIO). I disagree with this. The idea is that there is already an fast access logger. How about improving that one instead ? Yes, I can do that. Mine was first experimental, then based on the result I've got, I decided to act like Costin (commit experimental stuff :-) :-)) It is also not acceptable to use a background thread for this sole purpose (backgroundProcess is not server global - by default, it is, but that's all you can say about it). Fine. It's easy to remove it. BTW, there's no way you get +13% over the fast access logger, since it has about 6% overhead on a static file test (compared with 25-30% for the normal one) ;) Well, it approx. 20% without valve. Note that all benchmarks uses two machines, and both use 250 users and dynamics pages. -- Jeanfrancois Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session PersistentManagerBase.java StandardManager.java StandardSession.java
Remy Maucherat wrote: Jean-Francois Arcand wrote: Actually, my next steps is to allows empty field in catalina.properties, which will disable the mechanism (next commit :-)). Right now you can only disable the mechanism by removing the catalina.properties or if you use the Embedded interfance. By default I still want to keep Tomcat as secure as possible, but leave the door open for disabling the mechanism. As an example, when Tomcat gets benchmarked against other unsecure container with security turned on, people will think Tomcat is slower, which is not right. I don't understand. This configuration will make security useless, so what's the point ? Why not just disable security if it's going to be useless ? It's not useless. Normal permissions are still turned on. It's only the package protection that is disabled. When disabled, Tomcat 5 is as unsecure as Tomcat 4 in term of sniffing/loading classes, but still secure in term of browsing the file system etc. -- Jeanfrancois Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ByteBufferAccessLogValve.java mbeans-descriptors.xml
Remy Maucherat wrote: Jean-Francois Arcand wrote: BTW, there's no way you get +13% over the fast access logger, since it has about 6% overhead on a static file test (compared with 25-30% for the normal one) ;) Well, it approx. 20% without valve. I can't understand what you mean here. Without access log valve, we are 20% faster. With the ByteBuffer one, 13%. -- Jeanfrancois Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session PersistentManagerBase.java StandardManager.java StandardSession.java
Remy Maucherat wrote: Jean-Francois Arcand wrote: It's not useless. Normal permissions are still turned on. It's only the package protection that is disabled. When disabled, Tomcat 5 is as unsecure as Tomcat 4 in term of sniffing/loading classes, but still secure in term of browsing the file system etc. Possibly. But I don't know what you can do with access to the Tomcat internals, and hacking the container is a bad security problem IMO. I don't see how you could want half assed security. Oh wait, there's Window$, so I guess there are takers ;) LOL BTW, Tomcat 4 did package protection. Yes. I was meaning the improvement we did 2 years ago that ends up adding all thoses doPrivileged blocks as well as the catalina.properties list. -- Jeanfrancois Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContextFacade.java ApplicationFilterChain.java StandardWrapper.java
Bill Barker wrote: @@ -1012,13 +1041,12 @@ DummyResponse res = new DummyResponse(); if( System.getSecurityManager() != null) { -Class[] classType = new Class[]{ServletRequest.class, - ServletResponse.class}; -Object[] args = new Object[]{req, res}; +serviceType[0] = req; +serviceType[1] = res; SecurityUtil.doAsPrivilege(service, servlet, - classType, - args); + classTypeUsedInService, + serviceType); } else { servlet.service(req, res); } This can't possibly be thread-safe (and the changes to ACF look dubious as well). Hum...I did run a lot of stress tests that target the same servlet (ex: trade2 benchmarks) without seeing anything like that. I will investigate This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContextFacade.java ApplicationFilterChain.java StandardWrapper.java
Remy Maucherat wrote: Jean-Francois Arcand wrote: Bill Barker wrote: This can't possibly be thread-safe (and the changes to ACF look dubious as well). Hum...I did run a lot of stress tests that target the same servlet (ex: trade2 benchmarks) without seeing anything like that. I will investigate I think there will be thread safety problems too. There's no way around instantiating argument arrays here. I agree. I've reverted the patch. The only solution will be to nulllify all objects after every calls. I also think the shared classCache is not useful. I don't see why objectCache couldn't be static, so it could be the only cache. OK will take a look. Thanks -- Jeanfrancois Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Interesting usage of Tomcat...
Costin Manolache wrote: Mladen Turk wrote: Shapira, Yoav wrote: http://www.theserverside.com/talks/VendorPerspectives/Mainsoft/interview .tss Yes, indeed :) Almost a year ago I proposed a project that would enable Tomcat to seemesly integrate the legacy code. Something like moving the perspective from being an backend to becoming an integrator. Of course, the reaction was not much in favor :). But seems that the direction is to integrate as much of those 'million lines written' as possible. Regards, MT. We know more now than we did one year ago :-) Beeing able to integrate our code in other apps and other apps in our code is indeed becoming more and more important. plug and guess what I'm talking about at Apache Conf 2004 ;-). /plug OK that was an easy plug :-) -- Jeanfrancois Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat, other AppServer and ServletSpec_2.3
Hi, Tomcat behaviour is the right one (I've sopken with the spec lead). File a bug against your Container (or move to Tomcat :-) ) Thanks -- Jeanfrancois [EMAIL PROTECTED] wrote: I recognized a behaviour in Tomcat (version 4.1.29) and would like to no if you think this behaviour is a requirement to confirm to the servlet-spec-2.3. The reason for this question is that our production environment uses another appserver than tomcat (sorry for that!) which does not behave as expected. The support is (of course) of the opinion they do confirm to the spec. My question is about the following feature: An application which uses container security with form-based login secures a certain url (in my case a struts action). If I send a request for this url using HttpPost and the user-session is not(!) already authenticated Tomcat preserves the request parameters of the recent request after successfull authentication. This is not true for our production environment. Reading the servlet-spec-2.3 I find the following: ### J2EE.12.5.3.1 Login Form Notes ... /form If the form based login is invoked because of an HTTP request, the original request parameters must be preserved by the container for use if, on successful authentication, it redirects the call to the requested resource. ### What do you think? Regards, A. Grimm --- Anton Grimm MAN Nutzfahrzeuge AG IDP - Software Produktionsumgebungen Dachauerstr.667 D - 80995 München Fon: +49-89-1580-1054 Fax: +49-89-1580-4550 mailto:[EMAIL PROTECTED] Internet: http://www.man-trucks.com --- This message and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introduction
Hi, take a look at the current open bugs and submits patches. Someday one of us will propose you as committer, after looking at your patches :-) Thanks -- Jeanfrancois Felipe Leme wrote: Hi, My name is Felipe and I just joined the devs list recently, as I would like to more involved with Tomcat's development. Until now I just collaborated doing a few bug reports/patches (using the address nagoya AT felipeal DOT net) but now that I'm part of JSR-245 I'd like to help more (I'm also a committer for the Jakarta Taglibs project - my login at ASF is felipeal). Anyway, I'm just sending this email to offer my help if you need something specific (like fixing a bug or doing some tests, including the TCKs). Right now I'm just reading 'How Tomcat Works' and preparing myself to JavaOne - but once I get back from the conference, I could do more. Regards, Felipe PS: hopefully I can meet some of you guys/gals at JavaOne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAut
Nelson, Luke wrote: I tested it and it didn't throw the exception indicated earlier in this thread. I would rather this part of the patch be replaced with something more robust. There really isn't a need to test for the timeout as we should be able to know how the session expired by the session itself providing that information. Can you please double check, with Tomcat 5, that listeners are properly called when the session expire? This is an are where we are frequently regressing I don't have time now to test the patch (will take a look latter today) -- Jeanfrancois Luke -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 1:49 PM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat- catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAut Nelson, Luke wrote: Brian, I believe I just fixed those issues. See the latest patch to 9077. Did you actually test it ? Your patch calls getLastModified, does this really work if the session *did* timeout (and as such is no longer valid) ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: J2EE 1.4 final?
Shapira, Yoav wrote: Hi, Supposedly J2EE 1.4 has now gone final and been released. Not yet :-) Yet the link on java.sun.com hot downloads section still says J2EE 1.4 Beta 2. The JSR pages for 152 and 154 on www.jcp.org say Final Approval Ballot is completed, so I suppose the spec are indeed final? Yes, they are. The J2EE link on sun.com will be updated soon. -- Jeanfrancois Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenti cator SingleSignOnEntry.java AuthenticatorBase.java BasicAuthenticator.java DigestAuthenticator.java FormAuthenticator.java NonLoginAuthenticator.java SSLAuthentic
Brian Stansberry wrote: At 11:56 AM 11/24/2003 -0600, you wrote: I have tried applying the patch, and I found three problems with it. First, its removal of a session from the SingleSignOnEntry object causes an IndexOutOfBounds exception. Second, the method for determining whether the user explicitly logged out or whether a session timed out doesn't scale one of the numbers correctly (i.e. comparing millisecond values to seconds). I have fixed the patch, but I don't have a diff of it yet (I'm new to helping with this project). Finally, the patch doesn't synchronize on 'reverse' when removing an entry from it. I also looked at the code for StandardSession.getLastAccessedTime() and it looks as if it will throw an IllegalStateException if the session is expired. So that would break the algorithm used in the 9077 patch. BTW, the javadoc for javax.servlet.http.HttpSession doesn't specify throwing an IllegalStateException for a call to getLastAccessedTime(). It looks as if the exception throw was added in response to bug 15967, which stated that the javadoc does specify the exception, but I'm looking at the javadoc for both Servlet 2.3 and 2.4, and in both cases it's not specified. Hum...look at: http://java.sun.com/j2ee/1.4/docs/api/index.html quote getLastAccessedTime public long *getLastAccessedTime*() [.] *Returns:* a |long| representing the last time the client sent a request associated with this session, expressed in milliseconds since 1/1/1970 GMT *Throws:* |IllegalStateException http://java.sun.com/j2se/1.4/docs/api/java/lang/IllegalStateException.html| - if this method is called on an invalidated session /quote -- Jeanfrancois Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer: Mark Thomas
+1 -- Jeanfrancois Remy Maucherat wrote: Hi, I'd like to nominate Mark Thomas as a Tomcat committer. He has contibuted a significant amount of fixes already, and does what nobody else does: roam Bugzila to fix older issues and cleanup the database. He has special interest in the WebDAV code, which currently has no maintainer. He has my +1. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Kurt Miller as commiter
+1 -- Jeanfrancois Henri Gomez wrote: Hi to all, I would like to propose you a new tomcat commiter, Kurt Miller which as proposed many usefull patches for JK2. Since we want to deprecated jk and focus jk2, we need more people involved on jk2. Vote please. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New builds
ballot Release 4.1.29 as Stable ? [ ] Yes [ ] No /ballot ballot Release 5.0.14 as Beta ? [X] Yes [ ] No /ballot I've ran the Servlet/JSP tcks on 5.0.14 and they all passes (with and without SecurityManager). Validation is still working (wow 1 month without breaking...do not update xerces ;-) ) -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat CVS howto
I'm also having trouble those days when building the nightly build. It seems when you log in using anoncvs, you don't get all the source code. I have to use my account in order to make it work Anyone have such problem? -- Jeanfrancois Mark W. Webb wrote: I am looking for a doc that explains how to get all the necessary tomcat code out of CVS. I did a: cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout jakarta-tomcat-5 and got no java code. please advise. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: no main in Embedded.java
The Embedded.main has been removed a long time ago (at the time of introducing JMX). As for the sh/bat, I did remove the option2 days ago (just browse the list). The JMX approach is in my opinion a good alternative: http://apache.crihan.fr/dist/jakarta/tomcat-5/v5.0.12-beta/bin/jakarta-tomcat-5.0.12-embed.tar.gz I don't have any problem to bring the option back if you dig and submit a patch that bring back the Embedded.main (a lot of things has changed so be sure we are not regressing) -- Jeanfrancois Mark W. Webb wrote: I was looking at the tomcat 5.0.12 source and noticed that the file Embedded.java does not contain a main. I think that there should be one, since catalina.sh references this class as the entry point to start tomcat. PS. I do alot of work with embedded java and would like to help out more. Please let me know if I may be of any help to the people maintaining that part of tomcat. thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: no main in Embedded.java
Remy Maucherat wrote: Jean-Francois Arcand wrote: The Embedded.main has been removed a long time ago (at the time of introducing JMX). As for the sh/bat, I did remove the option2 days ago (just browse the list). The JMX approach is in my opinion a good alternative: http://apache.crihan.fr/dist/jakarta/tomcat-5/v5.0.12-beta/bin/jakarta-tomcat-5.0.12-embed.tar.gz I don't have any problem to bring the option back if you dig and submit a patch that bring back the Embedded.main (a lot of things has changed so be sure we are not regressing) That method was nothing more than an example anyway. It has no place in the distribution. I believe the Embedde API itself is still backwards compatible. Yes, it works fine.some products you may remember still use it ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5] Embedded script support?
Hi, The catalina.sh/bat script still include the embedded option (BTW no longer works since the Embedded class is not in bootstrap.jar). Do we still want to support that option or should I remove it from the script? Thanks, -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
Henri Gomez wrote: I traced TC 5.0 and Digester and suspect what could be the problem with external entities when only SYTEM is defined ie : !ENTITY appset1 SYSTEM appset1.xml !ENTITY appset2 SYSTEM appset2.xml In Digester.java, at least in the 1.5 release, resolveEntity return null if publicId is null even if systemId is set. To make it works, I just replaced : -- if (entityURL == null){ return (null); by --- if (entityURL == null){ if (systemId == null) return (null); else entityURL = systemId; } FYI, in resolveEntity we got as parms for previous app1app2 entities declaration: systemid=jndi:/localhost/myapp/WEB-INF/appset1.xml and publicid=null systemid=jndi:/localhost/myapp/WEB-INF/appset2.xml and publicid=null This hack will solve the resolution of entities presents in WEB-INF. That's strange since in Tomcat 5, the resolver is under o.a.c.u.SchemaResolver. Have you change something there? You should customize that class instead of the Digester one (will be easier and doesn't require commons-dev folks). Now for entities located outside webapp / WEB-INF. I know what the spec say about entities outside WAR but there is many case where you should serve the SAME application for many customers, and where specific settings for each customer MUST exist outside WAR. Let see my case : if the entity is defined like this : !ENTITY appset1 SYSTEM file:../etc/appset1.xml !ENTITY appset2 SYSTEM file:/var/www/customer1/etc/appset2.xml resolveEntity got systemId=file:../etc/appset1.xml and systemId=file:/var/www/customer1/etc/appset2.xml So if you have to specify a resource somewhere on your system, outside the webapp you should : 1) Know what the appBase and use .. trick to get it (relative). 2) Give an absolute reference on the file system, which is bad when you want to use the .war for many customers. Let consider the following layout for an ISP/ASP provider wich use the same application for many clients (running their own TC 5). /var/www/customer1/etc/appset1.xml /var/www/customer1/etc/appset2.xml /var/www/customer1/var/tomcat5/... /var/www/customer1/var/tomcat5/webapps/themainapp.war /var/www/customer2/etc/appset1.xml /var/www/customer2/etc/appset2.xml /var/www/customer2/var/tomcat5/... /var/www/customer2/var/tomcat5/webapps/themainapp.war You could use the file:.. trick to go from /var/www/customerx/var/tomcat5/, which is the appBase to /var/www/customerx/etc, where the customer specific settings are located. Now consider another layout for an ISP/ASP provider wich use the same application for many clients but using a shared TC5. /var/www/customer1/etc/appset1.xml /var/www/customer1/etc/appset2.xml /var/www/customer1/webapps/themainapp1.war /var/www/customer1/webapps/themainapp1/WEB-INF/... /var/www/customer2/etc/appset1.xml /var/www/customer2/etc/appset2.xml /var/www/customer2/webapps/themainapp2.war /var/www/customer2/webapps/themainapp1/WEB-INF/... themainapp1.war and themainapp2.war are copy of or symlink to the generic themainapp.war and are decompressed at startup time. TC 5 is in shared mode, so it live outside customer layout : /var/tomcat5/... You couldn't use anymore the file:.. trick to go from /var/tomcat5/, which is the appBase to /var/www/customerx/etc, where the customer specific settings are located. The only way to developpers and admins to have it works in both case is to set the current directory when web.xml is parsed to WEB-INF/. So what about having something like CATALINA_HOME/common/xml where you can put your shared file. The change the SchemaResolver to look under that folder if it isn't able to resolve the publid/system id? I may have missed something. -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Henri Gomez wrote: Remy Maucherat a écrit : Glenn Nielsen wrote: Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. So you're using entities in web.xml to load parts of the applications from files present in WEB-INF, whatever webapp location could be. !ENTITY ap_part1 SYSTEM app_part1.xml !ENTITY ap_part2SYSTEM app_part2.xml !ENTITY ap_part3SYSTEM app_part3.xml ap_part1; ap_part2; ap_part3; With a load base relative to app base you break such 'natural' behaviour. Also consider that you could have many webapps, in many differents locations (think ISP/ASP), which didn't have to know the location of the appBase. If you want we could make it Context optional but the choice should be present to allow sites using TC 3.2/3.3 to switch more easily to 5.0... Henri, this issue is only related to loading of ENTITY's from web.xml? Doesn't the XML parser handle resolving those, and can't you use references relative to the directory the web.xml is in? I think I have misunderstood stuff. It is ok to base resolution on the webapp docBase (but not on the server home directory). As Glenn says, it seems more logical to base it on the location of web.xml. Allelouia, we agree ;) The base should be the location of web.xml (la prochaine fois j'envoie un mail en français :---) +1 ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5] build broken
Hi, building from scratch I'm getting: BUILD FAILED file:/disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-5/build.xml:147: Warning: Could not find file /home/jfarcand/jakarta-tomcat/commons-daemon/commons-daemon.jar to copy. I've seens some change recently related to daemon. Where is the exact location of the jar? Thanks, -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
I would be interested to: - implement jsr115 as an optional feature (based on a previous discussion with Costin on this thread (that may bring Costing back :-) ). - turn SecurityManager on by default ( already proposed by Costin sometime ago if I remember). - improve xml parsing performance (may found that the problem is with my favorite parser ;-) ) -- Jeanfrancois Remy Maucherat wrote: Usually, when a Tomcat branch nears its release, a new branch is created. However, I only have a few feature ideas that make some sense, and the problem is that they are minor evolutions (hence, they could perfectly fit inside the 5.0 branch). This includes: - Updating JK2 to use the JMX events (the same ones the mapper uses) to get autoconfiguration, as an option. That seems useful, but it might well be a really stupid thing in the real world. - Java or native load balancer, with session affinity support. This could be the perfect commons project, and is not really related to Tomcat. - Use an in memory Java compiler to be able to automatically precompile webapps upon deployment. I heard such a compiler now exists, and this could be added fairly easily if it works well enough. I'm not a very big fan, but maybe it would make sense for some people. So to summarize, I have nothing to propose (sorry), and will focus on bugfixes and small additions in the 5.0 branch. If people want to see something more radical happen for the next major release, it's probably time to come up with proposals :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [next] What's next ?
Henri Gomez wrote: Henri Gomez a écrit : 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. One of the features I'd like to see in Tomcat 5.x, a features which prevent me to use TC 4.0.x, 4.1.x and 5.x on my production server is the ability to use external entities from within a web.xml. Let me explain : We have many customers which run the same application but with differents settings. All the settings are present in the web.xml via the use of external entities which are included at run-time. +1 The security mechanism in TC 4.x and higher (due to digester) avoid me to use such easy configuration tuning and so we have to stay with Tomcat 3.3.x for now. I'm probably missing something herewhy the digester suffer from that limitation? What kind of security exception are you seeing. If you give all permissions to the Digester, does it change something? -- Jeanfrancois If we could have a 'relaxed mode', I could switch all my productions servers to 5.x immediatly. We allready discuss in the past and option like JNDI and DSML provider are not valid options for us (for admins and historics reasons). So I'll welcome such 'relaxed mode' since I still wonder what the diff between load external xml entities from outside webapp or loading from JDNI + DSML... I'd like to have your opinions here - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Schedule change
Bill Barker wrote: By the way, is there any plan to certify Tomcat 5? As everyone knows, Sun controls the RI now. While it's rumored to be based on Tomcat code, that's not the same thing. Also, as everyone knows, Geronimo is planning to test the Sun/Apache agreement by getting the test-suite under the Sun/Apache agreement to certify them as a JSEE container once they've gotten up and running. I really think that Tomcat should request the test-suite for Servlet 2.4/JSP 2.0. At the very least, it might give Remy something to do while waiting for the specs to go final ;-). BTW, we are running the TCKs (JSP/Servlet/JSTL) on Tomcat nightly build every day. Currently all tcks are passing... We can certainly help getting/setting the tcks if required. The Axis team is currently running the tcks by their own right now. -- Jeanfrancois Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, The signals I'm getting from Sun about the schedule of the specifications is highly confusing. Since I'm tired of having Tomcat depend on these, I propose taking advantage of the backwards compatibility of the spec, and replacing the TC 5 statement phrase with: The 5.x releases implement the Servlet 2.3 and JSP 1.2 specifications, and will add support for the Servlet 2.4 and JSP 2.0 as soon as they are officially available. That would allow making a timely 5.0 release, rather than expecting stuff for an indefinite amount of time ... If I don't get yelled at too much, I'll call for a vote on this. Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java TldConfig.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/09/23 14:37:01 Modified:catalina/src/share/org/apache/catalina/startup ContextConfig.java TldConfig.java Log: Revert my previous patch since it force validation even when the value is set to false (for schema). I didn't upgrade back to X 2.5, but with X 2.1, this didn't force validation. I'm sure it's a bit hard to follow for everyone. Can you do a recap on tomcat-dev of what's wrong with Xerces, and what is being done about it ? Curently, schema validation doesn't work when you turns it on in server.xml. The problem resides in ContextConfig.java when you do webDigester.setSchema(). For a reason I'm trying to find, the schema file is not loaded by Xerces. I suspect a classloader issue but the validation task suffer the same problem. I'm trying to resolve the problem right now with the jaxp team, but if someone wants to create a test case and file a bug againts Xerces, I will be more that happy. Knowing how they work, without a little test case, they will never looks at it ;-) -- Jeanfrancois Thanks, Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.12 stability rating
Remy Maucherat wrote: ballot [ ] Alpha [X ] Beta /ballot -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Session at ApacheCon
Filip Hanik wrote: and clustering :) True. But I will try to speak about things that I know (or seems to know ;-)). For sure I will at least add it to the what's new list. Thanks, -- Jeanfrancois - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, September 15, 2003 10:01 AM Subject: [5.0] Session at ApacheCon http://apachecon.com/html/session-popup.html/e=MjAwMy9VUw?id=897 quoteNew XML Schema support/quote Well, hum, it doesn't work for me ^_^; quoteNew Connector Architecture/quote It was already there in 4.1.x. If you do a diff, you'll see that the differences are the added JMX stats and a few tweaks. quoteNew Security Architecture/quote I suppose that's the added privileged actions, and it allows more restrictive policies than before, right ? quoteServlet 2.4 new features/quote I think nobody cares anymore about the Servlet spec, esp since there's (almost) nothing new. However, the most useful changes to Tomcat are none of the above, but: - refactored deployer (on Windows, you couldn't do anything without restarting Tomcat) - monitoring and statistics - JMX embedding - mention JSP 2.0 briefly - also quite useful are the new wrappers for Windows and Unix Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.11 stability rating
Seems my apache/sun email are blocked when I reply. :-( Remy Maucherat wrote: ballot [X] Alpha [ ] Beta /ballot When turning the security manager on: java.security.AccessControlException: access denied (java.io.FilePermission /home/ja120114/src/jakarta-tomcat-5/build/server/webapps/manager/WEB-INF/classes/org/apache/log4j/Logger.class read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:270) at java.security.AccessController.checkPermission(AccessController.java:401) Always do catalina run -security -- Jeanfrancois pleaAs usual, please vote :)/plea Add comments if needed. 5.0.11 is similar to 5.0.10 (with the exception of the commons-logging integration). Please check it for regressions. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 12:32 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. Ok. I'm willing to vote for a (weak) Beta in exchange for a release-note that Tomcat doesn't implement the current-draft's Authentication requirements. What is your plan, BTW ? Wait a bit more for the deadline to see what the final specification will say ? (IMO, the old auth matching rules were not very good) I was hoping for a pfd4, but it doesn't look like it's coming out anytime soon :-(. It's a pretty big change to conform to pfd3 (which is a completely nonsensical requirement :), so I was playing the wait-and-see game. Of course, I'm more than happy to do the grunt work to bring Tomcat into compliance with pfd3. However, if the spec changes to something sensible, then that means two big (e.g. changing interfaces in o.a.c) API changes. The spec should'nt change now. I don't really understand why you think we aren't complinat right nowI tough your last change was to bring back compatibility with PFD 3. Do you have an example I can use to demonstrate the problem? Thanks, -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Bill Barker wrote: - Original Message - From: Jean-Francois Arcand [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 6:20 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 12:32 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. Ok. I'm willing to vote for a (weak) Beta in exchange for a release-note that Tomcat doesn't implement the current-draft's Authentication requirements. What is your plan, BTW ? Wait a bit more for the deadline to see what the final specification will say ? (IMO, the old auth matching rules were not very good) I was hoping for a pfd4, but it doesn't look like it's coming out anytime soon :-(. It's a pretty big change to conform to pfd3 (which is a completely nonsensical requirement :), so I was playing the wait-and-see game. Of course, I'm more than happy to do the grunt work to bring Tomcat into compliance with pfd3. However, if the spec changes to something sensible, then that means two big (e.g. changing interfaces in o.a.c) API changes. The spec should'nt change now. I don't really understand why you think we aren't complinat right nowI tough your last change was to bring back compatibility with PFD 3. Do you have an example I can use to demonstrate the problem? Thanks, The following doesn't work correctly according to pfd3: security-constraint web-resource-collection url-pattern/*/url-pattern /web-resource-collection auth-constraint role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection url-pattern/product1/*/url-pattern /web-resource-collection auth-constraint role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection url-pattern/product2/*/url-pattern /web-resource-collection auth-constraint role-nameproduct2/role-name /auth-constraint /security-constraint With Tomcat, you need role 'product1' to access /myapp/product1, role 'product2' to access /myapp/product2, and must be authenticated to access anything else. The correct behavior is that any authenticated user can access anything. My understanding of the spec is that is the proper behaviour (just discussed the issue with the spec lead). Having role-name equals to * doesn't means you have access to /product1/* etc. The spec will be clarified (but the required behaviour will stay the same) -- Jeanfrancois -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through
Re: [VOTE] 5.0.9 stability rating
Remy Maucherat wrote: ballot [ ] Alpha [X ] Beta /ballot Except for validation (which I'm still investigating (try to create smaller test case for the Xerces folks) -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.7] New build by Sunday
Remy Maucherat wrote: Jean-Francois Arcand wrote: +1. There is 1 bug in bugtraq currently open about *.jsp url mapping that I need to investigate (I'm not sure yet it's a bug) but I hope to have a fix before Sunday. And what would the bug be ? (I think I know the mapper code far better than you do, so it would be faster ;-) Of course, it might not be a mapper bug) That was an NPE that occured when the digester thrown a IllegalArgumentException. That was a user error but we should not see the NPE :-) Now we may want to avoid calling preRegister when this situation occurs. -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.7] New build by Sunday
+1. There is 1 bug in bugtraq currently open about *.jsp url mapping that I need to investigate (I'm not sure yet it's a bug) but I hope to have a fix before Sunday. -- Jeanfrancois Remy Maucherat wrote: Hi, I plan to make a new build available by Sunday. Comments ? Any issues which would need to be resolved by then ? A number of issues have been filed about commons-daemon and the new Windows .exe wrapper. Is anyone working on resolving them ? (Mladen, JF ?) I could have helped on that, but the requirement for Visual C++ prevents me from doing so. Is there any way around ? Thanks, Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.7 stability rating
Remy Maucherat wrote: ballot [X ] Alpha [ ] Beta /ballot pleaPlease vote :)/plea Add comments if needed. (1) Xerces validation doesn't work (seems the way we load the DTD is incorrect, producing the current error...but wait, we never know with Xerces ;-) ). Since validation was by default supported in 4.x, I'm considering this a regression. (2) When ContextConfig was refactored, TldConfig was created but it is impossible right now to turn on xml validation (the implementation is missing). Knowing how it may sometimes create the proper TLD, I think the functionality needs to be implemented. I'm working on (1) ( (2) will be easy once (1) is fixed) now and hope to have something soon. -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Xerces location and bug
Remy Maucherat wrote: Jean-Francois Arcand wrote: Hi, I've just realized that when you install Tomcat 5 from a fresh workspace, Xerces is not copied under common/endorsed. I don't remember what was the decision regarding Xerces. Have we decide to completely remove it? If yes, then we shoud remove the dependency in build.properties and unpdate the RELEASE-NOTES. What was the decision? It's my fault (sorry), and there was a decision about that (but I don't remember when it happened). I did it in April, for Tomcat 5.0.2 (looking at the CVS logs). I suppose putting it back could be considered. I agree. the xmlXXX element are still available on the host element so we should still support it. I can work on putting it back if everybody agree. Xerces is included with the deployer, where it is used for webapp validation (which works good for me in the deployer), so it shouldn't be removed completely. Strange.I think the web.xml is not mapped to the proper dtd (IMBW) when used from the endorsed dir. Also, when turning xml validation on with Xerces, all app throw the following: SEVERE: Parse Error at line 5 column 10: cvc-elt.1: Cannot find the declaration of element 'web-app'. org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'web-app'. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) ? That's a bit odd. What's that: cvc-elt.1 ? Same things hereI really like debugging cvc-elt.1 ;-) -- Jeanfrancois I'm gonna investigate and try to come with a fix before sunday Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resend: Tomcat 4.1.24 JVM 1.4.2 security hole?
Oups I've missed the discussion . There is a 1.4.2 bug found by Remy (and reported in bugtraq as 4895132. I'm not sure you can access the bug). The workaround is to add the following property when starting Tomcat: -Dsun.io.useCanonCaches=false Can you try it and see if that fixe the problem (I don't have a winXX)? -- Jeanfrancois Jeff Tulley wrote: The user list has been busy lately discussing a possible security hole, but only 1/3 of the people in the thread could see the problem. I finally got to where I could see it using Tomcat 4.1.24 and JVM 1.4.2, but NOT with JVM 1.4.1. The vulnerability is that if you stick a %20 on the end of a .jsp url, you get the source. I forgot to mention the platforms where this has been seen. I have seen this with Sun's JVM 1.4.2 on Windows XP, and now I just verified that it also exists on NetWare's JVM 1.4.2 (built on Sun's source code base, so not surprising) It might exist on other 1.4.2 implementations, but I am not sure. I also just verified this on Tomcat 4.1.18 and 4.1.26 as well. For some reason I see it better with the example jsp's - /examples/jsp/num/numbguess.jsp%20 for instance. But, you can tell the problem is going to be there if, when you add the %20 to the .jsp name, you don't get a 404. This is all going directly to port 8080, so no native connector is involved. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer: Eric Carmichael
+1. If he like Xerces, he can jump on that side too ;-) -- Jeanfrancois Remy Maucherat wrote: I'd like to nominate Eric Carmichael as a committer on the Tomcat project. Eric has been steadily supplying quality patches to the new Jasper which will implement the JSP 2.0 specification, and has helped fix outstanding bug reports. He plans to continue contributing in the future. He has my +1. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.7 stability rating
Remy Maucherat wrote: Jean-Francois Arcand wrote: Remy Maucherat wrote: ballot [X ] Alpha [ ] Beta /ballot pleaPlease vote :)/plea Add comments if needed. (1) Xerces validation doesn't work (seems the way we load the DTD is incorrect, producing the current error...but wait, we never know with Xerces ;-) ). Since validation was by default supported in 4.x, I'm considering this a regression. (2) When ContextConfig was refactored, TldConfig was created but it is impossible right now to turn on xml validation (the implementation is missing). Knowing how it may sometimes create the proper TLD, I think the functionality needs to be implemented. I'm working on (1) ( (2) will be easy once (1) is fixed) now and hope to have something soon. Great, I don't care about either ;-) lol :-) None of this is critical for a beta (off by default, and it is so slow you'd have to be crazy to enable it). Then I'm crazy :-) (to debug Xerces yes I'm crazy) I don't understand what you mean in (2): TLD validation is not implemented ? I mean it is impossible to turn on xml validation ( the getter/setter are not implemented, so the default value is always set to false ). Costin's re-factoring was too agressive :-) -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Xerces location and bug
Hi, I've just realized that when you install Tomcat 5 from a fresh workspace, Xerces is not copied under common/endorsed. I don't remember what was the decision regarding Xerces. Have we decide to completely remove it? If yes, then we shoud remove the dependency in build.properties and unpdate the RELEASE-NOTES. What was the decision? Also, when turning xml validation on with Xerces, all app throw the following: SEVERE: Parse Error at line 5 column 10: cvc-elt.1: Cannot find the declaration of element 'web-app'. org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'web-app'. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) I'm gonna investigate and try to come with a fix before sunday Thanks, -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: securityManager in JasperLoader.java
Hi Jean-Frederic, the current source have: int dot = name.lastIndexOf('.'); if (securityManager != null) { if (dot = 0) { try { // Do not call the security manager since by default, we grant that package. if (!org.apache.jasper.runtime.equalsIgnoreCase(name.substring(0,dot))){ securityManager.checkPackageAccess(name.substring(0,dot)); } } catch (SecurityException se) { which is the correct way, althrough int dot = name.lastIndexOf('.'); should be moved to be inside the if, because dot is not used outside of it. Thanks, -- Jeanfrancois jean-frederic clere wrote: Hi, One of my colleague has problems in JasperLoader.java: The System.getSecurityManager() is null when creating the class but not null later on. Why do we have the following code? (from jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JasperLoader.java): +++ if (System.getSecurityManager() != null) { if (dot = 0) { try { securityManager.checkPackageAccess(name.substring(0,dot)); } catch (SecurityException se) { String error = Security Violation, attempt to use + Restricted Class: + name; System.out.println(error); throw new ClassNotFoundException(error); } } } +++ We test System.getSecurityManager() but use securityManager! Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4.1.26 stability rating
Finaly... Remy Maucherat wrote: [ ] Alpha [ ] Beta [X] Stable -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] Authentication for Overlapping Constraints
Bill Barker wrote: Tomcat doesn't adhere to the (new) requirements in the 2.4 Servlet-Spec for handling the case of Overlapping Constraints: spec-quote version=2.4 pfd3 section=12.8.1 When a url-pattern and http-method pair occurs in multiple security constraints, the applicable constraints (on the pattern and method) are defined by combining the individual constraints. /spec-quote I see two ways to address this, but can't pick a clear favorite (hence asking for comments :). 1) Add a method 'List getSecurityConstraints(HttpRequest req, Context ctx)' to Realm, and have AuthenticatorBase loop through them. 2) Have RealmBase create it's own special SecurityConstraint that is the intersection of all of the overlapping constraints, and leave AuthenticatorBase alone. Case 1 has the advantage of being relatively clean from a coding standpoint. Case 2 would probably require adding a 'void intersect(SecurityContraint sc)' method to the SecurityConstraint class to enable it to construct the correct permissions (and this looks like it would be a non-trivial method to implement). Comments/Opinions/Flames? In Realm, we already have: /** * Return the SecurityConstraint configured to guard the request URI for * this request, or codenull/code if there is no such constraint. * * @param request Request we are processing */ public SecurityConstraint findSecurityConstraint(HttpRequest request, Context context); Can we modify that method to properly handle the spec? -- Jeanfrancois This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.5] New tag tomorrow ?
+1 Remy Maucherat wrote: To be able to reach beta quality around the end of this month, a new milestone will need to be released at the end of this week (and more generally, I think a one milestone per week schedule can't hurt when trying to go to beta - even if we end up missing the deadline ;-) ). As usual, I'll populate the changelog. I'll also try to add some docs content. Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5] Mapper bug?
Hi, I'm currently doing a very basic test: [EMAIL PROTECTED] jfarcand]$ wget http://localhost:8080/ --20:59:22-- http://localhost:8080/ = `index.html' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 400 No Host matches server name localhost 20:59:23 ERROR 400: No Host matches server name localhost. Does I'm missing something here? Same with index.jsp: [EMAIL PROTECTED] jfarcand]$ wget http://localhost:8080/index.jsp --21:00:30-- http://localhost:8080/index.jsp = `index.jsp' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 400 No Host matches server name localhost 21:00:30 ERROR 400: No Host matches server name localhost. I'm using the current head code before jumping into the Mapper/Coyote code (and get tons of -1 :-) .. just kidding ), can someone confirm I'm not wrong? Thanks, -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5MapperListener.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/07/22 21:02:29 Modified:catalina/src/share/org/apache/coyote/tomcat5 MapperListener.java Log: When using the embedded interface (or jmx directly), context are never removed because of this condition (mapper.removeContext is never called). Then if you re-deploy the same app, The Mapper will maps the http call to the first Mapper's context object, which is an invalid (orphan) object. The client always receives a 503 (since the context is invalid and marked as unavailable). Removing the condition doesn't have any side effect (but fix the problem). Really ? Doesn't it cause problems if there are multiple engines ? I was first able to reproduce the problem with 3 engines, but now I can reproduce it with only 1 engine. I will try to come up with a better solution if I can find a case were the condition is required and breaks the mapper. I'm working on it.Or at least come with a better description of the problem :-) -- Jeanfrancois Remy -if ( ! *.equals( domain ) -! domain.equals( objectName.getDomain() ) -! domain.equals( engineName ) ) { -// A different domain - not ours -if( j2eeType!=null ) -log.debug(MBean in different domain + objectName); -return; -} + log.debug( Handle + objectName ); if (notification.getType().equals (MBeanServerNotification.REGISTRATION_NOTIFICATION)) { - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] More dependencies
Remy Maucherat wrote: Remy Maucherat wrote: - daemon: Home of Mladen's procrun, a very promising exe wrapper for Java programs on Windows; this also contains a Unix wrapper for Java programs; the Unix wrapper could be advertised as the recommended solution to run Tomcat on 80 on Unix, and included as source with Tomcat's binary d/l; this component is currently in the sandbox, and would need to be either moved ASAP to commons proper, or be migrated to j-t-c (if thought to be too Tomcat specific to exist in the commons); a RM will be needed [Mladen, Jean-Frederic] In this email, I forgot to speak about other commons (and others) dependencies. Thanks for all the volunteering, BTW, it really helps (damn day job ...) :) commons-collection: No problem. commons-beanutils: No problem. commons-launcher: Problem; I think I did release 0.9 with Patrick Luby a long time ago, and the component has been dead since. Reviving it and putting a websiter up could help, but it's not certain. This piece of code was developed for the Sun web services pack 1.0 originally. Does anyone use it anymore ? Can it be removed (in favor of native wrappers) ? I have to admit it was quite nice, so I'd rather not have to remove it. Yes, jwsdp 1.2 is still using it. I also think we should keep it. commons-digester: No problem. commons-logging: No problem. commons-pool: No problem. JMX: I think we should try to ship with JMX 1.2 + a JSR 160 implementation if possible. I really hope MX4J will be able to provide that. Tyrex: This project seems dead (unfortunately) :-( We could replace it with some other TM, or (I like that one better) not provide an object factory implementation for UserTransaction by default, and let third parties provide it. That model seems to work great for J2EE providers (JOTM, OpenEJB, etc). Struts: We need 1.1 ! (I think the rest of the world does also :-D) Watchdog: (to the Sun folks) Where is Watchdog 5 (or whatever it's called) ? I'm unaware of such packages (but I will double check). -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteRequest.java
Remy Maucherat wrote: Jean-Francois Arcand wrote: OK, let's try to describe the problem. First, here is the stack trace the application is throwing when running: java.lang.NullPointerException at org.apache.coyote.tomcat5.CoyoteRequestFacade.getAttribute(CoyoteRequestFaca de.java:271) at com.sun.web.ui.view.html.CCButton.getAttribute(CCButton.java:306) at com.sun.web.ui.view.html.CCButton.restoreStateData(CCButton.java:284) at com.sun.web.ui.view.html.CCButton.beginDisplay(CCButton.java:204) at com.sun.web.ui.taglib.html.CCButtonTag.getHTMLString(CCButtonTag.java:236) at com.sun.web.ui.taglib.html.CCButtonTag.doEndTag(CCButtonTag.java:178) at org.apache.jsp.Module3_jsp._jspx_meth_cc_button_0(Module3_jsp.java:205) at org.apache.jsp.Module3_jsp._jspx_meth_jato_form_0(Module3_jsp.java:138) at org.apache.jsp.Module3_jsp._jspx_meth_jato_useViewBean_0(Module3_jsp.java:97 ) at org.apache.jsp.Module3_jsp._jspService(Module3_jsp.java:70) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) I don't think this is an application bug. Note that the problem doesn't occurs with 4.0.x or if you run it without the security manager. The first time the application runs (very simple test), no exception is produced. The second time you run, then the old facade object (the one used by the first request) is still available but since the clear method has been invoked, the request instance is set to null (so the NPE is thrown). It is clear that the facade object used when the NPE is thrown is the one used by the first invokation. It seems that facade object has not been recycled properly. I can send you the war file if you want to see the behaviour. It is very easy to reproduce on both 4.1.x and 5.0 (so that has nothing to do with package protection/access and the security changes we made in 5). I don't think the current solution open security issue, but I agree it is not an elegant solution. The other solution we have is to not invoke, in CoyoteRequest.recycle(), CoyoteRequestFacade.clear(), which set to null the CoyoteRequest. That solution works also: Index: CoyoteRequest.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v retrieving revision 1.8 diff -u -r1.8 CoyoteRequest.java --- CoyoteRequest.java 6 Jun 2003 03:03:33 - 1.8 +++ CoyoteRequest.java 6 Jun 2003 16:55:13 - @@ -438,7 +438,6 @@ mappingData.recycle(); if ((Constants.SECURITY) (facade != null)) { -facade.clear(); facade = null; } . This way the facade will be cleared and we will not create a facade for every request. If a webapp hags on to the facade, it can access the underlying request. That seems to me like a security problem. That also seems like a security bug to Bill, and that's why we both vetoed your commit. I understand and I will revert the patch (but I/we need to fix the problem). What about not calling the clear() method? What I find strange is the following: CoyoteRequest_instance invokes CoyoteRequestFacade_instance.clear() which set CoyoteRequest_instance = null. Same for the response. So applying the above patch by not calling the clear method should be better that the current solution (hope to have less that 2 -1 ;-) I will look at the bug. However, since the facade is only cleared at the end of the request processing (in the recycle), I don't see how you can produce a valid test case. Very simple one actually.I was under the same impression until they sent me the test case. It could be a bug with the tag and tag pooling. Disable tag pooling to see if it fixes the problem. No, it doesn't fix the problem on both 4.1.x/5.x -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteRequest.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/06/06 12:04:51 Modified:catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java Log: Revert the patch until I come with a better solution. I'd like to be convinced there's a bug here ;-) Look: When you access the request, getRequest will create a new facade if there's none. It will then be cleared and nulled only on recycle, which only occurs at the end of the request processing (or there's a bug). If your tag has incorrect pooling and keeps a reference, it could work very well without a security manager, but it's an accident (you're accessing a random underlying request). With a security manager, the request object becomes invalid after the request, and you get the NPE on the second request. The second request thing is a usual symptom of a bug with tag pooling. Do you have the source of the tag, BTW ? Yes, your explanation makes sence. I will look at the tag code to see what I can find.But the exception also occurs when tag pooling is set to off. If the tag has a bug/not well designed, I still think the app should not fail with an NPE but with an IllegalSomething exception.The CoyoteRequest object shouldn't be set to null when the client still have some reference to it. Thanks, -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteRequest.java
OK, let's try to describe the problem. First, here is the stack trace the application is throwing when running: java.lang.NullPointerException at org.apache.coyote.tomcat5.CoyoteRequestFacade.getAttribute(CoyoteRequestFaca de.java:271) at com.sun.web.ui.view.html.CCButton.getAttribute(CCButton.java:306) at com.sun.web.ui.view.html.CCButton.restoreStateData(CCButton.java:284) at com.sun.web.ui.view.html.CCButton.beginDisplay(CCButton.java:204) at com.sun.web.ui.taglib.html.CCButtonTag.getHTMLString(CCButtonTag.java:236) at com.sun.web.ui.taglib.html.CCButtonTag.doEndTag(CCButtonTag.java:178) at org.apache.jsp.Module3_jsp._jspx_meth_cc_button_0(Module3_jsp.java:205) at org.apache.jsp.Module3_jsp._jspx_meth_jato_form_0(Module3_jsp.java:138) at org.apache.jsp.Module3_jsp._jspx_meth_jato_useViewBean_0(Module3_jsp.java:97 ) at org.apache.jsp.Module3_jsp._jspService(Module3_jsp.java:70) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) I don't think this is an application bug. Note that the problem doesn't occurs with 4.0.x or if you run it without the security manager. The first time the application runs (very simple test), no exception is produced. The second time you run, then the old facade object (the one used by the first request) is still available but since the clear method has been invoked, the request instance is set to null (so the NPE is thrown). It is clear that the facade object used when the NPE is thrown is the one used by the first invokation. It seems that facade object has not been recycled properly. I can send you the war file if you want to see the behaviour. It is very easy to reproduce on both 4.1.x and 5.0 (so that has nothing to do with package protection/access and the security changes we made in 5). I don't think the current solution open security issue, but I agree it is not an elegant solution. The other solution we have is to not invoke, in CoyoteRequest.recycle(), CoyoteRequestFacade.clear(), which set to null the CoyoteRequest. That solution works also: Index: CoyoteRequest.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v retrieving revision 1.8 diff -u -r1.8 CoyoteRequest.java --- CoyoteRequest.java 6 Jun 2003 03:03:33 - 1.8 +++ CoyoteRequest.java 6 Jun 2003 16:55:13 - @@ -438,7 +438,6 @@ mappingData.recycle(); if ((Constants.SECURITY) (facade != null)) { -facade.clear(); facade = null; } . This way the facade will be cleared and we will not create a facade for every request. -- Jeanfrancois Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, June 05, 2003 11:49 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java Bill Barker wrote: I'm -1 on this patch unless you can explain what the bug exactly was, and how the recycling couldn't properly reset the facade. I'm not really happy with the patch either. I'll postpone adding my (since it's the second, binding) -1 until you provide a better explaination. Well, I have no idea what the bug report mentioned looks like, so I can't provide a real evaluation. However, what I'm now pretty sure about is that the patch is possibly unsafe. Note: AFAIK, one -1 is enough. I've had plenty of solo -1s ignored :). I understood the rule as more -1 than +1 with the committer assumed to +1. Then, again, I'm not big on rules, and that's for the PMC to work out anyway ;-). Reading Remy's comments, I'm giving my official -1 (so, even with my interpretation, this must be reverted unless you can convince someone to change their Vote). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Commons dependencies
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: - modeler: Basis for Tomcat 5 JMX features, with a lot of new impressively efficient functionality since release 1.0; again, a critical component [Costin (do you have enough time to continue being the RM of that component ?)] I have very little free time - if anyone could do the release it would be great. There are no changes from M1 - I'll check bugzilla to see what remains to be done. Ok, I undertsand; too bad :-( Any volunteers ? (again, this is a critical item) Yes, I can but I have very little experience . If you show me how or point me to some documentation, I can do it. -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] reference to 2.3 dtd instead of 2.4?
Tim Funk wrote: The dtd in jakarta-servletapi-5\jsr154\examples\WEB-INF\web.xml says: !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; Is this right? Yes it is. The examples doesn't contains any new 2.4 features. Of course it will be better if we improve the examples to demonstrate the new 2.4 features. -- Jeanfrancois -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreStandardContext.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/05/28 21:13:24 Modified:catalina/src/share/org/apache/catalina/core StandardContext.java Log: Revert back my latest changes since it did not fix the problem completely. Don't worry about that IMO. I'll have to rewrite that code for the deployer refactoring I'll do (today). I hope I'll be done in one day :) Bonne nouvelle :-) The problem right now is we ends up with 2 configuration files. If I have under webapps/ a file named test.xml that contains: Context path=/test docBase=../foo/bar/ debug=0 /Context that always work. But if the path is equals to: Context path=/test2 docBase=../foo/bar/ debug=0 /Context that will not work (even with my tentative patch). We will ends up with 2 configurations file (test.xml and test2.xml) and the admin tool/HostDeployer will always use webapp/test.xml -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xerces in tomcat-4.1.x
Wait :-) I still did not ran all the tests that I have, specially the lovely XML schema one. It seems to work fine when validation is turned off, but I would like to be sure...mayb we can start using it with Tomcat 5 and change Tomcat 4.1.x once we are sure it work. -- Jeanfrancois jean-frederic clere wrote: Hi, Why are we still using Xerces 2.3.0? The actual version is 2.4.0. Should I update to build.properties.sample to use 2.4.0? Cheers Jean-frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why does Tomcat use xerces under java 1.4 instead of the internaljvm classes?
Costin Manolache wrote: Jean-Francois Arcand wrote: Because the xerces version bundled with 1.4 is an older one, doesn't support XML schema properly, and contains bugs (and is not as performant as the 2.x version) Isn't Crimson in JDK1.4 ? I remember we decided to disable XML schema validation. Crimson Xerces are available. Crimson is the default one. Yes validation is turned off by default. At least in tomcat5 I never use xerces - only the bundled parser, and so far I've seen no problems. Crimson is a very good parser, and it still faster that Xerces in some case. The only reason I see for bundling xerces is for when we turn on validation the web.xml used a schema for validation. XML schema validation is just bad - if the spec would _require_ the container to validate ( and I hope it won't ) - then we can provide a separate validator that will include xerces and some script that users can run. From what I know, that will not happen for the 2.4 timeframe. -- Jeanfrancois Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.x] Next release
Costin Manolache wrote: Remy Maucherat wrote: Could I get some details on that filter/facade bug ? Yes, Filter.init() is called with the Context object instead of the facade. While Servlet.init() is called correctly. This may allow access to the internals, and is just weird ( getting different context objects in the same app for a servlet and a filter ). Fixed. I have ported the patch from Tomcat 5 (where no regression has been found). -- Jeanfrancois Costin I'm waiting for some input to fill up the list. Note that for low priority bugs, a patch will be required. The patch would need to: - have a low impact - be of good quality (no performance/scalability impact, clean code) Will the patch be a set of .jars, or a full release ? I think this is going to be a full release when(ever) everything is in. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.x] Next release
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Could I get some details on that filter/facade bug ? Yes, Filter.init() is called with the Context object instead of the facade. While Servlet.init() is called correctly. This may allow access to the internals, and is just weird ( getting different context objects in the same app for a servlet and a filter ). Does JFA patch fix this also ? Yes. -- Jeanfrancois I'm going to add a bug list in CVS so we can easily edit it. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why does Tomcat use xerces under java 1.4 instead of the internaljvm classes?
Because the xerces version bundled with 1.4 is an older one, doesn't support XML schema properly, and contains bugs (and is not as performant as the 2.x version) -- Jeanfrancois David Thielen wrote: thanks - dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Remy Maucherat wrote: Jean-Francois Arcand wrote: Hi Remy, the servlet doesn't compile with JDK 1.3.x : StatusManagerServlet.java:274: cannot resolve symbol [javac] symbol : method maxMemory () [javac] location: class java.lang.Runtime [javac] writer.print(Runtime.getRuntime().maxMemory()); [javac]^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 1 error This method is only available with JDK 1.4 +. Any ideas of alternatives ? I've just look at the jdk souce code and this method is native :-(, so I don't see an easy way to port itMaybe you can use reflection and return |Long.MAX_VALUE| http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Long.html#MAX_VALUE if jdk 1.4? -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Monitor servlet
Hi Remy, the servlet doesn't compile with JDK 1.3.x : StatusManagerServlet.java:274: cannot resolve symbol [javac] symbol : method maxMemory () [javac] location: class java.lang.Runtime [javac] writer.print(Runtime.getRuntime().maxMemory()); [javac]^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 1 error This method is only available with JDK 1.4 +. -- Jeanfrancois Remy Maucherat wrote: Remy Maucherat wrote: Hi, I proposed that to Costin a few days ago, but got not so enthusiastic comments. The idea would be to add a new monitor servlet to the manager webapp. It would generate data similar to http://www.apache.org/server-status. It would mostly (exclusively ?) use JMX to retrieve the components statistics. That's not a high priority task for me, but something I'd like to get done eventually, and I'm looking for some feedback. I understand that there are existing agents for JMX that can be used to provide more powerful remote access to the statistics (HTTP, RMI, etc), but these tools do not have the ability to give a user a quick and comprehensive look at the Tomcat status (although they allow much more complex operations, and it's not my objective to replace them). I've committed a rough version of the monitoring servlet. It will display status information for all Coyote connectors, using JMX exclusively. I don't think there's any statistic missing (the amount of meaningful status information available to a Java program is definitely much lower than for a native Unix program, hence the simpler look when compared to the Apache status). The thing is very rough, and could use contributions (hint, hint) :) As for using it, the monitor servlet is linked from the default Tomcat welcome page. It currently requires the same credentials as the rest of the manager webapp to access. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [4.1.24] Stability rating
ballot [ ] Alpha [ ] Beta [X ] Stable (GA) /ballot -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Xerces Question
From your description, everything seems fine. Does the error occurs only inside Tomcat or if you parse your file using the command line if also choke? -- Jeanfrancois Bill Barker wrote: I've been trying to set up a CLIENT-CERT authentication for MemoryRealm (one of the few that handles it :). The CN for the cert has embedded quot; characters in it. It seems that xerces chokes on attributes that have quot; embedded in them (which I had learned was the only reason to have quot; defined in the first place :). I've tried all of the XML tricks that I know (e.g. !ENTITY quote #x026;#x022;), but nothing works. Any hints on how to embed quot; into an attribute? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
build.xml still broken...
Hi, the nightly scriptm who starts from a clean workspace, fail with the following: downloadfile: [mkdir] Created dir: /home/jfarcand/jakarta-tomcat/tyrex-1.0 [get] Getting: http://telia.dl.sourceforge.net/sourceforge/tyrex/tyrex-1.0.jar init: [mkdir] Created dir: /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-5/build [mkdir] Created dir: /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-5/build/classes [mkdir] Created dir: /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-5/build/server/lib [mkdir] Created dir: /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-5/build/common/lib build-depends: build-servletapi: [echo] == Building: /home/jfarcand/jakarta-tomcat/servlet-api-2.4/lib/servlet-api.jar prepare: static: compile: examples: javadoc: jar: [copy] Copying 1 file to /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-servletapi-5/jsr154/build [jar] Building jar: /home/jfarcand/jakarta-tomcat/servlet-api-2.4/lib/servlet-api.jar BUILD FAILED file:/disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-servletapi-5/jsr154/build.xml:140: Problem creating jar: /home/jfarcand/jakarta-tomcat/servlet-api-2.4/lib/servlet-api.jar (No such file or directory) (and the archive is probably corrupt but I could not delete it) Anybody seeing this exception? -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resourcesLocalStrings_fr.properties
Hi Henry, a couple of comment about your translation :-) [EMAIL PROTECTED] wrote: hgomez 2002/10/31 01:34:44 Added: catalina/src/share/org/apache/naming LocalStrings_fr.properties catalina/src/share/org/apache/naming/resources LocalStrings_fr.properties Log: First pass of french translations Revision ChangesPath 1.1 jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/LocalStrings_fr.properties Index: LocalStrings_fr.properties === contextBindings.unknownContext=Nom de Contexte inconnu : {0} contextBindings.noContextBoundToThread=Aucun Contexte de nommage lié à ce thread contextBindings.noContextBoundToCL=Aucun Contexte de nommage lié à ce chargeur de classes selectorContext.noJavaUrl=Ce Contexte doit être accédé par une java: URL namingContext.contextExpected=Le Nom n''est pas lié à un Contexte namingContext.nameNotBound=Le Nom {0} n''est pas lié à ce Contexte namingContext.readOnly=Le Contexte est en lecture seule namingContext.invalidName=Le Nom est invalide namingContext.alreadyBound=Le Nom {0} est déjà lié à ce Contexte namingContext.noAbsoluteName=Impossible de générer un nom absolu pour cet espace de nommage (namespace) 1.1 jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/LocalStrings_fr.properties Index: LocalStrings_fr.properties === fileResources.base=Le document base {0} n''existe pas ou n''est pas un répertoire lisible Le document base warResources.notWar=Doc base doit pointé vers un fichier WAR warResources.invalidWar=Fichier WAR invalide ou illisible : {0} jarResources.syntax=Le document base {0} doit commencé par 'jar:' et finir avec '!/' commencer resources.alreadyStarted=Les Ressources ont déjà été démarrées resources.connect=Impossible de se connecter au document base {0} resources.input=Impossible de créer l'input stream pour la ressource {0} Instead, I suggest: Impossible de créer le l'input stream pour la ressource resources.notStarted=Les ressources n''ont pas encore été démarrées resources.null=Le document base ne peut être nul resources.notFound=La ressource {0} est introuvable resources.path=Le chemin relatif de context {0} doit commencé par '/' Le chemin relatif du contexte resources.alreadyBound=Le nom {0} est déjà référencé par ce contexte Le nom {0} a deja ete reference par ce contexte resources.bindFailed=Le liage a échoué: {0} resources.unbindFailed=Le déliage a échoué: {0} standardResources.alreadyStarted=Les ressources ont déja été démarrées standardResources.directory=Le file base {0} n''est pas un répertoire standardResources.exists=Le file base {0} n''existe pas Le file base (entre guillemets) standardResources.notStarted=Les ressources n''ont pas encore été démarrées standardResources.null=Le document base ne peut être nul standardResources.slash=Le document base {0} ne doit pas se terminer par un '/' De toute petite corrections ;-) ... ah ces Quebbecois! -- Jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/utilLocalStrings_fr.properties
Hi Henry, more translation recommendations ;-) [EMAIL PROTECTED] wrote: hgomez 2002/10/31 01:34:29 Added: catalina/src/share/org/apache/catalina/users LocalStrings_fr.properties catalina/src/share/org/apache/catalina/valves LocalStrings_fr.properties catalina/src/share/org/apache/catalina/logger LocalStrings_fr.properties catalina/src/share/org/apache/catalina/util LocalStrings_fr.properties Log: First pass of french translations Revision ChangesPath 1.1 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/users/LocalStrings_fr.properties Index: LocalStrings_fr.properties === memoryUserDatabase.invalidGroup=Nom de groupe invalide {0} memoryUserDatabase.renameOld=Impossible de renommer le fichier original en {0} memoryUserDatabase.renameNew=Impossible de renommer le nouveau fichier en {0} memoryUserDatabase.writeException=IOException lors de l''écriture vers {0} 1.1 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/LocalStrings_fr.properties Index: LocalStrings_fr.properties === accessLogValve.alreadyStarted=Le traceur d''accès a déjà été démarré accessLogValve.notStarted=Le traceur d''accès n''a pas encore été démarré certificatesValve.alreadyStarted=La Valve de Certificats a déjà été démarrée La valve de certificat (un petit v) certificatesValve.notStarted=La Valve de Certificats n''a pas encore été démarrée interceptorValve.alreadyStarted=La Valve d''Interception a déjà été démarré demarree interceptorValve.notStarted=La Valve d''Interception n''a pas encore été démarrée requestFilterValve.next=Aucune Valve 'suivante' n''a été configurée requestFilterValve.syntax=Erreur de synthaxe dans le pattern de filtre de requête {0} valveBase.noNext=Erreur de configuration error: Aucune Valve 'suivante' n''a été configurée error # Error report valve errorReportValve.errorReport=Rapport d''erreur errorReportValve.statusHeader=Etat HTTP {0} - {1} errorReportValve.exceptionReport=Rapport d''exception errorReportValve.statusReport=Rapport d''état errorReportValve.message=message errorReportValve.description=description errorReportValve.exception=exception errorReportValve.rootCause=cause mère cause principale? # HTTP status reports http.100=Le client peut continuer ({0}). http.101=Le serveur change de protocoles suivant la directive Upgrade de l''entête ({0}). protocole http.201=La requête a réussi et une nouvelle ressource ({0}) a été créee sur le serveur. a reussie http.202=La requête a été accepté pour traitement, mais n''a pas été terminée ({0}). acceptee http.203=L''information meta présentée par le client n''a pas pour origine ce server ({0}). http.204=La requête a réussi mais il n''y a aucune information à retourner ({0}). reussie http.205=Le client doit remettre à zéro la vue de document qui a causée l''envoi de cette requête ({0}). http.206=Le serveur a satisfait une requête GET partielle pour cette ressource ({0}). http.207=Plusieurs valeurs d''états ont été retournées ({0}). http.300=La ressource demandée ({0}) correspond à plusieurs représentations, chacune avec sa propre localisation. http.301=La ressource demandée ({0}) a été déplacée de façon permanente vers une nouvelle localisation. http.302=La ressource demandée ({0}) a été déplacée de façon temporaire vers une nouvelle localisation. http.303=La réponse à cette requête peut être trouvée à une URI différente ({0}). http.304=La ressource demandée ({0}) est disponible et n''a pas été modifiée. http.305=La ressource demandée ({0}) doit être accédée au travers du relais indiqué par la directive Location de l''entête. http.400=La requête envoyée par le client était syntaxiquement incorrecte ({0}). http.401=La requête nécessite une authentification HTTP ({0}). authentication, c'est francais? http.402=Un paiement est demandé pour accéder à cette ressource ({0}). http.403=L''accès à la ressource demandée ({0}) a été interdit. est interdit http.404=La ressource demandée ({0}) n''est pas disponible. http.405=La méthode HTTP spécifiée n''est pas autorisée pour la ressource demandée ({0}). http.406=La ressource identifiée par cette requête n''est capable de générer des réponses qu''avec des caractéristiques incompatible avec la directive accept présente dans l''entête de requête ({0}). incompatibles http.407=Le client doit d''abord s''authentifier auprès du relais ({0}). http.408=Le client n''a pas produit de requête pendant le temps d''attente du serveur ({0}). http.409=La requête ne peut être finalisée suite à un conflit lié à l''état de la ressource ({0}). http.410=La ressource demandée ({0}) n''est pas
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resourcesLocalStrings_fr.properties
Craig R. McClanahan wrote: On Thu, 31 Oct 2002, Jean-Francois Arcand wrote: De toute petite corrections ;-) ... ah ces Quebbecois! Is this going to be as bad as American versus British English speakers? :-) Mostly...but I'm in minority againts all the French peoples on the list ;-) -- Jeanfrancois -- Jeanfrancois Craig -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: accessClassInPackage.org.apache.catalina.realm permission
Renato wrote: Hi all, ( sorry to post here... in users list nobody answered ) One of my users is asking for the following permission in his context java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.realm) He is using the securityfilter.jar library I'm using Tomcat 4.1.12 with SecurityManager. Is is safe to grant this permission ? it is never safe to grant access to an internal catalina permission. You need to (1) trust your users and then (2) add the following to your tomcat.policy: grant codeBase file:${catalina.home}/webapps/{you user webapp name}/- { }; This will only grant his webapp to accessClassInPackage. But be aware that you *are* possibly opening a security hole. At you own risk ;-) -- Jeanfrancois Thanks Renato - Do you Yahoo!? HotJobs - Search new jobs daily now -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
10/29/02 Notes
are available under http://javaweb.sfbay.sun.com/~ja120114/security-audit/SecurityAudit.html Let me know if something is missing. Thanks, -- jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: 10/29/02 Notes
Oups..wrong list...sorry. -- Jeanfrancois Jean-Francois Arcand wrote: are available under http://javaweb.sfbay.sun.com/~ja120114/security-audit/SecurityAudit.html Let me know if something is missing. Thanks, -- jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [5.0] New build documentation, docs online
Bob Herrmann wrote: On Mon, 2002-10-28 at 05:07, Remy Maucherat wrote: New Tomcat 5.0 docs online (linked from the main Tomcat page): http://jakarta.apache.org/tomcat/tomcat-5.0-doc/index.html New building documentation: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/BUILDING.txt Comments ? Humm... I used JDK1.4.x and I have clean built several times, but I never had to download Xerces. Does JDK1.4 or ant include Xerces or something? I think the Xerces step maybe optional with JDK1.4. Yes ;-) You use by default the 1.4 parser, which is Crimson. If you try to turn on validation, Crimson will not be able to parse properly your xml file that contains link to XML schema. That's why we need Xerces 2.1 (not 2.0.1, 2.0.2 or 2.2 ;-) ) -- Jeanfrancois Cheers, -bob Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 13907] - security manager does not give readpermission on a context by default
Aditya wrote: Glenn, On Thu, Oct 24, 2002 at 10:03:47AM -, [EMAIL PROTECTED] wrote: This must be a problem in your local system configuration. Check the unix file ownerhsip and permissions for test2.new. I've done that and the fact is that it works fine without the security manager so it's not a unix file ownership and permissions problem. Also try running Tomcat with java property -Djava.security.debug=access,failure defined and then check the security manager debug output. yup, done that and the output has nothing more than the failure of read permissions. I just tested the jsp you posted with a fresh build of Tomcat 4.1 from the CVS head (What will be Tomcat 4.1.13) and Jasper 2. The FilePermission read for the context directory is being granted automatically and the JSP works. I just read the 4.1.13 announcement from Remy and it has the following note: IMPORTANT NOTE: Security manager functionality is broken in this milestone. This will be fixed in the next milestone. This milestone will not be proposed for official release, and should be used for testing purposes only. so before I checkout a fresh copy from CVS, need I be worried about this? No, this is not related to your problem. The SecurityManager in 4.1.13 will throws security exception when you use: HttpServletRequest.setContentType() HttpServletRequest.getContentType() HttpServletRequest.getParameters() HttpServletRequest.getMimeHeaders() HttpServletRequest.getCharacterEncoding() HttpServletResponse.getContentType() HttpServletResponse.setContentType() HttpServetResponse.getHeaders() HttpServetResponse..getHeader() And it should *not*. -- Jeanfrancois Thanks, Adi -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Package Protection: which one?
Hi, testing package protection, I have come to the following conclusion: Packages that we can protect against access -- o.a.catalina o.a.jasper o.a.jsp o.a.jk Packages that we can protect against definition -- o.a.catalina o.a.jasper o.a.jsp o.a.jk o.a.coyote Package that could be protected, but need to change: --- o.a.naming o.a.coyote o.a.tomcat.util If we decide to fully protect o.a.coyote, that means that every calls to CoyoteRequestFacade and CoyoteResponseFacade will need to runs under a doPrivilege blocks (every call that use o.a.tomcat.util). Then o.a.tomcat.util could be protected (only if o.a.coyote is). I made a wrong recommendation last week when I said that o.a.coyote can be protected (rule #1 test using the jakarta workspace, not with your local workspace). Testing with basic servlet prove me the contrary (see 4.1.13 release notesguilty!). I've committed in both Tomcat 4 and 5 the proper protection configuration. I would like to have recommendations based on which package should be protected. Based on the list I will audit package that stay unprotected. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Package Protection: which one?
Remy Maucherat wrote: Jean-Francois Arcand wrote: Hi, testing package protection, I have come to the following conclusion: Packages that we can protect against access -- o.a.catalina o.a.jasper o.a.jsp o.a.jk Packages that we can protect against definition -- o.a.catalina o.a.jasper o.a.jsp o.a.jk o.a.coyote Package that could be protected, but need to change: --- o.a.naming Naming is designed to be secure as is, and shouldn't need protection. o.a.coyote The implementations are protected by facades which have no useful methods for an attacker. o.a.tomcat.util I think this is safe too. If we decide to fully protect o.a.coyote, that means that every calls to CoyoteRequestFacade and CoyoteResponseFacade will need to runs under a doPrivilege blocks (every call that use o.a.tomcat.util). Then o.a.tomcat.util could be protected (only if o.a.coyote is). I made a wrong recommendation last week when I said that o.a.coyote can be protected (rule #1 test using the jakarta workspace, not with your local workspace). Testing with basic servlet prove me the contrary (see 4.1.13 release notesguilty!). I've committed in both Tomcat 4 and 5 the proper protection configuration. I would like to have recommendations based on which package should be protected. Based on the list I will audit package that stay unprotected. I don't think being paranoid would be very useful given that there are facades which are supposed to get the job done. Of course, I'm not the one making the audit, so I don't know for sure. Remy Well, maybe I paranoid (OK I paranoid).but I would prefer protecting all packages and implement the appropriate doPrivileged block. This way we avoid situations like: (1) a new committer add a class to an unprotected package and open a security hole. A good example is, in Tomcat 4, o.a.c.util is not protected because there is no sensitive classes (right Glenn?). But let's say in two year we need to add a class and actual committers are gone because their stock options make them rich (OK I paranoid again :-) ) (2) a hacker breaks a facade and accesses some confidential data. Actually, (2) seems the easiest way to do something bad (and from SUN security group, the most frequent security issue). I must admit that since I'm working on the audit (3 weeks), I did not found any facade that contains a potientally security issues...but IMBW, I'm not an hacker. I would like a decision to protect/not protect a package as soon as possible, since I will not audit a package that is protected (I will just add the appropriate doPrivilege block). And not protecting a package make my life easier since I don't have to implement doPrivileged blocks and try to find every situation when a doPrivileged block is requiredShould we vote? -- Jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Security Check in Classloader.
Hi, In StandardClassLoader, starting line 815, the SecurityManager is invoked: // (.5) Permission to access this class when using a SecurityManager if (securityManager != null) { int i = name.lastIndexOf('.'); if (i = 0) { try { securityManager.checkPackageAccess(name.substring(0,i)); } catch (SecurityException se) { String error = Security Violation, attempt to use + Restricted Class: + name; System.out.println(error); se.printStackTrace(); log(error); throw new ClassNotFoundException(error); } } } Why are we calling the SecurityManager.checkPackageAccess in StandardClassLoader? Since we give all permissions to org.apache.catalina, I think this call is useless. This call is required when invoked inside WebappClassLoader. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Security Check in Classloader.
Foget that email. The problem is in front of the computer, not in the class ;-) -- Jeanfrancois Jean-Francois Arcand wrote: Hi, In StandardClassLoader, starting line 815, the SecurityManager is invoked: // (.5) Permission to access this class when using a SecurityManager if (securityManager != null) { int i = name.lastIndexOf('.'); if (i = 0) { try { securityManager.checkPackageAccess(name.substring(0,i)); } catch (SecurityException se) { String error = Security Violation, attempt to use + Restricted Class: + name; System.out.println(error); se.printStackTrace(); log(error); throw new ClassNotFoundException(error); } } } Why are we calling the SecurityManager.checkPackageAccess in StandardClassLoader? Since we give all permissions to org.apache.catalina, I think this call is useless. This call is required when invoked inside WebappClassLoader. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[3.3] Is methodo.a.c.http11.Http11Processor.addFilter used
Hi, is method o.a.c.http11.Http11Processor.addFilter used by Tomcat 3.x? The method is not used in 4.1.X and 5, and I would like to remove it. The method gives direct access to Class.forName, and this is a lightweight security issue. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[Off-topic] FYI Xerces 2.2
HI, just a quick update with Xerces 2.2. Two weeks ago, I tough I've found the problem Tomcat was having with Xerces 2,2 (by replacing struts.jar file with the 1.1 beta version, the bug did not show up again). I did some tests last week and the bug starts to re-appear, but not all the time (sometimes 10 runs works fine). First I was under the impression it was a bug in Digester, but that was a wrong assumption. I have discussed the issue with the Xerces team and sent a small test case to them that reproduce consistently the bug. They have changed the threading model in Xerces 2.2 and, IMO, seems to be the cause (thread race). The bug doesn't occurs all the time, but the struts-config.xml is the perfect candidate to reproduce the problem. More news to come :-) -- Jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [VOTE] New Committer John Turner
+1 He is quite impressive on tomcat-users list -- Jeanfrancois Bob Herrmann wrote: Mladen's word is enough for me. +1 for John Turner Cheers, -bob On Fri, 2002-10-18 at 15:11, Mladen Turk wrote: Hi, I'd like to propose John Turner [Jturner at AAS.com] as a new Tomcat committer. He does a great job in helping people on tomcat-users list, and he is willing to help us writing docs, testing, etc. MT. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
MBean error when adding a new o.a.c.s.Manager.
Hi, I got the following error when I start Tomcat with the o.a.c.session.PersistentManager manager: ServerLifecycleListener: createMBeans: MBeanException java.lang.Exception: ManagedBean is not found with PersistentManager at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:527) at org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycl eListener.java:422) And when I stop the server: ServerLifecycleListener: destroyMBeans: Throwable javax.management.InstanceNotFoundException: MBeanServer cannot find MBean with ObjectName Catalina:type=Valve,sequence=5890388,path=/admin,host=localhost,service=Tomcat-Standalon e at mx4j.server.MBeanServerImpl.findMBeanMetaData(MBeanServerImpl.java:282) at mx4j.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:611) Is those errors expected since the PersistentManager is considered experimental? Seems to me to be a bug. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
MBean error when using o.a.c.session.PersistentManager
Hi, I got the following error when I start Tomcat with the o.a.c.session.PersistentManager manager: ServerLifecycleListener: createMBeans: MBeanException java.lang.Exception: ManagedBean is not found with PersistentManager at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:527) at org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycl eListener.java:422) And when I stop the server: ServerLifecycleListener: destroyMBeans: Throwable javax.management.InstanceNotFoundException: MBeanServer cannot find MBean with ObjectName Catalina:type=Valve,sequence=5890388,path=/admin,host=localhost,service=Tomcat-Standalon e at mx4j.server.MBeanServerImpl.findMBeanMetaData(MBeanServerImpl.java:282) at mx4j.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:611) Is those errors expected since the PersistentManager is considered experimental? Seems to me to be a bug. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: MBean error when using o.a.c.session.PersistentManager
Sorry for the second postmy mail server is having problems Jean-Francois Arcand wrote: Hi, I got the following error when I start Tomcat with the o.a.c.session.PersistentManager manager: ServerLifecycleListener: createMBeans: MBeanException java.lang.Exception: ManagedBean is not found with PersistentManager at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:527) at org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycl eListener.java:422) And when I stop the server: ServerLifecycleListener: destroyMBeans: Throwable javax.management.InstanceNotFoundException: MBeanServer cannot find MBean with ObjectName Catalina:type=Valve,sequence=5890388,path=/admin,host=localhost,service=Tomcat-Standalon e at mx4j.server.MBeanServerImpl.findMBeanMetaData(MBeanServerImpl.java:282) at mx4j.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:611) Is those errors expected since the PersistentManager is considered experimental? Seems to me to be a bug. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [Security Audit] CoyoteRequest.doGetSession
OK, I have committed the change, do testing, and try to hack the code I just wrote. Of course, more testing will be appreciated :-) -- Jeanfrancois Glenn Nielsen wrote: Jean-Francois Arcand wrote: Glenn Nielsen wrote: Costin Manolache wrote: I'm in the middle on this one - but I would vote for Jean-Francois proposal. Glen is right, it is possible to restrict individual managers using the policy. However as geenral programming it is better to keep the doPrivileged block as small as possible - and have each individual manager that needs to change the permission context do that for the specific areas where this is needed, instead of a global aproach. In general I agree, keeping the amount of code within a doPrivileged() block to a minimum is a good practice. That makes it less likely that the code which calls a method which uses doPrivileged can compromise security. That is not the case for getSession() where the only thing passed to the method is a boolean for create and the Manager gets the JSESSIONID cookie from the request. Removing doPrivileged() from where it currently is will force alot of other work to be done. And will then require anyone who implements a custom Manager/Store to wrap their code in doPrivileged() also. I don't see any security risks from the current implemenation, so why change it? If you can show me an exploit that this change would fix I would be all for it. Eum...why waiting for a security issue (joke: we are not Microsoft ;-) ). Spending time trying to demonstrate a security hole will take as much time as reducing the doPrivilege block. I understand your point but still, I consider the doPrivilege block too large. And still, when Tomcat is used as it is (with the default SecurityManager), the doPrivilege block is *not* required. For a lot of Tomcat users, we are forcing a doPrivilege block. Correct me if I'm wrong, but only JDBCStore and FileStore needs to be changed. I volonteer to make the extra work. It isn't the size of the block of code that matters... Its how the code within that block could pose a security risk. From a security standpoint I don't see any possible exploits. There may be a slight performance improvement for those requests where a session is used by moving the doPrivileged out of the critical path. From just a performance perspective I would want to profile Tomcat to determine where efforts could be best spent to improve performance. Then spend time on the biggest bottleneck to performance found rather than on this. It will require that the documentation for how to write a Manager/Store be updated to discuss this issue. It will also require alot of testing to make sure that you find _all_ the places where a doPrivileged is needed. That means trying all the Manager/Store implementations which come with Tomcat and trying different configuration options. Sounds like alot of work to me. I know I don't have the time to make a change like this for the minimal benefit I see. But if you have the time and want to implement this, go ahead, its your itch. :-) Regards, Glenn -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [Security Audit] CoyoteRequest.doGetSession
Glenn Nielsen wrote: The doPrivileged() for getting a session is in the CoyoteRequest public getSession() method which is implemented as required by ServletRequest and HttpServletRequest. I'm unable to find the information in the spec. Can you point me to the section where the discuss the required privilege? My understanding is the doPrivilege block is needed only if you want to serialize/store the session. If you don't, then you don't need it. If you run Tomcat as it is right now (with the security manager), then you don't need the extra call. The getSession() can be called by a web application. The doPrivileged() block would be required to exist either where it currently is or in each individual implementation of Manager/Store. If it wasn't there getting a session would fail if the web app were not granted the necessary permissions. Permissions I would not want to grant to it. Not in the current implementation. Since the default Manager do not need any special permission, the doPrivilege block is not required. IMHO it is best left where it is. If someone were to implement a custom Manager/Store then the permissions allowed at that point would be the intersection of those permissions granted to catalina and those granted to the codeBase for the custom Manager/Store. So you still have your fine grained control of security policies. That is how it should work. Well, every Manager have a large set of permissions granted by default. I personnaly prefer limitting the permission set instead of granting everything (like the current implementation). Also, the doPrivilege block (as implemented right now) do not contains anything that require special permissions. The doPrivilege block is a performance penalty, and the block is way too big ( for security reasons ). See http://java.sun.com/products/jdk/1.2/docs/guide/security/doprivileged.html for more info. Right now, every Manager are granted by default whatever they want. If I want to denied ManagerA file permissions, I have no way to do it right now...right? -1 for changing/removing the doPrivileged() Other voices? Regards, Glenn Thanks, -- Jeanfrancois Jean-Francois Arcand wrote: Hi, In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege block that grant the doGetSession method. This method delegate the logic to the o.a.c.Manager instance. A Manager can (but it's not required) uses a o.a.c.Store object . The Manager and the Store object may need special privileges when handling session persistance (see o.a.c.session.FileStore for an example). I would recommend we remove the doPrivilege block from CoyoteRequest and delegate the doPrivilege call to the Manager (or the Store) instance. That will allow better fine grained security check. Only the required operations should be granted (right now every Manager is granted - so every Store instance!). As an example, o.a.c.session.FileStore does not contains any security checks in its current implementation, and IMO, it should. The contract between the Manager and CoyoteRequest will have to be documented somewhere since Manager written for Tomcat 4 may no longer works. The catalina.policy file can then be used to give special privileges to ManagerX, but not to ManagerY (same for Store instance or whatever objects is used), based on codebase. Any recommendations/objections to the modification? Thanks, -- Jeanfrancois P.S Right now, if you run Tomcat with the default Security manager, the doPrivilege block is useless. For performance reason, we should avoid this call. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Security Audit] CoyoteRequest.doGetSession
Glenn Nielsen wrote: Costin Manolache wrote: I'm in the middle on this one - but I would vote for Jean-Francois proposal. Glen is right, it is possible to restrict individual managers using the policy. However as geenral programming it is better to keep the doPrivileged block as small as possible - and have each individual manager that needs to change the permission context do that for the specific areas where this is needed, instead of a global aproach. In general I agree, keeping the amount of code within a doPrivileged() block to a minimum is a good practice. That makes it less likely that the code which calls a method which uses doPrivileged can compromise security. That is not the case for getSession() where the only thing passed to the method is a boolean for create and the Manager gets the JSESSIONID cookie from the request. Removing doPrivileged() from where it currently is will force alot of other work to be done. And will then require anyone who implements a custom Manager/Store to wrap their code in doPrivileged() also. I don't see any security risks from the current implemenation, so why change it? If you can show me an exploit that this change would fix I would be all for it. Eum...why waiting for a security issue (joke: we are not Microsoft ;-) ). Spending time trying to demonstrate a security hole will take as much time as reducing the doPrivilege block. I understand your point but still, I consider the doPrivilege block too large. And still, when Tomcat is used as it is (with the default SecurityManager), the doPrivilege block is *not* required. For a lot of Tomcat users, we are forcing a doPrivilege block. Correct me if I'm wrong, but only JDBCStore and FileStore needs to be changed. I volonteer to make the extra work. -- Jeanfrancois I also thing that the permissions should be granted on apps, not managers. The manager should check and have control over the operation that it's doing. ( for example give only some applications permissions to serialize the session in a file - that's probably a bad example as using security manager for that is not the best implementation, but I think you get my point ). Persisting session data is the responsibility of the container not the web application. Session management/persistence should be completely transparent to the webapp including security policy permissions required for managing/persisting those sessions. Costin Jean-Francois Arcand wrote: Glenn Nielsen wrote: The doPrivileged() for getting a session is in the CoyoteRequest public getSession() method which is implemented as required by ServletRequest and HttpServletRequest. I'm unable to find the information in the spec. Can you point me to the section where the discuss the required privilege? My understanding is the doPrivilege block is needed only if you want to serialize/store the session. If you don't, then you don't need it. If you run Tomcat as it is right now (with the security manager), then you don't need the extra call. The getSession() can be called by a web application. The doPrivileged() block would be required to exist either where it currently is or in each individual implementation of Manager/Store. If it wasn't there getting a session would fail if the web app were not granted the necessary permissions. Permissions I would not want to grant to it. Not in the current implementation. Since the default Manager do not need any special permission, the doPrivilege block is not required. IMHO it is best left where it is. If someone were to implement a custom Manager/Store then the permissions allowed at that point would be the intersection of those permissions granted to catalina and those granted to the codeBase for the custom Manager/Store. So you still have your fine grained control of security policies. That is how it should work. Well, every Manager have a large set of permissions granted by default. I personnaly prefer limitting the permission set instead of granting everything (like the current implementation). Also, the doPrivilege block (as implemented right now) do not contains anything that require special permissions. The doPrivilege block is a performance penalty, and the block is way too big ( for security reasons ). See http://java.sun.com/products/jdk/1.2/docs/guide/security/doprivileged.html for more info. Right now, every Manager are granted by default whatever they want. If I want to denied ManagerA file permissions, I have no way to do it right now...right? -1 for changing/removing the doPrivileged() Other voices? Regards, Glenn Thanks, -- Jeanfrancois Jean-Francois Arcand wrote: Hi, In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege block that grant the doGetSession method. This method delegate the logic to the o.a.c.Manager instance. A Manager can (but it's not required
[Proposal] Having a Tomcat.security file.
Hi, I've re-factored Catalina.java and CatalinaService.java and merge the security code into a single class: o.a.c.security.SecurityConfig. This class will manage all the package access/definition security properties. Actually, the list of package access/definition are harcoded in that class. I would like to propose we move this package list into a Tomcat.security file following the J2SE format (see below). This way if people needs accesses to a package, they will have the opportunity to do it with having to recompile Catalina. Righ now, some Watchdog tests are failling because they need accesses to o.a.t.util, and yesterday, we have started protecting this package. What do you think? I know, that's another config file (I don't like having another file). I don't see where we could place that information. Thanks, -- Jeanfrancois # # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageAccess unless the # corresponding RuntimePermission (accessClassInPackage.+package) has # been granted. package.access=sun. # # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageDefinition unless the # corresponding RuntimePermission (defineClassInPackage.+package) has # been granted. # # by default, no packages are restricted for definition, and none of # the class loaders supplied with the JDK call checkPackageDefinition. # #package.definition= -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Proposal] Having a Tomcat.security file.
Glenn Nielsen wrote: Jean-Francois Arcand wrote: Hi, I've re-factored Catalina.java and CatalinaService.java and merge the security code into a single class: o.a.c.security.SecurityConfig. This class will manage all the package access/definition security properties. Works for me! You might consider moving o.a.c.startup.SecurityClassLoad.java into o.a.c.security also since it is directly related to use of the SecurityManager. That's a good idea. I will do that. Is this change just in Tomcat 5? Yes, but I can port easily the change in Tomcat 4 also. Actually, the list of package access/definition are harcoded in that class. I would like to propose we move this package list into a Tomcat.security file following the J2SE format (see below). This way if people needs accesses to a package, they will have the opportunity to do it with having to recompile Catalina. If someone needs access to a restricted package they can grant the appropriate RuntimePermission in their catalina.policy. What packages need restrictions rarely change. Moving the list of packages into a Global variable would make it easier to change these the rare times we need to. But I am -1 for adding a new config file just for this. If somone has their own packages which they feel need restrictions they can always update their own $JAVA_HOME/jre/lib/security/java.security file. o.a.c.security.SecurityConfig currently contains 2 global variables: PACKAGE_ACCESS and PACKAGE_DEFINITION. :-) OK then I will leave it like that. I would consider adding a section to the Secutity-Manager HOW To to explain how to change those settings. Righ now, some Watchdog tests are failling because they need accesses to o.a.t.util, and yesterday, we have started protecting this package. Either grant the appropriate permissions where needed in catalina.policy Ya, but I have to give access to the entire package. No problem for Watchdog, but I prefer the public folder. This way we don't need to change the catalina.policy file everytime we run Watchdog. or wrap more code with doPrivileged() in catalina methods which need it. There are classes or sub packages in org.apache.tomcat.* which need to be restricted. But are the classes which are causing the failure ones which are sensitive from a security standpoint. util.http.ValuesEnumerator util.http.NamesEnumerator I don't think they are sensitive. We have the same issue with o.a.c.u.ParameterMap If not, perhaps those classes should be moved into a different package which is not restricted. +1 I think we should consider having a package in each catalina project where we expose classes to webapp. The easiest way be to create a publicClasses package under each sub-project. Since there is not a lot of classes like that, it should be easy ( I can do it). Any recommendation for the package name? If this isn't workable then either grant the appropriate permissions where needed in catalina.policy or wrap more code with doPrivileged() in catalina methods which need it. I prefer the public package instead of doPrivilege block. SecurityManager related changes and subsequent testing with the default policy file and a very strict policy file can be a very painstaking process. I am happy to more developers getting involved in this area of Tomcat. :-) Regards, ;-) Thanks, -- Jeanfrancois Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0.3 doesn't deploy WAR files with particular names
The appropriate forum for that type of questions will be first under tomcat-user mailling list :-) I've just rename one of my war wiponline.war file without any problems. So it is not related to Tomcat. Maybe you JDK have a bug? -- Jeanfrancois Markus Zänglein wrote: HI I was faced with a really strange problem today. when I wanted Tomcat to use a WAR file named wiponline.war, the server seemingly did not recognize it as a real web application. Despite of the server.xml setting UnpackWARs=true Tomcat didn't create a new directory in webapps. After only renaming the file to any other name e.g. wipOnline.war, WIPonline.war or wip-online.war the trouble was gone ! The app was loaded and executed without any difficulties. Now I wonder, why Tomcat can't cope with wiponline.war. I haven't heard anything about webapps need to have a special name. It rather seems to be some buggy feature ... tia Markus -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Security Audit] Package protection...
HI, is somebody aware why package org.apache.coyote.* and org.apache.tomcat.* are not protected againts package insertion/access in Catalina.java. What is the reasons? Actually, classes are not available to a Webapp (the Classloader is taking care of it) but when Tomcat is embedded in an app container (or when there is a special Classloader), those classes are available :-( Actually, we only protect the following package: if( System.getSecurityManager() != null ) { String access = Security.getProperty(package.access); if( access != null access.length() 0 ) access += ,; else access = sun.,; Security.setProperty(package.access, access + org.apache.catalina.,org.apache.jasper.); String definition = Security.getProperty(package.definition); if( definition != null definition.length() 0 ) definition += ,; else definition = sun.,; Security.setProperty(package.definition, // FIX ME package javax. was removed to prevent HotSpot // fatal internal errors definition + java.,org.apache.catalina.,org.apache.jasper.); } Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startupCatalina.java CatalinaService.java
Hi Glenn, should it be org.apache.tomcat.util instead of org.apache.util ? Thanks, -- Jeanfrancois [EMAIL PROTECTED] wrote: glenn 2002/10/15 13:33:19 Modified:catalina/src/share/org/apache/catalina/startup Catalina.java CatalinaService.java Log: Add two new package restrictions Revision ChangesPath 1.49 +8 -6 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java Index: Catalina.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v retrieving revision 1.48 retrieving revision 1.49 diff -u -r1.48 -r1.49 --- Catalina.java23 May 2002 17:22:37 - 1.48 +++ Catalina.java15 Oct 2002 20:33:19 - 1.49 @@ -484,7 +484,8 @@ else access = sun.,; Security.setProperty(package.access, -access + org.apache.catalina.,org.apache.jasper.); +access + + org.apache.catalina.,org.apache.jasper.,org.apache.coyote.,org.apache.util.); String definition = Security.getProperty(package.definition); if( definition != null definition.length() 0 ) definition += ,; @@ -493,7 +494,8 @@ Security.setProperty(package.definition, // FIX ME package javax. was removed to prevent HotSpot // fatal internal errors -definition + java.,org.apache.catalina.,org.apache.jasper.); +definition + + java.,org.apache.catalina.,org.apache.jasper.,org.apache.coyote.,org.apache.util.); } // Replace System.out and System.err with a custom PrintStream 1.8 +8 -6 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/CatalinaService.java Index: CatalinaService.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/CatalinaService.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- CatalinaService.java 9 Jul 2002 10:46:16 - 1.7 +++ CatalinaService.java 15 Oct 2002 20:33:19 - 1.8 @@ -216,7 +216,8 @@ else access = sun.,; Security.setProperty(package.access, -access + org.apache.catalina.,org.apache.jasper.); +access + + org.apache.catalina.,org.apache.jasper.,org.apache.coyote.,org.apache.util.); String definition = Security.getProperty(package.definition); if( definition != null definition.length() 0 ) definition += ,; @@ -225,7 +226,8 @@ Security.setProperty(package.definition, // FIX ME package javax. was removed to prevent HotSpot // fatal internal errors -definition + java.,org.apache.catalina.,org.apache.jasper.); +definition + + java.,org.apache.catalina.,org.apache.jasper.,org.apache.coyote.,org.apache.util.); } // Start the new server -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Security Audit] CoyoteRequest.doGetSession
Hi, In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege block that grant the doGetSession method. This method delegate the logic to the o.a.c.Manager instance. A Manager can (but it's not required) uses a o.a.c.Store object . The Manager and the Store object may need special privileges when handling session persistance (see o.a.c.session.FileStore for an example). I would recommend we remove the doPrivilege block from CoyoteRequest and delegate the doPrivilege call to the Manager (or the Store) instance. That will allow better fine grained security check. Only the required operations should be granted (right now every Manager is granted - so every Store instance!). As an example, o.a.c.session.FileStore does not contains any security checks in its current implementation, and IMO, it should. The contract between the Manager and CoyoteRequest will have to be documented somewhere since Manager written for Tomcat 4 may no longer works. The catalina.policy file can then be used to give special privileges to ManagerX, but not to ManagerY (same for Store instance or whatever objects is used), based on codebase. Any recommendations/objections to the modification? Thanks, -- Jeanfrancois P.S Right now, if you run Tomcat with the default Security manager, the doPrivilege block is useless. For performance reason, we should avoid this call. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] tomcat-commiters list
Costin Manolache wrote: I would like to propose a new mailing list. The list will be closed to commiters only. The main purpose will be discussions of security and other special issues. This should avoid [Cc] threads. The main target should be active commiters - so it should start empty. This is a majority vote. [X] I agree with the proposal [ ] I don't agree with the proposal -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/netSSLServerSocketFactory.java
Hi Remy, when you start with the SecurityManager, the following exception is thrown. java.lang.ClassNotFoundException: org.apache.catalina.connector.HttpRequestBase$Privilege dGetSession at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.j ava:890) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.j ava:755) at org.apache.catalina.startup.SecurityClassLoad.securityClassLoad(SecurityClassL oad.java:112) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:178) I just commited the patch ;-) -- Jeanfrancois [EMAIL PROTECTED] wrote: remm2002/10/11 01:56:29 Modified:catalina/src/share/org/apache/catalina/loader WebappClassLoader.java Removed: catalina/src/share/org/apache/catalina/connector HttpRequestBase.java HttpResponseBase.java RequestBase.java RequestStream.java ResponseBase.java ResponseStream.java ResponseWriter.java catalina/src/share/org/apache/catalina/net SSLServerSocketFactory.java Log: - As voted, remove deprecated components. Revision ChangesPath 1.8 +18 -13 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java Index: WebappClassLoader.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- WebappClassLoader.java 10 Oct 2002 14:35:21 - 1.7 +++ WebappClassLoader.java 11 Oct 2002 08:56:29 - 1.8 @@ -1432,26 +1432,31 @@ started = false; -int length = jarFiles.length; +int length = files.length; +for (int i = 0; i length; i++) { +files[i] = null; +} + +length = jarFiles.length; for (int i = 0; i length; i++) { try { jarFiles[i].close(); -jarFiles[i] = null; } catch (IOException e) { // Ignore } +jarFiles[i] = null; } notFoundResources.clear(); resourceEntries.clear(); -repositories = new String[0]; -files = new File[0]; -jarFiles = new JarFile[0]; -jarRealFiles = new File[0]; +repositories = null; +files = null; +jarFiles = null; +jarRealFiles = null; jarPath = null; -jarNames = new String[0]; -lastModifiedDates = new long[0]; -paths = new String[0]; +jarNames = null; +lastModifiedDates = null; +paths = null; hasExternalRepositories = false; permissionList.clear(); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] Remove deprecated and unsupported components
ballot [ X ] Remove deprecated org.apache.catalina.connector components from the j-t-catalina module [ ] Leave them in /ballot -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4.1.12: Xerces 2.2 problems - Struts 1.0.2 bug.
Hi, with Tomcat 4.1.12, Xerces 2.2 is throwing the following exception: org.xml.sax.SAXParseException: The string -- is not permitted within comments. at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) This is a bug in the org.apache.struts.digester.Digester class. If you uses Struts 1.1 beta 2 jar file, the bug will not happen. Xerces 2.2 generates a lot of Warnings and the Digester version of Struts 1.0.2 logs an exception instead of a warning. This has been corrected in the current Digester (1.3) we are using. So we have to decide which combinaison we want to support with 4.1.x: Xerces 2.1 + Struts 1.0.2 or Xerces 2.2 + Struts 1.1b2 -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Proposal] Security Audit
Costin Manolache wrote: AFAIK, the most important check is doPriviledged(). What we need to look for is if any of those blocks could be used by untrusted code to do something. The second very important check is the facades - making sure untrusted code can't get access to the real objects. We should also make sure that the facades are not reused or are reused only inside a context. It is nice to review all code for security and bugs ( and general quality ) - but IMO it is more important to review first the critical areas. I will start looking at the doPrivilege block. One thing that I have found is most Tomcat's doPrivilege block contains more operations that they should. Minimizing what we put inside the doPrivilege is very important. As an example (need to be optimized), I made some change to the WebappClassLoader (see the diff.txt). The ClassLoader shouldn't create any major problems ( at least in delegating mode - in non delegating mode we can only trust the servlet experts that they did the resarch and can guarantee there's no security implications. I haven't heard anything convincing on this, but they should have this knowledge - otherwise it wouldn't be in the spec :-) Other areas we can look first are: - Admin Tool. Is the tool secure enougth? - Invoker/Defaut Servlet ;-) - The code Jasper generates. This is one place where facade will get accessed. -- Jeanfrancois Costin Bob Herrmann wrote: FYI, Just to start off, I am going to review these classes. If someone else also reviews them, thats probably a good thing... # classes, package name 17 o.a.c.deploy 9 o.a.c.users 44 o.a.c.* 34 o.a.jk.* 15 j.s.http Briefly, I am going to look for - How/if a ClassLoader is used - privilege blocks (are they small, use trusted values) - look for non-final static variables (can they be abused) - can methods/fields be made private? - are mutable objects returned to caller (especially arrays) think about returning clones - non final equals/hashcode methods? (accessing sensitive stuff?) - Serializable (exposes private stuff?) Does anyone publish a security checklist list like this? Blah Blah, -bob On Tue, 2002-10-08 at 16:36, Jean-Francois Arcand wrote: Hi, I'm looking to do a Security Audit on the current Tomcat 5.0 codebase. I would like to collect as more as information as where you think I should look at (code, security hole, etc.). I'm planning to do the audit using the default SecurityManager. Rigth now, I have started looking at: - doPrivilege blocks. Are they small enough? Can they be reduced? - JSP generated code. Are they secure? Can a malicious app uses the code to access o.a.catalina code? - Is catalina.policy restricted enough? - Is our Classloader secure? Any direction/ideas/recommendations will be appreciated. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Index: WebappClassLoader.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v retrieving revision 1.6 diff -u -r1.6 WebappClassLoader.java --- WebappClassLoader.java 5 Sep 2002 11:38:59 - 1.6 +++ WebappClassLoader.java 9 Oct 2002 19:23:07 - @@ -154,16 +154,16 @@ protected class PrivilegedFindResource implements PrivilegedAction { -private String name; +private int filePointer; private String path; -PrivilegedFindResource(String name, String path) { -this.name = name; +PrivilegedFindResource(int filePointer, String path) { +this.filePointer = filePointer; this.path = path; } public Object run() { -return findResourceInternal(name, path); +return findResourceInternal(filePointer, path); } } @@ -895,13 +895,7 @@ ResourceEntry entry = (ResourceEntry) resourceEntries.get(name); if (entry == null) { -if (securityManager != null) { -PrivilegedAction dp = -new PrivilegedFindResource(name, name); -entry = (ResourceEntry)AccessController.doPrivileged(dp); -} else { -entry = findResourceInternal(name, name); -} +entry = findResourceInternal(name, name); } if (entry != null) { url = entry.source; @@ -1479,13 +1473,7 @@ ResourceEntry entry = null; -if (securityManager != null) { -PrivilegedAction dp = -new PrivilegedFindResource(name, classPath); -entry = (ResourceEntry)AccessController.doPrivileged(dp); -} else { -entry = findResourceInternal(name, classPath); -} +entry = findResourceInternal
[Proposal] Security Audit
Hi, I'm looking to do a Security Audit on the current Tomcat 5.0 codebase. I would like to collect as more as information as where you think I should look at (code, security hole, etc.). I'm planning to do the audit using the default SecurityManager. Rigth now, I have started looking at: - doPrivilege blocks. Are they small enough? Can they be reduced? - JSP generated code. Are they secure? Can a malicious app uses the code to access o.a.catalina code? - Is catalina.policy restricted enough? - Is our Classloader secure? Any direction/ideas/recommendations will be appreciated. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP 2.0's J2SE 1.4 Requirement
Costin Manolache wrote: Remy Maucherat wrote: If the EG prefers features over portability - then we need to find a way to create a distribution without JSP ( is this possible ?) and maybe compensate by including cocoon or velocity. Personally, I would support 1.3 (and 1.2 assuming you are willing to download missing libraries). 1.4 brings I/O improvements so it's a nice JDK choice, even if the nio API itself seems useless for Tomcat. +1... I think 1.3 is available on several platforms. From a previous email send last week, I re-call there were only 2 classes that do not compile on 1.2. We should consider supporting 1.2 as well if it's trueWe can always optimize/abstract the code to use the stength of the target platform (like NIO). I'm fine with using any API in JDK1.4 that we need - but not with _requiring_ JDK1.4. We can easily detect JDK1.4 and enable NIO for that case, or anything else that would help up. I'm obviously -1 on using jdk1.4 regexp or logging API or any 'boundled' feature that can't be used in plain Java2 ( especially when we have better alternatives that work with any java). I have no problem with including Velocity if people want it. As for Cocoon, it is huge, so this looks like a bad idea. Just by curiosity, which JDK version are they supporting? If we can't include JSP2.0 for JDK1.2 and JDK1.3 ( and more important for me - for GCJ and Kaffe and open source VMs ) - then we should include some alternative. We could include JSP1.2, but I doubt we're allowed to do so by licence. The 'default' tomcat release ( in case JSP2 remains with JDK1.4 requirement) will obviously continue to be the same. What I'm interested is what we'll do for the 'tomcat for java2' release. If you're interested in the issue, you should make a proper call for vote. +1 The JSP 2.0 spec is not final, so we have time to ask for a change. -- Jeanfrancois I'm interested in having tomcat and java-based webapps on most platforms. I would prefer to have JSP - and I'm more interested in having this requirement fixed. But if it stops beeing an option, then we need alternatives. If I would care more about features and less about portability, then I could write C# and use windows.