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: 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]
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: [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: [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: 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: 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: 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: [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/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: [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: [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: 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]
[PACTH] [jakarta-tomcat-5]
Hi,
the attached patch add support for Web App Deployment Descriptor that
use XML Schema (Servlet 2.4).
Thanks,
-- Jeanfrancois
Index: ContextConfig.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.66
diff -u -r1.66 ContextConfig.java
--- ContextConfig.java 23 Jun 2002 20:35:30 - 1.66
+++ ContextConfig.java 30 Jul 2002 20:45:13 -
@@ -133,6 +133,7 @@
* of that Context, and the associated defined servlets.
*
* @author Craig R. McClanahan
+ * @author Jean-Francois Arcand
* @version $Revision: 1.66 $ $Date: 2002/06/23 20:35:30 $
*/
@@ -224,7 +225,6 @@
* @param event The lifecycle event that has occurred
*/
public void lifecycleEvent(LifecycleEvent event) {
-
// Identify the context we are associated with
try {
context = (Context) event.getLifecycle();
@@ -483,6 +483,14 @@
url = ContextConfig.class.getResource(Constants.TldDtdResourcePath_12);
tldDigester.register(Constants.TldDtdPublicId_12,
url.toString());
+
+url = ContextConfig.class.getResource(Constants.TldSchemaResourcePath_20);
+
+// to support servlet.jar that does not contains the schema
+if (url != null){
+tldDigester.setSchema(url.toString());
+}
+
tldDigester.addRuleSet(new TldRuleSet());
return (tldDigester);
@@ -494,9 +502,9 @@
* web application deployment descriptor (web.xml).
*/
private static Digester createWebDigester() {
-
URL url = null;
Digester webDigester = new Digester();
+webDigester.setNamespaceAware(true);
webDigester.setValidating(true);
url = ContextConfig.class.getResource(Constants.WebDtdResourcePath_22);
webDigester.register(Constants.WebDtdPublicId_22,
@@ -504,11 +512,39 @@
url = ContextConfig.class.getResource(Constants.WebDtdResourcePath_23);
webDigester.register(Constants.WebDtdPublicId_23,
url.toString());
+
+url = ContextConfig.class.getResource(Constants.WebSchemaResourcePath_24);
+
+// to support servlet.jar that does not contains the schema
+if (url != null){
+webDigester.setSchema(url.toString());
+}
+
+// Add local copy of Servlet 2.4 XML Schema instance.
+url = ContextConfig.class.getResource(Constants.J2eeSchemaResourcePath_14);
+webDigester.register(Constants.J2eeSchemaPublicId_14,
+ url.toString());
+
+url = ContextConfig.class.getResource(Constants.W3cSchemaResourcePath_10);
+webDigester.register(Constants.W3cSchemaPublicId_10,
+ url.toString());
+
+url = ContextConfig.class.getResource(Constants.JspSchemaResourcePath_20);
+webDigester.register(Constants.JspSchemaPublicId_20,
+ url.toString());
+
+url = ContextConfig.class.getResource(Constants.W3cSchemaResourcePath_10);
+webDigester.register(Constants.W3cSchemaPublicId_10,
+ url.toString());
+
+url = ContextConfig.class.getResource(Constants.TldSchemaResourcePath_20);
+webDigester.register(Constants.TldSchemaPublicId_20,
+ url.toString());
+
webDigester.addRuleSet(new WebRuleSet());
return (webDigester);
}
-
/**
* Process the default configuration file, if it exists.
Index: Constants.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Constants.java,v
retrieving revision 1.5
diff -u -r1.5 Constants.java
--- Constants.java 22 Jul 2001 20:25:13 - 1.5
+++ Constants.java 30 Jul 2002 20:45:13 -
@@ -69,6 +69,7 @@
* String constants for the startup package.
*
* @author Craig R. McClanahan
+ * @author Jean-Francois Arcand
* @version $Revision: 1.5 $ $Date: 2001/07/22 20:25:13 $
*/
@@ -91,6 +92,11 @@
//conf/tld_12.dtd;
/javax/servlet/jsp/resources/web-jsptaglibrary_1_2.dtd;
+public static final String TldSchemaPublicId_20 =
+web-jsptaglibrary_2_0.xsd;
+public static final String TldSchemaResourcePath_20 =
+/javax/servlet/resources/web-jsptaglibrary_2_0.xsd;
+
public static final String WebDtdPublicId_22 =
-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN;
public static final String WebDtdResourcePath_22 =
@@ -103,4 +109,24 @@
// conf/web_23.dtd;
/javax/servlet/resources/web-app_2_3.dtd;
+public static final String WebSchemaPubliId_24
[PATCH][jakarta-tomcat-catalina]
Hi,
this minor change fixes a bug : when an appllication is undeployed
(removed), ContainerEvent with the value of REMOVE_EVENT are fired.
The bug is also in jakarta-tomcat-4. Should I send another patch?
Thanks,
-- Jeanfrancois
Index: StandardHostDeployer.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 StandardHostDeployer.java
--- StandardHostDeployer.java 18 Jul 2002 16:48:05 - 1.1.1.1
+++ StandardHostDeployer.java 1 Aug 2002 00:58:15 -
@@ -418,7 +418,8 @@
host.log(sm.getString(standardHost.removing, contextPath));
try {
host.removeChild(context);
-} catch (Exception e) {
+host.fireContainerEvent(REMOVE_EVENT, context);
+ } catch (Exception e) {
host.log(sm.getString(standardHost.removeError, contextPath), e);
throw new IOException(e.toString());
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] [jakarta-servletapi-5]
Hi , attached is the remaining XML schema that need to be available locally. src/share/dtd/j2ee_1_4.xsd src/share/dtd/web-app_2_4.xsd src/share/dtd/jsp_2_0.xsd src/share/dtd/jsptaglibrary_2_0.xsd Thanks, -- Jeanfrancois jakarta-servletapi- 5_localschema.zip Description: Zip compressed data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] [jakarta-servletapi-5]
Hi, this include a modified version of xml.xsd (from W3c) were the DOCTYPE element is removed (commented). Xerces 2.0.1 seems to have problem with this entity when schema is used and the parser is running inside a firewall, using a local copy of the xml.xsd. Thanks, -- Jeanfrancois Index: xml.xsd === RCS file: /home/cvspublic/jakarta-servletapi-5/src/share/dtd/xml.xsd,v retrieving revision 1.1 diff -u -r1.1 xml.xsd --- xml.xsd 1 Aug 2002 00:12:24 - 1.1 +++ xml.xsd 1 Aug 2002 17:40:35 - @@ -1,5 +1,7 @@ ?xml version='1.0'? +!-- Xerces 2.0.1 bug when trying to resolve the systemID locally !DOCTYPE xs:schema PUBLIC -//W3C//DTD XMLSCHEMA 200102//EN XMLSchema.dtd +-- xs:schema targetNamespace=http://www.w3.org/XML/1998/namespace; xmlns:xs=http://www.w3.org/2001/XMLSchema; xml:lang=en xs:annotation -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH]'jakarta-tomcat-catalina]
Hi, this patch clean up the code and turn on automatically namespace validation when using schema. Thanks, -- Jeanfrancois Index: ContextConfig.java === RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v retrieving revision 1.4 diff -u -r1.4 ContextConfig.java --- ContextConfig.java 1 Aug 2002 04:53:03 - 1.4 +++ ContextConfig.java 2 Aug 2002 20:01:18 - @@ -496,10 +496,6 @@ tldDigester.register(Constants.J2eeSchemaPublicId_14, url.toString()); -url = ContextConfig.class.getResource(Constants.W3cSchemaResourcePath_10); -tldDigester.register(Constants.W3cSchemaPublicId_10, - url.toString()); - url = ContextConfig.class.getResource(Constants.JspSchemaResourcePath_20); tldDigester.register(Constants.JspSchemaPublicId_20, url.toString()); @@ -511,7 +507,11 @@ url = ContextConfig.class.getResource(Constants.TldSchemaResourcePath_20); tldDigester.register(Constants.TldSchemaPublicId_20, url.toString()); - + +url = ContextConfig.class.getResource(Constants.WebSchemaResourcePath_24); +tldDigester.register(Constants.WebSchemaPublicId_24, + url.toString()); + tldDigester.addRuleSet(new TldRuleSet()); return (tldDigester); @@ -526,6 +526,7 @@ URL url = null; Digester webDigester = new Digester(); +webDigester.setNamespaceAware(true); webDigester.setValidating(true); url = ContextConfig.class.getResource(Constants.WebDtdResourcePath_22); webDigester.register(Constants.WebDtdPublicId_22, @@ -555,10 +556,6 @@ url = ContextConfig.class.getResource(Constants.JspSchemaResourcePath_20); webDigester.register(Constants.JspSchemaPublicId_20, - url.toString()); - -url = ContextConfig.class.getResource(Constants.W3cSchemaResourcePath_10); -webDigester.register(Constants.W3cSchemaPublicId_10, url.toString()); url = ContextConfig.class.getResource(Constants.TldSchemaResourcePath_20); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][tomcat-catalina] RealmBase/Authenticator re-factoring.
HI, I have completed the move of the authorization logic from the o.a.c.authenticator.AuthenticatorBase to the o.a.c.realm.RealmBase. The Realm class has now three new methods: /** * 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); /** * Perform access control based on the specified authorization constraint. * Return codetrue/code if this constraint is satisfied and processing * should continue, or codefalse/code otherwise. * * @param request Request we are processing * @param response Response we are creating * @param constraint Security constraint we are enforcing * @param The Context to which client of this class is attached. * * @exception IOException if an input/output error occurs */ public boolean hasResourcePermission(HttpRequest request, HttpResponse response, SecurityConstraint constraint, Context context) throws IOException; /** * Enforce any user data constraint required by the security constraint * guarding this request URI. Return codetrue/code if this constraint * was not violated and processing should continue, or codefalse/code * if we have created a response already. * * @param request Request we are processing * @param response Response we are creating * @param constraint Security constraint being checked * * @exception IOException if an input/output error occurs */ public boolean hasUserDataPermission(HttpRequest request, HttpResponse response, SecurityConstraint constraint) throws IOException; Now, Realm can overload those methods an implement a different resource authorization mechanism. Actual Realm implementatin still work since they all extend RealmBase. Let me know if you see any issues. Can somebody apply this patch? Thanks, -- Jeanfrancois Index: Realm.java === RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Realm.java,v retrieving revision 1.2 diff -u -r1.2 Realm.java --- Realm.java 7 Aug 2002 20:51:44 - 1.2 +++ Realm.java 8 Aug 2002 20:18:10 - @@ -64,7 +64,6 @@ package org.apache.catalina; - import java.beans.PropertyChangeListener; import java.io.IOException; import java.security.Principal; @@ -171,7 +170,14 @@ */ public Principal authenticate(X509Certificate certs[]); - +/** + * 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); /** * Perform access control based on the specified authorization constraint. * Return codetrue/code if this constraint is satisfied and processing @@ -184,10 +190,10 @@ * * @exception IOException if an input/output error occurs */ -public boolean hasResourceAccess(HttpRequest request, - HttpResponse response, - SecurityConstraint constraint, - Context context) +public boolean hasResourcePermission(HttpRequest request, + HttpResponse response, + SecurityConstraint constraint, + Context context) throws IOException; @@ -201,7 +207,23 @@ */ public boolean hasRole(Principal principal, String role); - +/** + * Enforce any user data constraint required by the security constraint + * guarding this request URI. Return codetrue/code if this constraint + * was not violated and processing should continue, or codefalse/code + * if we have created a response already. + * + * @param request Request we are processing + * @param response Response we are creating + * @param constraint Security constraint being checked + * + * @exception IOException if an input/output error occurs + */ +public boolean hasUserDataPermission(HttpRequest request, + HttpResponse response, + SecurityConstraint constraint) +throws
[PATCH][servletapi-5] Build.xml
Hi,
minor change to include all *.xsd in the same directory
(javax/servlet/resources) since there is a Xerces limitation when
resolving systemId from multiple URIs (only 1 is supported).
Thanks,
-- Jeanfrancois
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-servletapi-5/build.xml,v
retrieving revision 1.4
diff -u -r1.4 build.xml
--- build.xml 8 Aug 2002 20:26:32 - 1.4
+++ build.xml 10 Aug 2002 14:43:28 -
@@ -76,9 +76,7 @@
copy todir=${servletapi.build}/classes/javax/servlet/resources
fileset dir=src/share/dtd includes=*.dtd,*.xsd
exclude name=jsp*.dtd/
- exclude name=jsp*.xsd/
exclude name=web-jsp*.dtd/
- exclude name=web-jsp*.xsd/
/fileset
/copy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][Catalina] Use fully qualified URI for locating local schema
Hi,
this patch change the way local schema are stored - use the full URI
instead a the file name.
Thanks,
-- Jeanfrancois
Index: Constants.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Constants.java,v
retrieving revision 1.3
diff -u -r1.3 Constants.java
--- Constants.java 1 Aug 2002 04:53:03 - 1.3
+++ Constants.java 10 Aug 2002 14:46:08 -
@@ -93,9 +93,9 @@
/javax/servlet/jsp/resources/web-jsptaglibrary_1_2.dtd;
public static final String TldSchemaPublicId_20 =
-web-jsptaglibrary_2_0.xsd;
+http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd;;
public static final String TldSchemaResourcePath_20 =
-/javax/servlet/jsp/resources/web-jsptaglibrary_2_0.xsd;
+/javax/servlet/resources/web-jsptaglibrary_2_0.xsd;
public static final String WebDtdPublicId_22 =
-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN;
@@ -110,23 +110,23 @@
/javax/servlet/resources/web-app_2_3.dtd;
public static final String WebSchemaPublicId_24 =
-web-app_2_4.xsd;
+http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;;
public static final String WebSchemaResourcePath_24 =
/javax/servlet/resources/web-app_2_4.xsd;
public static final String J2eeSchemaPublicId_14 =
-j2ee_1_4.xsd;
+http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd;;
public static final String J2eeSchemaResourcePath_14 =
/javax/servlet/resources/j2ee_1_4.xsd;
public static final String W3cSchemaPublicId_10 =
-xml.xsd;
+http://www.w3.org/2001/xml.xsd;;
public static final String W3cSchemaResourcePath_10 =
/javax/servlet/resources/xml.xsd;
public static final String JspSchemaPublicId_20 =
-jsp_2_0.xsd;
+http://java.sun.com/xml/ns/j2ee/jsp_2_0.xsd;;
public static final String JspSchemaResourcePath_20 =
-/javax/servlet/jsp/resources/jsp_2_0.xsd;
+/javax/servlet/resources/jsp_2_0.xsd;
}
Index: ContextConfig.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.7
diff -u -r1.7 ContextConfig.java
--- ContextConfig.java 8 Aug 2002 18:31:33 - 1.7
+++ ContextConfig.java 10 Aug 2002 14:46:08 -
@@ -493,10 +493,9 @@
// to support servlet.jar that does not contains the schema
if (url != null){
tldDigester.setSchema(url.toString());
+tldDigester = registerLocalSchema(tldDigester);
}
-tldDigester = registerLocalSchema(tldDigester);
-
tldDigester.addRuleSet(new TldRuleSet());
return (tldDigester);
@@ -527,9 +526,8 @@
// to support servlet.jar that does not contains the schema
if (url != null){
webDigester.setSchema(url.toString());
+webDigester = registerLocalSchema(webDigester);
}
-
-webDigester = registerLocalSchema(webDigester);
webDigester.addRuleSet(new WebRuleSet());
return (webDigester);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH][Catalina] Use fully qualified URI for locating localschema
) at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:2978) at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:918) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.handleEndElement(XMLDocumentFragmentScannerImpl.java:1145) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:988) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1446) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:333) at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:529) at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:585) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1148) at org.apache.commons.digester.Digester.parse(Digester.java:1531) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:423) at org.apache.catalina.core.StandardHost.install(StandardHost.java:803) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:452) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:409) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:879) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:368) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1196) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2231) at org.apache.catalina.startup.Catalina.start(Catalina.java:516) at org.apache.catalina.startup.Catalina.execute(Catalina.java:402) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) Jean-francois Arcand wrote: Hi, this patch change the way local schema are stored - use the full URI instead a the file name. Thanks, -- Jeanfrancois Index: Constants.java === RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Constants.java,v retrieving revision 1.3 diff -u -r1.3 Constants.java --- Constants.java1 Aug 2002 04:53:03 -1.3 +++ Constants.java10 Aug 2002 14:46:08 - @@ -93,9 +93,9 @@ /javax/servlet/jsp/resources/web-jsptaglibrary_1_2.dtd; public static final String TldSchemaPublicId_20 = -web-jsptaglibrary_2_0.xsd; +http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd;; public static final String TldSchemaResourcePath_20 = -/javax/servlet/jsp/resources/web-jsptaglibrary_2_0.xsd; +/javax/servlet/resources/web-jsptaglibrary_2_0.xsd; public static final String WebDtdPublicId_22 = -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN; @@ -110,23 +110,23 @@ /javax/servlet/resources/web-app_2_3.dtd; public static final String WebSchemaPublicId_24 = -web-app_2_4.xsd; +http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;; public static final String WebSchemaResourcePath_24 = /javax/servlet/resources/web-app_2_4.xsd; public static final String J2eeSchemaPublicId_14 = -j2ee_1_4.xsd; +http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd;; public static final String J2eeSchemaResourcePath_14 = /javax/servlet/resources/j2ee_1_4.xsd; public static final String W3cSchemaPublicId_10 = -xml.xsd; +http://www.w3.org/2001/xml.xsd;; public static final String W3cSchemaResourcePath_10 = /javax/servlet/resources/xml.xsd; public static final
Re: [5.0] Build notes
Patrick Luby wrote: Costin, [EMAIL PROTECTED] wrote: On Sun, 11 Aug 2002, Patrick Luby wrote: commons-digester/logging, etc. I think that this would make the build more reliable since Tomcat 5 is dependent on very specific versions of Apache dependencies (e.g. Xerces 2.0.1 only). IMHO that's _totally_ unacceptable ( having tomcat5 work only with xerces). I think that the dependency on Xerces 2.0.1 is excessively restrictive as well. IIRC (maybe Jean-François could provide some of the details he found?), Xerces 2.0.1 was the only Xerces parser that we have found so far that does not throw StackOverflow or other fatal exceptions when an XML file using XML schema is parsed. I believe (Jean-François: let me know if my understanding is incorrect) that this problem exists even if schema validation is turned off. The StackOverflowException _only_ occurs with released version of Xerces 2.0.2. It has been fixed since the release (nightly build works fine). Yes the problem exist even if the schema validation is on. And having schema validation turned on by default has a strong -1 from me - if the spec _requires_ schema validation, then implement it at deployment time. The performance hit is just unacceptable. Any performance increases through delayed validation sounds good to me. I agree. What behaviour do we want if a xml instance is not well-formed? ( in the process we should also move DTD validation to the same stage and stop doing it on every startup if the xml file didn't change ) Makes sense. Especially since we use this same technique for JSP page compilation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
Steve Downey wrote:
Thanks for pointing the tomcat5 task out. I'm trying to reimplement
with that, and have run into a couple of snags.
First is that o.a.c.startup.CatalinaService doesn't distinguish
between catalina.home and catalina.base. setHome() actually sets both
of them. Adding a setBase() is trivial, but it affects the semantics
of initialization. Any current client expects both to be set by a call
to setHome(), and just moving the setProperty to setBase() breaks
that. Of course if the setProperty(catalina.base,s) is left in
setHome(), then initialization is order dependent. For now, and I just
added a setBase() and ignored the problem.
The next problem was that the task runs in VM. Ant's xercesImpl chokes
on parsing the schemas. This is the known dependency on Xerces 2.0.1.
Replacing the xercesImpl.jar in Ant fixed that, but that seems an ugly
requirement.
The problem should occurs only with Xerces 2.0.2. Is 2.0.2 bundle with
ANT 1.5? If you try with the current Xerces nightly build, it should
work. This is a big paint because Xerces 2.0.2 seems to be used
everywhereThe only solution will be to set the schema validation
off, or detect the Xerces version and throw an exception before starting
parsing a file.
-- Jeanfrancois
In any case, after doing that, Catalina service starts up, but doesn't
seem to be able to find the servlet apis to compile JSP pages. As an
added irritation, stdout isn't redirected to catalina.out, and it is
quite noisy.
So, my current patch may not be the best possible, but it does have
the advantage of working.
I think it will make more sense to use the launcher as the basis for a
task to run tomcat. Running it in process leads to a lot of state
leaking over. For testing I think it's safer to run it as much as
possible in its own environment.
This is what I was using for the tomcat5 task:
property name=tools.jar
location=${java.home}/../lib/tools.jar /
path id=tomcatcp
pathelement location=${tomcat.build}/server/classes/
pathelement location=${tools.jar} /
fileset dir=${tomcat.build}/server/lib
include name=**/*.jar/
/fileset
fileset dir=${tomcat.build}/common/lib
include name=**/*.jar/
/fileset
fileset dir=${tomcat.build}/common/endorsed
include name=**/*.jar/
/fileset
fileset dir=${tomcat.build}/shared/lib
include name=**/*.jar/
/fileset
/path
taskdef name=tomcat5
classname=org.apache.catalina.startup.CatalinaService
classpathref=tomcatcp /
tomcat5 do=start
home=${tomcat.build}
base=${basedir}/tmp/tomcat
wait=false/
[EMAIL PROTECTED] wrote:
On Wed, 14 Aug 2002, Steve Downey wrote:
This patch starts up a copy of tomcat with the watchdog war files,
runs watchdog against it, and shuts down tomcat afterwards. It uses
the Launcher to run tomcat in the background, and puts the webapps,
work, logs and conf directories in a tmp dir so as not to muck up
the build.
The only part I really don't like is that there isn't a good way to
know that tomcat is up and running, so for now there's a sleep
between launching tomcat and starting the watchdog tests.
For tomcat5 ? Well, it is - if you use the task ( take a look at
build2.xml ). The task will start tomcat inprocess, and will return
after all the startup is done ( and continue with the next task ).
( unless you have wait=true )
Costin
--
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]
[5.0] [PROPOSAL] Validation/NamespaceAware
Hi, based on the mailling list feedback, I would like to propose the following solution for the XML Parser DTD/Schema validation/namespace aware problems: - Add the following attributes in server.xml under the HOST element: xmlValidation=false xmlNamespaceAware=false and set them equal to false by default. This way, peoples will be able to turn it on only if they need it, using the AdminTool or directly in the server.xml file. It will still let the door open for: - have a separate validation program that can be run on a webapp _before_ it is deployed on tomcat (Costin) - keeping validation available when required (Steve) - etc. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][5] build.properties.defaut, BUILDING.txt
This patch update the required version of the Digester.
Thanks,
-- Jeanfrancois
Index: build.properties.default
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.27
diff -u -r1.27 build.properties.default
--- build.properties.default13 Aug 2002 16:52:19 - 1.27
+++ build.properties.default15 Aug 2002 20:39:44 -
@@ -72,7 +72,7 @@
commons-daemon.loc=jakarta-commons-sandbox/daemon
-# - Commons Digester, version 1.3 or later -
+# - Commons Digester, version 20020815 or later -
commons-digester.home=${base.path}/commons-digester-1.3
commons-digester.lib=${commons-digester.home}
commons-digester.jar=${commons-digester.lib}/commons-digester.jar
Index: BUILDING.txt
===
RCS file: /home/cvspublic/jakarta-tomcat-5/BUILDING.txt,v
retrieving revision 1.18
diff -u -r1.18 BUILDING.txt
--- BUILDING.txt14 Aug 2002 15:46:37 - 1.18
+++ BUILDING.txt15 Aug 2002 20:39:45 -
@@ -216,7 +216,7 @@
(8) Download and Install the Commons Digester Binary Distribution
-* Download a binary distribution (version 1.3 or later) from:
+* Download a binary distribution (version 20020815 or later) from:
http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Xerces 2.0.1 also is buggy
Hi,
Xerces 2.0.1 contains a bug that produce the error Remy reports earlier
this week :-(
Xerces 2.0.2 contains a bug that produce a StackTraceOverflow :-(
In order to supports schema and dtd, Xerces nightly build is the only
version that parse properly DTD and schema when validation is on.
That's a very good reason why we need to have by default validation
turned off ;-)
Thanks,
-- Jeanfrancois
Index: build.properties.default
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.29
diff -u -r1.29 build.properties.default
--- build.properties.default16 Aug 2002 17:03:19 - 1.29
+++ build.properties.default16 Aug 2002 23:36:59 -
@@ -103,12 +103,12 @@
regexp.loc=http://jakarta.apache.org/builds/jakarta-regexp/release/v1.2/jakarta-regexp-1.2.tar.gz
-# - Xerces XML Parser, version 2_0_1 -
-xerces.home=${base.path}/xerces-2_0_1
+# - Xerces XML Parser, version 20020815 or latter -
+xerces.home=${base.path}/xml-xerces
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
-xerces.loc=http://xml.apache.org/dist/xerces-j/old_xerces2/Xerces-J-bin.2.0.1.tar.gz
+xerces.loc=xml-xerces
# --
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Jean-Francois Arcand
Thanks everybody! Now you can say you have a Quebecois as a commiter ;-) -- Jeanfrancois Patrick Luby wrote: All, Jean-François Arcand has received several +1's and no -1's. So, Jean-François, congratulations! Can someone create an account for Jean-François Arcand? Thanks, Patrick Patrick Luby wrote: I would like to propose that we add Jean-François Arcand as a Tomcat committer. I believe he has submitted enough patches to show that he will be a positive contributor to Tomcat 5. Thanks, Patrick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] [Catalina]
/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.catalina.util;
import java.util.HashMap;
import org.apache.commons.digester.Digester;
import org.xml.sax.InputSource;
import org.xml.sax.EntityResolver;
import org.xml.sax.SAXException;
/**
* This class implements a local SAX's codeEntityResolver/code. All
* DTDs and schemas used to validate the web.xml file will re-directed
* to a local file stored in the servlet-api.jar and jsp-api.jar.
*
* @author Jean-Francois Arcand
*/
public class SchemaResolver implements EntityResolver {
/**
* Extension to make the difference between DTD and Schema.
*/
protected String schemaExtension = xsd;
/**
* The public identifier of the DTD we are currently parsing under
* (if any).
*/
protected String publicId = null;
/**
* The URLs of dtds and schemas that have been registered, keyed by the public
* identifier that corresponds.
*/
protected HashMap entityValidator = new HashMap();
/**
* The XML schema to use for validating an XML instance.
*/
protected String schemaLocation = null;
/**
* Create a new codeEntityResolver/code that will redirect
* all remote dtds and schema to a locat destination.
* @param schemaLocation the XML Schema used to validate xml instance.
*/
public SchemaResolver(String schemaLocation){
this.schemaLocation = schemaLocation;
}
/**
* Register the specified DTD/Schema URL for the specified public identifier.
* This must be called before the first call to codeparse()/code.
*
* When adding a schema file (*.xsd), only the name of the file
* will get added. If two schemas with the same name are added,
* only the last one will be stored.
*
* @param publicId Public identifier of the DTD to be resolved
* @param entityURL The URL to use for reading this DTD
*/
public void register(String publicId, String entityURL) {
String key = publicId;
if(publicId.indexOf(schemaExtension) != -1){
key = publicId.substring(publicId.lastIndexOf('/')+1);
}
entityValidator.put(key, entityURL);
}
/**
* Resolve the requested external entity.
*
* @param publicId The public identifier of the entity being referenced
* @param systemId The system identifier of the entity being referenced
*
* @exception SAXException if a parsing exception occurs
*
*/
public InputSource resolveEntity(String publicId, String systemId)
throws SAXException {
if (publicId != null)
this.publicId = publicId;
// Has this system identifier been registered?
String entityURL = null;
if (publicId != null) {
entityURL = (String) entityValidator.get(publicId);
}
// Redirect the schema location to a local destination
String key = null;
if (schemaLocation != null entityURL == null systemId != null){
key = systemId.substring(systemId.lastIndexOf('/')+1);
entityURL = (String)entityValidator.get(key);
}
if (entityURL == null){
return (null);
}
try {
return (new InputSource(entityURL));
} catch (Exception e) {
throw new SAXException(e);
}
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] Proposal: webapp startup
[EMAIL PROTECTED] wrote: There are several possible use cases, and I think we should try to provide options to support each one. Regardless of the startup timing, in all cases no request will be served from an webapp until all initialization is done, including load on startup servlets. There are 2 options here: 1. Wait. The request will be delayed until the initialization completes. The user will just see a slow request. 2. 503. A response page with 'application is temporarily unavilable' or 'starting' or 'refreshing' - eventually with a meta reload. There are several options for how to load: 1. load-on-startup, serial ( maybe with ordering). That's the current situation. All webapps declared in server.xml are loaded in the defined order - and if we move to separate .xmls for each webapp in webapps, we can add an 'sequence' option and require it to be loaded sequencialy and before the server port is started. 2. load-on-startup, parallel. That's very usefull if we have many applications and will speed up the startup. The server port will begin accepting connections after all apps with load-on-startup are loaded. 3. load-on-startup, delayed. For some applications it may be usefull to not delay the start of the server - the startup will be done in background and no request for it will be served until the app is ready. 4. load-on-demand. The context will be initialized when the first request for that context is received. That is the only reasonable choice if you have many ( 50+ ? ) small webapps ( say a hosting env ). I don't see this as a big priority, but nice to have. I'll implement the 'load-on-startup, parallel' as soon as I figure how to do the thread binding and find the time. For example, the admin/ app can be very well loaded on demand or delayed - and same for any app that is not 'critical'. Actually, implementing the xml validation on/off mechanism, admin/ is _the_ reason why Tomcat is slow at startup. There is a lot of xml files to parse/validate in that applicationso I'm +1 to load on demand and set validation to false :-) I know it may involve a lot of work, but It might be nice to have an option in server.xml that configure the web-app startup mode? -- Jeanfrancois It is far better to have tomcat restart quickly and have minimal downtime for the frequently used apps ( where load-on-startup is a good choice ), and use delayed for less-frequent or less critical apps. Costin -- 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]
[PATCH][Catalina] Validation turned off by default.
(){
+return xmlNamespaceAware;
+}
+
+
+/**
+ * Set the namespace aware feature of the XML parser used when
+ * parsing xml instances.
+ * @param xmlNamespaceAware true to enable namespace awareness
+ */
+public void setXmlNamespaceAware(boolean xmlNamespaceAware){
Index: ContextConfig.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.9
diff -u -r1.9 ContextConfig.java
--- ContextConfig.java 20 Aug 2002 03:26:36 - 1.9
+++ ContextConfig.java 20 Aug 2002 18:30:50 -
@@ -139,7 +139,7 @@
*
* @author Craig R. McClanahan
* @author Jean-Francois Arcand
- * @version $Revision: 1.9 $ $Date: 2002/08/20 03:26:36 $
+ * @version $Revision: 1.8 $ $Date: 2002/08/10 22:42:34 $
*/
public final class ContextConfig
@@ -186,15 +186,26 @@
* The codeDigester/code we will use to process tag library
* descriptor files.
*/
-private static Digester tldDigester = createTldDigester();
+private static Digester tldDigester = null;
/**
* The codeDigester/code we will use to process web application
* deployment descriptor files.
*/
-private static Digester webDigester = createWebDigester();
+private static Digester webDigester = null;
+
+/**
+ * Attribute value used to turn on/off XML validation
+ */
+ private static boolean xmlValidation = false;
+
+
+/**
+ * Attribute value used to turn on/off XML namespace awarenes.
+ */
+ private static boolean xmlNamespaceAware = false;
// - Properties
@@ -271,7 +282,10 @@
log(sm.getString(contextConfig.applicationMissing));
return;
}
-
+
+if (webDigester == null){
+webDigester = createWebDigester();
+}
// Process the application web.xml file
synchronized (webDigester) {
try {
@@ -281,11 +295,11 @@
InputSource is = new InputSource(url.toExternalForm());
is.setByteStream(stream);
webDigester.setDebug(getDebug());
+
if (context instanceof StandardContext) {
((StandardContext) context).setReplaceWelcomeFiles(true);
}
-
webDigester.clear();
webDigester.push(context);
webDigester.parse(is);
@@ -308,7 +322,6 @@
}
}
}
-
}
@@ -417,8 +430,11 @@
boolean secure = false;
Container container = context.getParent();
if (container instanceof Host) {
+xmlValidation = ((Host)container).getXmlValidation();
+xmlNamespaceAware = ((Host)container).getXmlNamespaceAware();
container = container.getParent();
}
+
if (container instanceof Engine) {
Service service = ((Engine)container).getService();
// The service can be null when Tomcat is run in embedded mode
@@ -485,8 +501,8 @@
URL url = null;
Digester tldDigester = new Digester();
-tldDigester.setNamespaceAware(true);
-tldDigester.setValidating(true);
+tldDigester.setNamespaceAware(xmlNamespaceAware);
+tldDigester.setValidating(xmlValidation);
if (tldDigester.getFactory().getClass().getName().indexOf(xerces)!=-1) {
tldDigester = patchXerces(tldDigester);
@@ -542,8 +558,8 @@
URL url = null;
Digester webDigester = new Digester();
-webDigester.setNamespaceAware(true);
-webDigester.setValidating(true);
+webDigester.setNamespaceAware(xmlNamespaceAware);
+webDigester.setValidating(xmlValidation);
if (webDigester.getFactory().getClass().getName().indexOf(xerces)!=-1) {
webDigester = patchXerces(webDigester);
@@ -592,6 +608,10 @@
log(sm.getString(contextConfig.defaultMissing), e);
return;
}
+
+if (webDigester == null){
+webDigester = createWebDigester();
+}
// Process the default web.xml file
synchronized (webDigester) {
@@ -600,6 +620,7 @@
new InputSource(file:// + file.getAbsolutePath());
stream = new FileInputStream(file);
is.setByteStream(stream);
+
webDigester.setDebug(getDebug());
if (context instanceof StandardContext)
@@ -720,6 +741,8 @@
if( !context.getOverride() ) {
if( container instanceof Host ) {
((Host)container).importDefaultContext(context);
+xmlValidation
Re: [TC 5] XMLSchema validation and Xerces 2.1.0
Hans Schmid wrote: Hi, as far as I understand, there are problems in Tomcat 5 with the XML Schema validation. A hack in Tomcat plus Xerces 2.0.1 are currentzly in the build system. Has anyone tried the new Xerces release 2.1.0 yet ? Yes, I have done some tesing and it works fine. It the first Xerces version that works properly with schema. 2.0.1 has some performance problems, 2.0.2 has a StackOverflow exception. So yes, 2.1.0 works fine :-) Remember that by default, XML validation is turned off in Tomcat 5. You need to setup optional attribute on the host element to turn it on (xmlValidation=true, xmlNamespaceAware=true). If 2.1.0 fixes the XML Schema problems it might be worth including it in Tomcat 4.1 as well XML Schema is not supported in 4.1. It was required by the new Servlet 2.4/JSP 2.0 specs. -- Jeanfrancois Just a thought, Hans Schmid -- 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: [TC 5] XMLSchema validation and Xerces 2.1.0
David Oxley wrote: Also, you probably ought to include the XML parser (Xerces 2.1.0) with the LE edition of TC5 (If it does fix it). Does Sun JDK1.4 come with Xerces or Crimson? I thought I read that it was supplied with a version of Xerces, but the source that comes with it has org.apache.crimson. stuff in it. By default, Crimson is used, but the Xerces files are available. -- Jeanfrancois Dave. -Original Message- From: Hans Schmid [mailto:[EMAIL PROTECTED]] Sent: 04 September 2002 13:37 To: Tomcat-Dev Subject: [TC 5] XMLSchema validation and Xerces 2.1.0 Hi, as far as I understand, there are problems in Tomcat 5 with the XML Schema validation. A hack in Tomcat plus Xerces 2.0.1 are currentzly in the build system. Has anyone tried the new Xerces release 2.1.0 yet ? If 2.1.0 fixes the XML Schema problems it might be worth including it in Tomcat 4.1 as well Just a thought, Hans Schmid -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [TC 5] XMLSchema validation and Xerces 2.1.0
Remy Maucherat wrote: Jean-Francois Arcand wrote: Hans Schmid wrote: Hi, as far as I understand, there are problems in Tomcat 5 with the XML Schema validation. A hack in Tomcat plus Xerces 2.0.1 are currentzly in the build system. Has anyone tried the new Xerces release 2.1.0 yet ? Yes, I have done some tesing and it works fine. It the first Xerces version that works properly with schema. Cool :) I'll include Xerces 2.1.0 in 4.1.11+ (and of course, the first 5.0.0 milestone), unless people would like to stick with Xerces 2.0.x (2.0.2 is included in 4.1.10). BTW, is it actually faster (working fine is nice by itself, of course) ? Yes, it is (but still slower than Crimson). Xerces 2.0.1 was cycling over and over when a publicId=systemId=null,. They have fixed the problem in Xerces 2.1 and that makes a huge difference (at least for Tomcat schema and dtd) -- Jeanfrancois Remy -- 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: Abuse@verizon.net
jean-frederic clere wrote: Hi, Each time I am replying a message of the list I am getting a message from [EMAIL PROTECTED] (Advert or complain?). Has any one received this kind of message? I don't, but I suspect your mail server has been placed on a spam mail list and now monitored by some agency (I might be wrong at all, but I already experienced something similar) -- Jeanfrancois Is someone not receiving my replies? (last was on topic: Making A Donation (mod_jk for Mac OS X)). Cheers Jean-frederic -- 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: [4.1.10] Stability rating
Remy Maucherat wrote: I think milestone 4.1.10 is of good quality and we can consider releasing it as the first stable release in the 4.1.x line. ballot [ ] Alpha [ ] Beta [X ] Stable /ballot From the DTD validation point of view, the performance seems better with Xerces 2.1 (informal testing ;-), but I see a small difference) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] [4.0.5] [4.1.12] Security releases
Remy Maucherat wrote: A security vulnerability which affects all releases of Tomcat 4.x has been discovered. It is proposed that new Tomcat 4.0.x and 4.1.x releases are made, at which time the exploit will be publicized. The security advisory will also include an easy workaround to protect existing Tomcat installations, so upgrading is not a necessity. Tomcat 4.0.5 release Tomcat 4.0.5 is virtually indentical to 4.0.4, with the exception of: - a bugfix to URL parsing - the security fix ballot +1 [X ] Yes, I approve this release -1 [ ] No, because: /ballot Tomcat 4.1.12 Stable release Tomcat 4.1.12 includes all the changes made to Tomcat 4.1.10 since its release. Tomcat 4.1.11, on which the release is based, has recieved positive feedback so far. The list of changes is available in the release notes. It is proposed that it recieves a Stable rating. The existing 4.1.10 release will be retired. ballot +1 [X ] Yes, I approve this release -1 [ ] No, because: /ballot The proposed binaries for 4.0.5 and 4.1.12 are available at: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/ http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/ 4.0.5 was packaged on my new computer (which I have been using for all the 4.1.x releases), and may contain unwanted changes over 4.0.4. Please let me know if there are problems. Remy -- 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: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS
quot;00"; //--> [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS Glenn Nielsen Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS Costin Manolache Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS Glenn Nielsen Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS Jean-Francois Arcand Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS Glenn Nielsen Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS Costin Manolache Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS Glenn Nielsen Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS Costin Manolache Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS Glenn Nielsen Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS Costin Manolache Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS Remy Maucherat Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS Glenn Nielsen Reply via email to
Re: [Off Topic] SecurityManager XML Policy questions/recommendations
Hi Glenn, see below... Glenn Nielsen wrote: Hi Jean-Francois, My comments are intermixed below. Jean-Francois Arcand wrote: Hi Glenn, here is a couple of questions regarding your SecurityManager XML works: (1) All permissions seems to be stored in class SecurityPolicyBase. The Map used to store permission is static, meaning all permissions will be stored in (why all? doing permissions.implies will browse every permissions instead of application-scope permission). This can be very slow. I'm not sure I follow this. Could you expand on this? Or give me an example of a better way to return the permissions for a CodeSource? My mistake. I did not properly analyse the inner class CodeSourcePermission. Your approach is fast enough. There likely is a better way to get the permissions than the code I wrote which uses an Iterator. I followed the XP method of first getting it to work, then determine what is worth optimizing. I haven't profiled this code yet. The getPermissions() method is only a one time performance hit for each individual java class load. ...except when the refreshPolicy is invoked. You can get permissions from the CodeSourcePermission's collection instead of re-creating all the permissions (I doubt the permission file will change entirely). You will pay the price of an ifBut I'm not sure you can do that since Castor is in the picture. Can you check if a permission exists before you create it? (2) Child scope will always have parent scope permissions. It there a reason? Can it be optional? Its the other way around, a parent will inherit the permissions configured for a child. This is done to make configuring your security policy easier. This is because all classes on the stack are required to have the permission (Unless a doPrivileged was invoked) for the permission to be granted. It is easier to define a specific permission just once rather than having to define it for every codebase. How you nest your SecurityPolicy elements determines the inheritance. If you nest them similar to how they get invoked in a stack trace inheritance makes the policy configuration easier. OK. (3) I didn't see any 'doPrivilege', 'Subject.doAsPrivilege' etc. in your code. I think we need to think about a notion of Tomcat Principal/Subject to only allow Tomcat doing those kind of operations (adding/removing permissions). This is usefull not only for your stuff, but for all security related call. The policy code is in package org.apache.catalina.policy, this package has both package.access and package.definition restrictions. Only code that has been granted the Runtime accessClassInPackage.org.apache.catalina.* can use the code. In the normal policy config that is only the catalina core. OK, but when Tomcat is embedded in another container (JBOSS, J2EE), the AccessControlContext will not be associated with a principal/subject. It's not a problem, but might be an improvement. (4) There is a class called sun.security.provider.PolicyFile where the unmarshalling' of policy statement are made. Your XML Policy file do not define any Policy.implies method. meaning if XMLPolicy.implies is invoked, the call will be delegated to PolicyFile.implies, who doesn't know anything about the permission. This method will return false for every policy.xml permission sinde they are created outside the defaut Policy scope. If a Servlet try accessing a file that is not granted in the policy.xml file, right now, the permission will be allowed since the AccesController will call the Policy.implies..IMBW... sun.security.provider.PolicyFile is just an implementation of a Policy. Which is a SUN specific implementation and not part of the java.security API. My XMLPolicy class extends the abstract Policy class which does not have an implies() method. XMLPolicy is put in place at runtime using SecurityManager.setPolicy(), at that point XMLPolicy is in control of determining what permissions have been granted to a CodeSource. For whatever reason,. I was under the impression you where extending that class.Maybe because I'm reading in english and thinking in french ;-) Whether a servlet has permission depends on the Permissions assigned to it by the Catalina WebappClassLoader when the class is instantiated. It then uses the Policy implemenation, in this case XMLPolicy. (5) I did not see any statement about replacing the policy.provider=sun.security.provider.PolicyFile (using the -Djavax.security.jacc.policy.provider= ) ? The property javax.security.jacc.policy.provider is specific to JSR 115. I though of using the policy.provider config in $JAVA_HOME/jre/lib/security/java.security. But that requires installing the all of the required jar files to implement XMLPolicy in $JAVA_HOME/jre/lib/ext. This could be a frequent tomcat support problem. So instead I designed it to replace
Re: [VOTE] [5.0] Milestones
ballot [ X] +1 Yes, start releasing milestones [ ] -1 No, because: /ballot -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/conf catalina.policy
Hi Glenn, your last addition seems, IMO, to open a security isssue with classes located under the o.a.c.util directory. Actually, maybe not for Tomcat 4.1, but for 5.0, I have created a class called SecurityAudit.java that contains some security check. If we port your latest changes, this class will be exposed to malicious uses. Also, Is there a reason why we are giving the defineClassInPackage? I think two solutions are available (1) move sensitive classes to another package (2) create a public package where we want to give access to some internal class. What is your recommendation? Thanks, -- Jeanfrancois [EMAIL PROTECTED] wrote: glenn 2002/09/30 12:59:47 Modified:catalina/src/conf catalina.policy Log: Allow defineClassInPackage for util due to Request Parametermap needs Revision ChangesPath 1.28 +3 -1 jakarta-tomcat-4.0/catalina/src/conf/catalina.policy Index: catalina.policy === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/catalina.policy,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- catalina.policy 8 Sep 2002 18:04:02 - 1.27 +++ catalina.policy 30 Sep 2002 19:59:47 - 1.28 @@ -121,6 +121,8 @@ // Required for sevlets and JSP's permission java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.util; permission java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.util.*; + permission java.lang.RuntimePermission defineClassInPackage.org.apache.catalina.util; + permission java.lang.RuntimePermission defineClassInPackage.org.apache.catalina.util.*; // Required for running servlets generated by JSPC permission java.lang.RuntimePermission accessClassInPackage.org.apache.jasper.runtime; -- 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: Little refactoring in o.a.t.u.net
Tar the code and post it here...so we can look and enjoy :-) -- Jeanfrancois Ignacio J. Ortega wrote: I have in my workspace working a litle refactoring of the o.a.t.u.net package translating the JSSE* classes to his own package ( named of course jsse) and the same for PureTLs* ones ( with a package name of ptls), i have the tc4.1.X tc5 versions working, and i can put the tc33 and others working too, althought I only need this to be able to use RefactorIt.. :)) ( the real reason is that the only way to make RefactorIt to exclude some package is for complete packages not single files ) I know this is very sensitive code used by many other packages parts, i can live with the change in my workspace without problems.,. but maybe this is useful for anyone more.. Comments? Saludos , Ignacio J. Ortega -- 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: Is Compile Failure? was Re: Need some clarifications
Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? Because, I think, Xerces 2.2.0 was relased two weeks ago. I'm actually testing Xerces 2.2.knowing how much problem we have with Xerces 2.0.1 - 2.0.2 and XML Schema, I just want to be sure there is no regression ;-) -- Jeanfrancois From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) -- 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] Removal of the LE distribution
ballot +1 [X] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot But...The only problem I see is the Xerces version included in 1.3 doesn't support XML Schema. So if people turn on validation, the parser will not work for Servlet 2.4/JSP 2.0I recommend we make it clear in the installation note (or in another place). We can also display a warning message. -- Jeanfrancois Remy Maucherat wrote: Hi all, Before starting to release 5.0.x milestones, I would like to propose having only one distribution for Tomcat 5.0.x, and standardize on what the LE distribution contains (so well, it's more the other distribution which gets removed). It has some advantages: - it is slightly smaller (less these days now that the XML parser has to be shipped again with Tomcat) - runs as-is on JDK 1.3 (because of the Xerces inclusion) - 99% Apache or Apache-style licence (the JDBC 2 standard extension is needed for JDK 1.3 DataSource support :-() - less user confusion The main problem is that the user will need additional downloads for some of the more advanced features, and the package will also not run on JDK 1.2 as is (but from what I've seen, JDK 1.2 compatibility may not be a priority for developers). Remy -- 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] Removal of the LE distribution
Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, October 03, 2002 7:50 PM Subject: Re: [5.0] [VOTE] Removal of the LE distribution Costin Manolache wrote: Remy Maucherat wrote: Hi all, Before starting to release 5.0.x milestones, I would like to propose having only one distribution for Tomcat 5.0.x, and standardize on what the LE distribution contains (so well, it's more the other distribution which gets removed). It has some advantages: - it is slightly smaller (less these days now that the XML parser has to be shipped again with Tomcat) - runs as-is on JDK 1.3 (because of the Xerces inclusion) - 99% Apache or Apache-style licence (the JDBC 2 standard extension is needed for JDK 1.3 DataSource support :-() - less user confusion The main problem is that the user will need additional downloads for some of the more advanced features, and the package will also not run on JDK 1.2 as is (but from what I've seen, JDK 1.2 compatibility may not be a priority for developers). ballot +1 [X] Yes, remove the LE distribution -1 [ ] No, keep both distributions /ballot What would it take to be 100% Apache-style licence ? Can we do some introspection tricks or conditional compilation to solve this ? I can remove the JDBC SE JAR, but then the JDBC connection pooling features won't work right out of the box on JDK 1.3 (assuming it is possible to run JDK 1.3 with TC 5). A great blinking warning should be added to the download page and the release notes if we do that. If somehow the Catalina (with JSP 2 support) adapter requires JDK 1.4, then JDBC SE can be removed. Well, it seems that this has already been done without a [VOTE]. After a long time away from 5.0, I attempted to build it, only to discover that it can't be built any more. As a result, I'm now (belatedly) posting my -1 to R1.2 of o.a.c.core.StandardWrapper.java. and R1.1 of o.a.c.u.SecurityUtil. Please change to a version that compiles under 1.2 at least until there is a [VOTE] to change the target version. AFAIK, the target version is still the same as 4.x (e.g. 1.2). I'm confuse. The Tomcat 4.0-4.1 documentatopm requires JDK 1.3 for compilling the source code: This subproject contains the source code Tomcat 4.0, a server that implements the Servlet 2.3 and JSP 1.2 Specifications from Java Software. In order to build a binary distribution version of the container from a source distribution, you must have a Java Development Kit (JDK) for version 1.3 (or later) downloaded and installed (version 1.3.1 recommended), and do the following: Tomcat should run on 1.2, but should it compile? -- Jeanfrancois Remy -- 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: xerces-j2 2.2.0 problem submitted in bugzilla
I just spoke to a Xalan member and he told me they have the same problem (exception) but this time with / instead of --. We should stick with Xerces 2.1.0seems to have more that one bug in Xerces 2.2.0. -- Jeanfrancois Henri Gomez wrote: I reported the error in xerces2 bugzilla about xerces 2.2.0 and tomcat 4.1.12. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13282 Thanks to comments if you have interesting clues. -- 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: 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.
[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: [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
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: [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]
[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: [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 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
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
[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
[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
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
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: 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: 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: 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] 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: [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: 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: [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: [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: [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]
