Re: Jk2 object model
jean-frederic clere wrote: Costin Manolache wrote: I remember some time ago Mladen (?) was suggesting to use C++ for jk2 instead of the pseudo-OO programming. I am -1 for using C++... And wondering why you want to use C++. I don't actually want to use C++ - I'm just a bit unhappy with the reinventing the wheel object model in jk2, and I was wondering if any alternatives have been discussed. I was looking over the code, and while I still remember some of it :-) I can't stop wondering if it's the best choice. It is an improvement over jk, at least from a java - OO perspective, and I don't remember any other valid option at that time ( Mozilla XPCOM, glib, C++ and open office OO model each had issues ). C++ or COM-style query interface are a bit more standard, and it may be nice if jk2 would be able to integrate with a wider set of applications ( and using the same object model helps ). Right now integration is probably the thing I'm most interested in - i.e. communication between different applications and components. Jk2 is of course pretty specialized to web-like applications - however a lot of things can interoperate using this http request/response model ( web services ? ). So I was wondering if jk2 or something similar could be used as a connector into apps like mozilla or evolution ( or any other desktop app ) and allow access to the services and info inside. Costin Did anything got discussed/decided about this or the low-level model ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security SecurityClassLoad.java
remm2004/01/06 00:39:20 Modified:catalina/src/share/org/apache/catalina/security SecurityClassLoad.java Log: - I didn't test it, but I saw a typo. Revision ChangesPath 1.13 +5 -5 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityClassLoad.java Index: SecurityClassLoad.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityClassLoad.java,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- SecurityClassLoad.java6 Jan 2004 04:27:34 - 1.12 +++ SecurityClassLoad.java6 Jan 2004 08:39:20 - 1.13 @@ -247,7 +247,7 @@ String basePackage = org.apache.tomcat.util.; loader.loadClass (basePackage + - buff.C2BConverter); + buf.C2BConverter); } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25919] New: - java.net.SocketException: socket closed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25919. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25919 java.net.SocketException: socket closed Summary: java.net.SocketException: socket closed Product: Tomcat 4 Version: 4.1.29 Platform: HP URL: http://www.tellngo.com OS/Version: Windows NT/2K Status: UNCONFIRMED Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Jan 5, 2004 2:05:47 PM org.apache.tomcat.util.net.PoolTcpEndpoint acceptSocket SEVERE: Endpoint ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=80] ignored exception: java.net.SocketException: socket closed java.net.SocketException: socket closed at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353) at java.net.ServerSocket.implAccept(ServerSocket.java:448) at java.net.ServerSocket.accept(ServerSocket.java:419) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(De faultServerSocketFactory.java:107) at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoi nt.java:371) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java :553) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:666) at java.lang.Thread.run(Thread.java:536) Jan 5, 2004 2:05:47 PM org.apache.tomcat.util.net.PoolTcpEndpoint closeServerSoc ket SEVERE: Caught exception trying to unlock accept on 80 java.net.ConnectException : Connection refused: connect Jan 5, 2004 2:05:47 PM org.apache.tomcat.util.net.PoolTcpEndpoint acceptSocket WARNING: Reinitializing ServerSocket - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
From Costin Manolache Sent: 6. sijeanj 2004 8:11 To: [EMAIL PROTECTED] Subject: Re: Jk2 object model jean-frederic clere wrote: Costin Manolache wrote: I remember some time ago Mladen (?) was suggesting to use C++ for jk2 instead of the pseudo-OO programming. I am -1 for using C++... And wondering why you want to use C++. I don't actually want to use C++ - I'm just a bit unhappy with the reinventing the wheel object model in jk2, and I was wondering if any alternatives have been discussed. Me too... The JK2 IMO is a pretty dead project. Henri tried to boost that forcing the APR as a default, we did some work, but it is agin stalled. IMO for the majority of the people the JK is sufficient enough. Using APR in JK would perhaps make it the same as JK2. As I see it, most of the people are looking at JK2 as an enhancement over the JK, but in the real life there is not much technological difference. We still have a same packet communication between them (that hasn't changed conceptually from jserv). What I would like to see is something different in approach to the problem of integration. So I was wondering if jk2 or something similar could be used as a connector into apps like mozilla or evolution ( or any other desktop app ) and allow access to the services and info inside. Something simmilar I woud say :-). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug 23929: ServletRequest.setCharacterEncoding()
Remy Maucherat wrote: Jess Holle wrote: Remy Maucherat wrote: This is a good question -- but one which only applies to POST. My bug case was explictly with GET. If there is an entity body encoding specified in the request, then I am not sure which should override. If there is not, then I would presume setCharacterEncoding() should win out. If the only issue is when these differ, then I believe that site designers should simply ensure they don't. I think you should read the HTTP RFC. content-type does not apply to the URI or the HTTP header. The fact that setCharacterEncoding would apply to (part of) the URI and/or the header violates the RFC on URIs. Anyway, to put it simply: in the next release, add useBodyEncodingForURI=true on the connector, and you're done. Please don't complain that it won't do what you want before trying it. You can also use the URIEncoding attribute to specify the path encoding. Rémy my 2 cents on this issue, Remy is for sure right stating that a) the HTTP RFC does not cover variable character encoding for query parameters for different requests b) it is (sounds ?) logical to assume that the whole URI (including paths, query parameters etc.) should be considered as being encoded with the same character encoding From a developers point of view however, applying the above two points a) brakes expected behaviour (setCharacterEncoding() method does not work the same as before) b) does not give an acceptable alternative (if all parameter passing could be solved with POST method, then the GET method would not be needed, would it?) c) a lot of web apps stopped working when an upgrade of the tomcat version was performed So I think it is legitimate to be upset when first confronted with this change of behaviour. As for how easy it is to NOT file duplicate bugs on this issue, having followed this debate, I have collected the following list of somehow related bugs bug 25360 bug 25231 bug 25235 bug 22666 bug 24557 bug 24345 bug 23929 bug 25848 and of course a bunch of messages in the developer list Speaking for myself and having reread these messages: Assuming I 've been working for some time with the old behaviour and experienced the new one, I would not be able to understand why this change was made, EVEN if someone gave me the above list of bugs. I propose the following: write a short summary of why this change was necessary and include the above list of bugs, as well as links to the related developer list threads. Then submit a link to this summary to all the above bugs. If not already done, port the useBodyEncodingForURI parameter to the next 4.1.x release. I volunteer to write the summary if the list thinks that the proposal is reasonable. Regards Stefanos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Retrieving the context path from a standalone class
Hi all, I have a class in my web app that runs in a separate thread. It's responsibility is to re-index the site every x minutes (I am using Lucene for site searches). It recursively loops over the relevant files within the web app folder and attempts to index each one (the web app must be exploded at this stage). I have this working for HTML and plain text resources. However, I would like to include JSPs in my index. Of course, I need to request each JSP to get any meaningful information for the index. I have a class that implements the ServletContextListener interface and stores a global reference to the ServletContext object. Originally I thought this would be all I needed to dynamically request JSPs. I figured you could retrieve the servlet context path from the ServletContext object in order to construct a URL to request - how silly of me! It seems you cannot retrieve the context path from anywhere other than the HttpServletRequest interface. Besides being a major design flaw (?), this complicates things for me. I cannot dynamically construct a request URL because I don't know the context path and my application must be able to run under any context path including the default one. I thought about using the ServletContext.getRequestDispatcher() method. However, I needed an implementation of HttpServletRequest and HttpServletResponse in order to use the dispatcher. HttpServletRequest, as I just mentioned, defines the getContextPath() method which I obviously can't implement. The JSPs in my application already rely on this method returning the correct context path. Hence, this was not an option. I also thought of having a servlet that loads on start-up set a global variable containing the context path. However, I would need the servlet to be requested in order to obtain an instance of HttpServletRequest from which I could extract the context path - the parameters to the init() method are of no help. A possible solution is to define an environment entry for the web app that duplicates the details of the context path. This is an awful solution and should not be necessary. Can anyone shed some light on this? Am I missing something embarrassingly obvious here? Thanks, Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25921] New: - Service runs improperly.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25921. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25921 Service runs improperly. Summary: Service runs improperly. Product: Tomcat 5 Version: 5.0.16 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Minor Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am running Tomcat 5.0.16 on winodws NT and have structured it properly with the java SDK but the service will not start automatically at log in. I have to run commmand line to the startup and shutdown .bat to get the service to start and stop - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Retrieving the context path from a standalone class
Howdy, You're missing a few things: 1. The context path is (according to the spirit of the servlet spec) to be decided by the server administrator, just like the port on which the webapp will run. Your application should be completely agnostic of the actual context path. This is not a design flaw in the servlet API, but a flaw in your own application's current design. 2. If you want to keep your current design, simply start the indexing thread when the first request comes in using its context path. You can, for example, have your servlet context listener class also be a servlet request listener, and do something on the first incoming request only. 3. This is a user, i.e. the tomcat-user list, question, so please continue discussion there. This list is for internal tomcat development discussions. Thanks, Yoav Shapira Millennium ChemInformatics -Original Message- From: Kent Boogaart [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 06, 2004 12:34 AM To: '[EMAIL PROTECTED]' Subject: Retrieving the context path from a standalone class Hi all, I have a class in my web app that runs in a separate thread. It's responsibility is to re-index the site every x minutes (I am using Lucene for site searches). It recursively loops over the relevant files within the web app folder and attempts to index each one (the web app must be exploded at this stage). I have this working for HTML and plain text resources. However, I would like to include JSPs in my index. Of course, I need to request each JSP to get any meaningful information for the index. I have a class that implements the ServletContextListener interface and stores a global reference to the ServletContext object. Originally I thought this would be all I needed to dynamically request JSPs. I figured you could retrieve the servlet context path from the ServletContext object in order to construct a URL to request - how silly of me! It seems you cannot retrieve the context path from anywhere other than the HttpServletRequest interface. Besides being a major design flaw (?), this complicates things for me. I cannot dynamically construct a request URL because I don't know the context path and my application must be able to run under any context path including the default one. I thought about using the ServletContext.getRequestDispatcher() method. However, I needed an implementation of HttpServletRequest and HttpServletResponse in order to use the dispatcher. HttpServletRequest, as I just mentioned, defines the getContextPath() method which I obviously can't implement. The JSPs in my application already rely on this method returning the correct context path. Hence, this was not an option. I also thought of having a servlet that loads on start-up set a global variable containing the context path. However, I would need the servlet to be requested in order to obtain an instance of HttpServletRequest from which I could extract the context path - the parameters to the init() method are of no help. A possible solution is to define an environment entry for the web app that duplicates the details of the context path. This is an awful solution and should not be necessary. Can anyone shed some light on this? Am I missing something embarrassingly obvious here? Thanks, Kent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25923] New: - using classes not in any package fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25923. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25923 using classes not in any package fails Summary: using classes not in any package fails Product: Tomcat 5 Version: 5.0.16 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, it is not possible to use a class which is not in a package in a jsp. Example: webapps/demojsp/WEB-INF/classes/Adder.class webapps/demojsp/add.jsp An import in the add.jsp is not allowed because of the spec: %@ page info=Adder Page import=Adder % produces a not compileable java source because of invalid import statement. But without the import statement the Adder.class will not be found. So it is not possible to use the Adder.class which is not in any package?! Is this missing in the spec or a bug in tomcat. I tested it with any tomcat Version 3,4,5 (it is all the same). (Ok, it is not very important because of bad style not using namespaces, but I sumble across it from a real scenario using a foreign class) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25923] - using classes not in any package fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25923. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25923 using classes not in any package fails [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-06 14:19 --- http://jakarta.apache.org/tomcat/faq/classnotfound.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25921] - Service runs improperly.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25921. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25921 Service runs improperly. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-06 14:26 --- You need the service set as automatic, and you need the -Xrs as a JVM parameter (this is set by default by the installer). I recommend posting about this on tomcat-user if you are still having trouble. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
Mark,
For backwards compatibility, I think the restrictions to the TLD
location need to follow the spec level used by the web application.
Since JSP 1.1 didn't include much in the way of restrictions,
I know of some legacy Servlet 2.2/JSP 1.1 webapps that would fail
these restrictions if deployed to Tomcat 5 with this change (or
Tomcat 4.1 with the port of this change). If you want, I can take
a look at fixing this.
Cheers,
Larry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 03, 2004 8:57 AM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/reso
urces messages.properties
markt 2004/01/03 05:56:39
Modified:jasper2/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java
jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
- Fix bug 11069. Check that the location of the TLD file is
spec compliant.
Revision ChangesPath
1.50 +11 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/comp
iler/TagLibraryInfoImpl.java
Index: TagLibraryInfoImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/j
asper/compiler/TagLibraryInfoImpl.java,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- TagLibraryInfoImpl.java 3 Jan 2004 12:17:18 - 1.49
+++ TagLibraryInfoImpl.java 3 Jan 2004 13:56:38 - 1.50
@@ -5,7 +5,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999 The Apache Software Foundation. All rights
+ * Copyright (c) 1999,2004 The Apache Software Foundation.
All rights
* reserved.
*
* Redistribution and use in source and binary forms, with
or without
@@ -200,6 +200,13 @@
}
} catch (FileNotFoundException ex) {
err.jspError(jsp.error.file.not.found, location[0]);
+}
+
+// Check TLD file location conforms to JSP.7.3.1
+if (!location[0].startsWith(/WEB-INF/)
+||
location[0].startsWith(/WEB-INF/classes/)
+||
location[0].startsWith(/WEB-INF/lib/)) {
+
err.jspError(jsp.error.tld.invalid.location, location[0]);
}
parseTLD(ctxt, location[0], in, null);
1.138 +2 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/reso
urces/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/j
asper/resources/messages.properties,v
retrieving revision 1.137
retrieving revision 1.138
diff -u -r1.137 -r1.138
--- messages.properties 11 Dec 2003 18:24:21 - 1.137
+++ messages.properties 3 Jan 2004 13:56:39 - 1.138
@@ -187,6 +187,7 @@
jsp.error.tld.unable_to_read=Unable to read TLD \{1}\
from JAR file \{0}\: {2}
jsp.error.tld.unable_to_get_jar=Unable to get JAR resource
\{0}\ containing TLD: {1}
jsp.error.tld.missing_jar=Missing JAR resource \{0}\
containing TLD
+jsp.error.tld.invalid.location=\{0}\ is not a valid
location for a TLD as per JSP specification JSP.7.3.1
jsp.error.webxml_not_found=Could not locate web.xml
jsp.cmd_line.usage=Usage: jsptoservlet [-dd
path/to/outputDirectory] [-keepgenerated] \
.jsp files
-
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: Bug 23929: ServletRequest.setCharacterEncoding()
From a developers point of view however, applying the above two points a) brakes expected behaviour (setCharacterEncoding() method does not work the same as before) b) does not give an acceptable alternative (if all parameter passing could be solved with POST method, then the GET method would not be needed, would it?) c) a lot of web apps stopped working when an upgrade of the tomcat version was performed So I think it is legitimate to be upset when first confronted with this change of behaviour. I will not claim that I was reasonable when originally confronted with the change. I will say that: 1. Our existing (4.1.x) usage of setCharacterEncoding() works across all recent servlet engines tested [including 2 commercial servlet engines] -- and is thus some indication of a de facto standard. 2. It would seem from examples provided with setCharacterEncoding() by Sun that the intent is to include request parameters and that thus this should be the default operation of this API rather than requiring additional configuration to obtain this behavior. As for how easy it is to NOT file duplicate bugs on this issue, having followed this debate, I have collected the following list of somehow related bugs I did searches again after being scolded by Remy. I must admit that I must have crossed wires when doing searches and filing bugs and somehow managed to miss this search (which it is my habit to do). Speaking for myself and having reread these messages: Assuming I 've been working for some time with the old behaviour and experienced the new one, I would not be able to understand why this change was made, EVEN if someone gave me the above list of bugs. Agreed. Without a short summary attached to the bugs I would still have filed a new bug and argued to high hell... -- Jess Holle
Re: Bug 23929: ServletRequest.setCharacterEncoding()
Stefanos Karasavvidis wrote: If not already done, port the useBodyEncodingForURI parameter to the next 4.1.x release. This new flag has been ported last month. Rémy - 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/security SecurityClassLoad.java
[EMAIL PROTECTED] wrote:
billbarker2004/01/05 20:27:34
Modified:catalina/src/share/org/apache/catalina/security
SecurityClassLoad.java
Log:
Adding classes for Coyote-Jk.
This addresses Bug #25819.
Reported By: Dario Bonino [EMAIL PROTECTED]
Revision ChangesPath
1.12 +13 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityClassLoad.java
Index: SecurityClassLoad.java
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityClassLoad.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- SecurityClassLoad.java 31 Oct 2003 01:30:01 - 1.11
+++ SecurityClassLoad.java 6 Jan 2004 04:27:34 - 1.12
@@ -90,6 +90,7 @@
loadJavaxPackage(loader);
loadCoyotePackage(loader);
loadHttp11Package(loader);
+loadJkPackage(loader);
}
@@ -239,6 +240,14 @@
loader.loadClass
(basePackage +
CoyoteResponse$3);
+}
+
+private final static void loadJkPackage(ClassLoader loader)
+throws Exception {
+String basePackage = org.apache.tomcat.util.;
+loader.loadClass
+(basePackage +
+ buff.C2BConverter);
}
}
-1. That breaks the way we are implementing security. The role of this
class is to load security related inner classes. Doing this make the
class available for all Servlet (that break the package protection
mechanism). You should add a doPrivileged block within the jk code
instead and load the inner class here. Also, it is now impossible to
protect that class using the catalina.properties if you do that.
If you think C2BConverter is secure and should not be protected
(avaiable to Servlet), add the package to the catalina.policy instead.
-- Jeanfrancois
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25822] - tomcat shouldn't write tomcat-users.xml at startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25822. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25822 tomcat shouldn't write tomcat-users.xml at startup --- Additional Comments From [EMAIL PROTECTED] 2004-01-06 15:41 --- Created an attachment (id=9829) complete the first patch to correctly detect all modifications - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25822] - tomcat shouldn't write tomcat-users.xml at startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25822. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25822 tomcat shouldn't write tomcat-users.xml at startup --- Additional Comments From [EMAIL PROTECTED] 2004-01-06 15:43 --- Since you liked my first patch tentative, I completed it by detecting every modifications made to the UserDatabase. I hope this could be accepted since it remains simple. - 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/security SecurityClassLoad.java
- Original Message -
From: Jeanfrancois Arcand [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, January 06, 2004 7:40 AM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security
SecurityClassLoad.java
[EMAIL PROTECTED] wrote:
billbarker2004/01/05 20:27:34
Modified:catalina/src/share/org/apache/catalina/security
SecurityClassLoad.java
Log:
Adding classes for Coyote-Jk.
This addresses Bug #25819.
Reported By: Dario Bonino [EMAIL PROTECTED]
Revision ChangesPath
1.12 +13 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/Secu
rityClassLoad.java
Index: SecurityClassLoad.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/sec
urity/SecurityClassLoad.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- SecurityClassLoad.java 31 Oct 2003 01:30:01 - 1.11
+++ SecurityClassLoad.java 6 Jan 2004 04:27:34 - 1.12
@@ -90,6 +90,7 @@
loadJavaxPackage(loader);
loadCoyotePackage(loader);
loadHttp11Package(loader);
+loadJkPackage(loader);
}
@@ -239,6 +240,14 @@
loader.loadClass
(basePackage +
CoyoteResponse$3);
+}
+
+private final static void loadJkPackage(ClassLoader loader)
+throws Exception {
+String basePackage = org.apache.tomcat.util.;
+loader.loadClass
+(basePackage +
+ buff.C2BConverter);
}
}
-1. That breaks the way we are implementing security. The role of this
class is to load security related inner classes. Doing this make the
class available for all Servlet (that break the package protection
mechanism). You should add a doPrivileged block within the jk code
instead and load the inner class here. Also, it is now impossible to
protect that class using the catalina.properties if you do that.
If you think C2BConverter is secure and should not be protected
(avaiable to Servlet), add the package to the catalina.policy instead.
I'll revert it. C2BC is pretty harmless (it's basically a glorified Writer
:), but it doesn't really need to be in catalina.policy. It just seemed to
be over-kill to create a PA for one new statement ;).
-- Jeanfrancois
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java
kinman 2004/01/06 11:42:40
Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
Log:
- Fix 25787: Directives added to working tag files are not generated.
Revision ChangesPath
1.75 +7 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.74
retrieving revision 1.75
diff -u -r1.74 -r1.75
--- Compiler.java 10 Nov 2003 22:26:20 - 1.74
+++ Compiler.java 6 Jan 2004 19:42:39 - 1.75
@@ -545,25 +545,28 @@
}
Iterator it = depends.iterator();
+boolean outDated = false;
while (it.hasNext()) {
String include = (String)it.next();
try {
URL includeUrl = ctxt.getResource(include);
if (includeUrl == null) {
//System.out.println(Compiler: outdated, no includeUri +
include );
-return true;
+outDated = true;
}
if (includeUrl.openConnection().getLastModified()
targetLastModified) {
//System.out.println(Compiler: outdated, include old +
include );
-return true;
+outDated = true;
+// Remove any potential Wrappers for tag files
+ctxt.getRuntimeContext().removeWrapper(include);
}
} catch (Exception e) {
e.printStackTrace();
-return true;
+outDated = true;
}
}
-return false;
+return outDated;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25787] - adding %@ attribute name=xxx fragment=true % won't be declared
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25787. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25787 adding %@ attribute name=xxx fragment=true % won't be declared [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-01-06 19:44 --- Reopen to change status - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25787] - adding %@ attribute name=xxx fragment=true % won't be declared
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25787. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25787 adding %@ attribute name=xxx fragment=true % won't be declared [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-06 19:48 --- Upon a closer look, there is a bug after all. Apologies to [EMAIL PROTECTED] (Kjeld Ingemann Poulsen) When compiling a tagfile, the cached TagInfo object was passed, even when the tagfile has been modified. This is now fixed. Thanks for reporting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH]Virtual Host Choice on HTML Manager
on Mon, 05 Jan 2004 20:57:28 +0100 Remy Maucherat [EMAIL PROTECTED] wrote: An acceptable patch would be to extend the existing manager class with a new class which implements this feature. Then those administering Tomcat can choose which version of the manager they want to install. I agree with this. Is one manager per vhost really too much to ask ? (since different principals will be needed in many situations) Thanx for your comments everyone. I got your point. I'm not lazy to login each virtual host, but I am when installing manager application to each virtual host. There are a use cases for the feature, of course, so I'm ok with having an extension class that could replace the default manager servlet. I'll try to modify as follows: 1)Make new classes extend HTMLManagerServlet ManagerServlet. 2)These servlets are optional. (commented out in web.xml) 3)Only admin role can access them. (by web.xml) Do you think I've it figured out? Regards. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c
mmanders2004/01/06 13:44:20
Modified:jk/native/common jk_ajp_common.c
Log:
Fixed logic when attempting to reuse connections in ajp_send_request. If the send
is successful, we needed to get out of the while loop. If the ping/pong or the
request failed, try and reuse without getting out of the loop.
Revision ChangesPath
1.44 +6 -2 jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
Index: jk_ajp_common.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- jk_ajp_common.c 5 Jan 2004 22:42:03 - 1.43
+++ jk_ajp_common.c 6 Jan 2004 21:44:20 - 1.44
@@ -1025,14 +1025,18 @@
err++;
}
+/* If we got an error or can't send data, then try to get a pooled */
+/* connection and try again. If we are succesful, break out of this */
+/* loop. */
if (err || ajp_connection_tcp_send_message(ae, op-request, l) == JK_FALSE)
{
jk_log(l, JK_LOG_INFO,
Error sending request try another pooled connection\n);
jk_close_socket(ae-sd);
ae-sd = -1;
ajp_reuse_connection(ae, l);
- break;
}
+else
+break;
}
/*
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17762] - runtime link error loading jkjni.so
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17762.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17762
runtime link error loading jkjni.so
--- Additional Comments From [EMAIL PROTECTED] 2004-01-06 21:49 ---
After a long time of not working with this, I decided to tackle the issue again.
I'm now on Fedora Core 1, j2sdk 1.4.2_02, Tomcat 5.0.16, and Apache 2.0.48.
I used the following flags before compiling Apache 2.0.48
export LDFLAGS=-lgdbm -lldap -lexpat -ldb -L/usr
export CPPFLAGS=-I/usr/kerberos/include -I/usr/openssl/include
I used the following to configure Apache 2.0.48
./configure --enable-ssl=shared --enable-modules=all --enable-mods-shared=most
I then moved over to the connectors - source from:
jakarta-tomcat-connectors-jk2-2.0.2-src.tar.gz
I ran the following configure command in
jakarta-tomcat-connectors-jk2-2.0.2-src/native/jk2:
./configure --with-apxs2=/home/apache/bin/apxs \
--with-tomcat41=/home/tomcat \
--with-os-type=/usr/java/jre/lib/i386 \
--with-jni \
--with-pcre
The third line is new.
Once the configuration is run, the Makefile in
jakarta-tomcat-connectors-jk2-2.0.2-src/native/jk2/server/apache2 was altered.
JK_LDFLAGS=-L${APACHE2_LIBDIR} -lcrypt -lapr-0 -lpcre -lpcreposix -laprutil-0
In particular, -laprutil-0 was added.
After building and installing mod_jk2.so and jkjni.so, I was able to get the
following Apache 2.048 - Tomcat 5.0.16
httpd - tomcat via IP socketsworks
httpd - tomcat via UNIX sockets works
httpd - tomcat via in-processloops with unable to find child in
httpd error_log
This has been mentioned on the Tomcat mailing lists, so I will search to see if
there is a solution.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
Larry,
AFAIK Tomcat behaviour does not depend on the version of the
deployment descriptor schema apart from during the
interpretation of the descriptor. On this basis, I am against
setting a precedent here.
Further, my understanding is that each version of Tomcat is
written to support a single defined version of the spec. It is
not written to support multiple spec versions. If a version of
the spec is not 100% backwards compatible with the previous
version I believe that this is a spec issue, not a tomcat
issue.
It is inevitable that in each new version of the spec there will
be a number of areas that will cause problems with migrating
applications from a previous version.
I would be interested to hear the views of other tomcat
developers on this issue.
Mark
On Tuesday, January 06, 2004 3:27 PM, Larry Isaacs [SMTP:[EMAIL PROTECTED]
wrote:
Mark,
For backwards compatibility, I think the restrictions to the TLD
location need to follow the spec level used by the web application.
Since JSP 1.1 didn't include much in the way of restrictions,
I know of some legacy Servlet 2.2/JSP 1.1 webapps that would fail
these restrictions if deployed to Tomcat 5 with this change (or
Tomcat 4.1 with the port of this change). If you want, I can take
a look at fixing this.
Cheers,
Larry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 03, 2004 8:57 AM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/reso
urces messages.properties
markt 2004/01/03 05:56:39
Modified:jasper2/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java
jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
- Fix bug 11069. Check that the location of the TLD file is
spec compliant.
Revision ChangesPath
1.50 +11 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/comp
iler/TagLibraryInfoImpl.java
Index: TagLibraryInfoImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/j
asper/compiler/TagLibraryInfoImpl.java,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- TagLibraryInfoImpl.java 3 Jan 2004 12:17:18 - 1.49
+++ TagLibraryInfoImpl.java 3 Jan 2004 13:56:38 - 1.50
@@ -5,7 +5,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999 The Apache Software Foundation. All rights
+ * Copyright (c) 1999,2004 The Apache Software Foundation.
All rights
* reserved.
*
* Redistribution and use in source and binary forms, with
or without
@@ -200,6 +200,13 @@
}
} catch (FileNotFoundException ex) {
err.jspError(jsp.error.file.not.found, location[0]);
+}
+
+// Check TLD file location conforms to JSP.7.3.1
+if (!location[0].startsWith(/WEB-INF/)
+||
location[0].startsWith(/WEB-INF/classes/)
+||
location[0].startsWith(/WEB-INF/lib/)) {
+
err.jspError(jsp.error.tld.invalid.location, location[0]);
}
parseTLD(ctxt, location[0], in, null);
1.138 +2 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/reso
urces/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/j
asper/resources/messages.properties,v
retrieving revision 1.137
retrieving revision 1.138
diff -u -r1.137 -r1.138
--- messages.properties 11 Dec 2003 18:24:21 - 1.137
+++ messages.properties 3 Jan 2004 13:56:39 - 1.138
@@ -187,6 +187,7 @@
jsp.error.tld.unable_to_read=Unable to read TLD \{1}\
from JAR file \{0}\: {2}
jsp.error.tld.unable_to_get_jar=Unable to get JAR resource
\{0}\ containing TLD: {1}
jsp.error.tld.missing_jar=Missing JAR resource \{0}\
containing TLD
+jsp.error.tld.invalid.location=\{0}\ is not a valid
location for a TLD as per JSP specification JSP.7.3.1
jsp.error.webxml_not_found=Could not locate web.xml
jsp.cmd_line.usage=Usage: jsptoservlet [-dd
path/to/outputDirectory] [-keepgenerated] \
.jsp files
-
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]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardHostDeployer.java
markt 2004/01/06 14:31:18
Modified:catalina/src/share/org/apache/catalina/core
StandardHostDeployer.java
Log:
- Fix bug11682. Deploying a webapp to the root context via an Ant
task when unpackWARs is true now behaves correctly.
Revision ChangesPath
1.17 +6 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java
Index: StandardHostDeployer.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- StandardHostDeployer.java 14 Nov 2003 10:02:23 - 1.16
+++ StandardHostDeployer.java 6 Jan 2004 22:31:18 - 1.17
@@ -396,7 +396,11 @@
// Expand war file if host wants wars unpacked
if (isWAR host.isUnpackWARs()) {
-docBase = ExpandWar.expand(host, war, contextPath);
+if (contextPath.equals()) {
+docBase = ExpandWar.expand(host, war, /ROOT);
+} else {
+docBase = ExpandWar.expand(host, war, contextPath);
+}
}
// Install the new web application
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardHostDeployer.java
markt 2004/01/06 14:32:07
Modified:catalina/src/share/org/apache/catalina/core
StandardHostDeployer.java
Log:
- Fix bug11682. Deploying a webapp to the root context via an Ant
task when unpackWARs is true now behaves correctly.
- Ported from TC5.
- Remove unused imports - thanks to Eclipse.
Revision ChangesPath
1.14 +9 -9
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java
Index: StandardHostDeployer.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- StandardHostDeployer.java 13 Jan 2003 23:23:28 - 1.13
+++ StandardHostDeployer.java 6 Jan 2004 22:32:07 - 1.14
@@ -65,13 +65,10 @@
package org.apache.catalina.core;
-import java.io.BufferedOutputStream;
import java.io.File;
-import java.io.FileOutputStream;
import java.io.InputStream;
import java.io.IOException;
import java.net.URL;
-import java.util.Enumeration;
import org.apache.catalina.Container;
import org.apache.catalina.Context;
import org.apache.catalina.Deployer;
@@ -85,7 +82,6 @@
import org.apache.catalina.startup.NamingRuleSet;
import org.apache.catalina.util.StringManager;
import org.apache.commons.digester.Digester;
-import org.xml.sax.SAXParseException;
/**
@@ -288,7 +284,11 @@
// Expand war file if host wants wars unpacked
if (isWAR host.isUnpackWARs()) {
-docBase = ExpandWar.expand(host,war,contextPath);
+if (contextPath.equals()) {
+docBase = ExpandWar.expand(host,war,/ROOT);
+} else {
+docBase = ExpandWar.expand(host,war,contextPath);
+}
}
// Install the new web application
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11682] - App does not work when deployed to root context via ant
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11682. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11682 App does not work when deployed to root context via ant [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-06 22:33 --- Various changes mean that this was still broken but in a different way. I have committed fixes to TC4 and TC5. The next release of each will include the fix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardHostDeployer.java
[EMAIL PROTECTED] wrote: markt 2004/01/06 14:31:18 Modified:catalina/src/share/org/apache/catalina/core StandardHostDeployer.java Log: - Fix bug11682. Deploying a webapp to the root context via an Ant task when unpackWARs is true now behaves correctly. Are you sure this was actually broken ? Note that the install task is deprecated (deploy should be used instead), so no fix is needed for that. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH]Virtual Host Choice on HTML Manager
On Wed, Jan 07, 2004 at 12:33:38AM +0900, TANAKA Yoshihiro wrote: on Mon, 05 Jan 2004 20:57:28 +0100 Remy Maucherat [EMAIL PROTECTED] wrote: An acceptable patch would be to extend the existing manager class with a new class which implements this feature. Then those administering Tomcat can choose which version of the manager they want to install. I agree with this. Is one manager per vhost really too much to ask ? (since different principals will be needed in many situations) Thanx for your comments everyone. I got your point. I'm not lazy to login each virtual host, but I am when installing manager application to each virtual host. There are a use cases for the feature, of course, so I'm ok with having an extension class that could replace the default manager servlet. I'll try to modify as follows: 1)Make new classes extend HTMLManagerServlet ManagerServlet. 2)These servlets are optional. (commented out in web.xml) 3)Only admin role can access them. (by web.xml) Do you think I've it figured out? That sounds right. :-) Thanks for contributing your patches so that others can benefit from them. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11710] - startup/shutdown - FileNotFoundException on server.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11710. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11710 startup/shutdown - FileNotFoundException on server.xml [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-06 22:52 --- This has been fixed for some time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardHostDeployer.java
When I tested the deploy task, the behaviour I saw was that the original codedocBase = ExpandWar.expand(host, war, contextPath)code; failed to create any files at all in the webapp directory. The root context _was_ displayed in the manager app but when I tried to access it all I saw was a directory listing for the webapp directory. It was on this basis that I wrote the fix. Mark On Tuesday, January 06, 2004 10:41 PM, Remy Maucherat [SMTP:[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: markt 2004/01/06 14:31:18 Modified:catalina/src/share/org/apache/catalina/core StandardHostDeployer.java Log: - Fix bug11682. Deploying a webapp to the root context via an Ant task when unpackWARs is true now behaves correctly. Are you sure this was actually broken ? Note that the install task is deprecated (deploy should be used instead), so no fix is needed for that. 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]
DO NOT REPLY [Bug 11784] - Failure in loading class with destroy method of Servlet
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11784. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11784 Failure in loading class with destroy method of Servlet [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-06 23:31 --- It looks like you are using packageless classes. This could well be the root cause of the problem. See http://jakarta.apache.org/tomcat/faq/classnotfound.html for more info. I haven't tested this but I am going to resolve as invalid as this is a fairly common problem. If using packages doesn't solve the problem than please feel free to re-open this bug and I will look at it further. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
Hi Mark,
Kin-Man pointed me to this thread and I figured I'd contribute my
interpretation.
For reference, the JSP 2.0 specification, JSP.7.3.1 states:
Tag library descriptor files have names that use the
extension .tld, and the extension indicates a tag library
descriptor file. When deployed inside a JAR file, the tag
library descriptor files must be in the META-INF directory, or
a subdirectory of it. When deployed directly into a web
application, the tag library descriptor files must always be in
the WEB-INF directory, or some subdirectory of it. TLD files
should not be placed in /WEB-INF/classes or /WEB-INF/lib.
A few notes:
1. The intent of this guideline is that the container can but need not
recognize .tld files elsewhere. This is a requirement on the
application, not the container. In other words, an application
that places its TLD file in any other location is in violation of
the specification, and a container can but need not handle that
application.
2. The specification does not state that an error occurs if a TLD
file appears elsewhere. It leaves it up to the container.
3. The specification says should not be placed in /WEB-INF/classes
or /WEB-INF/lib, not must, so the requirement for these two
locations is even less strong.
So it seems we're free to do what we want in Tomcat. My recommendation
would be to either leave it the way it was or log a warning to the user
that the application is not spec-compliant.
I don't like producing an error here - if prior versions of Tomcat
handled this, I see no reason to go out of our way to change this and
break applications that once worked. However, it might be appropriate
to log a friendly warning to the user since the application is not
following the specification.
---
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.
Mark Thomas wrote:
Larry,
AFAIK Tomcat behaviour does not depend on the version of the
deployment descriptor schema apart from during the
interpretation of the descriptor. On this basis, I am against
setting a precedent here.
Further, my understanding is that each version of Tomcat is
written to support a single defined version of the spec. It is
not written to support multiple spec versions. If a version of
the spec is not 100% backwards compatible with the previous
version I believe that this is a spec issue, not a tomcat
issue.
It is inevitable that in each new version of the spec there will
be a number of areas that will cause problems with migrating
applications from a previous version.
I would be interested to hear the views of other tomcat
developers on this issue.
Mark
On Tuesday, January 06, 2004 3:27 PM, Larry Isaacs [SMTP:[EMAIL PROTECTED]
wrote:
Mark,
For backwards compatibility, I think the restrictions to the TLD
location need to follow the spec level used by the web application.
Since JSP 1.1 didn't include much in the way of restrictions,
I know of some legacy Servlet 2.2/JSP 1.1 webapps that would fail
these restrictions if deployed to Tomcat 5 with this change (or
Tomcat 4.1 with the port of this change). If you want, I can take
a look at fixing this.
Cheers,
Larry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 03, 2004 8:57 AM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/reso
urces messages.properties
markt 2004/01/03 05:56:39
Modified:jasper2/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java
jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
- Fix bug 11069. Check that the location of the TLD file is
spec compliant.
Revision ChangesPath
1.50 +11 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/comp
iler/TagLibraryInfoImpl.java
Index: TagLibraryInfoImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/j
asper/compiler/TagLibraryInfoImpl.java,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- TagLibraryInfoImpl.java3 Jan 2004 12:17:18 - 1.49
+++ TagLibraryInfoImpl.java3 Jan 2004 13:56:38 - 1.50
@@ -5,7 +5,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999 The Apache Software Foundation. All rights
+ * Copyright (c) 1999,2004 The Apache Software Foundation.
All rights
* reserved.
*
* Redistribution and use in source and binary forms, with
or without
@@ -200,6 +200,13 @@
}
} catch (FileNotFoundException ex) {
err.jspError(jsp.error.file.not.found, location[0]);
+}
+
+// Check TLD file location conforms to JSP.7.3.1
+if (!location[0].startsWith(/WEB-INF/)
+||
DO NOT REPLY [Bug 11845] - Session sometimes times out
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11845. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11845 Session sometimes times out [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-07 00:07 --- Sorry, there just isn't enough information here to debug this issue. I have searched all the TC4 bugs (open and closed) but I can't find any similar reports. My best guess (and it is only a guess) is that it is something in your web app. If you have been able to reproduce this please re-open this report, adding the steps to reproduce. Better yet would be a simple web app that demonstrates it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
Mark, Thanks for the clarification. I must confess I has missed the 'should' and read it as 'must'. I'll revert my previous patch and modify the bugzilla report to an enhancement request to log a warning. Mark On Tuesday, January 06, 2004 11:45 PM, Mark Roth [SMTP:[EMAIL PROTECTED] wrote: Hi Mark, Kin-Man pointed me to this thread and I figured I'd contribute my interpretation. For reference, the JSP 2.0 specification, JSP.7.3.1 states: Tag library descriptor files have names that use the extension .tld, and the extension indicates a tag library descriptor file. When deployed inside a JAR file, the tag library descriptor files must be in the META-INF directory, or a subdirectory of it. When deployed directly into a web application, the tag library descriptor files must always be in the WEB-INF directory, or some subdirectory of it. TLD files should not be placed in /WEB-INF/classes or /WEB-INF/lib. A few notes: 1. The intent of this guideline is that the container can but need not recognize .tld files elsewhere. This is a requirement on the application, not the container. In other words, an application that places its TLD file in any other location is in violation of the specification, and a container can but need not handle that application. 2. The specification does not state that an error occurs if a TLD file appears elsewhere. It leaves it up to the container. 3. The specification says should not be placed in /WEB-INF/classes or /WEB-INF/lib, not must, so the requirement for these two locations is even less strong. So it seems we're free to do what we want in Tomcat. My recommendation would be to either leave it the way it was or log a warning to the user that the application is not spec-compliant. I don't like producing an error here - if prior versions of Tomcat handled this, I see no reason to go out of our way to change this and break applications that once worked. However, it might be appropriate to log a friendly warning to the user since the application is not following the specification. --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. Mark Thomas wrote: Larry, AFAIK Tomcat behaviour does not depend on the version of the deployment descriptor schema apart from during the interpretation of the descriptor. On this basis, I am against setting a precedent here. Further, my understanding is that each version of Tomcat is written to support a single defined version of the spec. It is not written to support multiple spec versions. If a version of the spec is not 100% backwards compatible with the previous version I believe that this is a spec issue, not a tomcat issue. It is inevitable that in each new version of the spec there will be a number of areas that will cause problems with migrating applications from a previous version. I would be interested to hear the views of other tomcat developers on this issue. Mark On Tuesday, January 06, 2004 3:27 PM, Larry Isaacs [SMTP:[EMAIL PROTECTED] wrote: Mark, For backwards compatibility, I think the restrictions to the TLD location need to follow the spec level used by the web application. Since JSP 1.1 didn't include much in the way of restrictions, I know of some legacy Servlet 2.2/JSP 1.1 webapps that would fail these restrictions if deployed to Tomcat 5 with this change (or Tomcat 4.1 with the port of this change). If you want, I can take a look at fixing this. Cheers, Larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, January 03, 2004 8:57 AM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/reso urces messages.properties markt 2004/01/03 05:56:39 Modified:jasper2/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java jasper2/src/share/org/apache/jasper/resources messages.properties Log: - Fix bug 11069. Check that the location of the TLD file is spec compliant. Revision ChangesPath 1.50 +11 -4 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/comp iler/TagLibraryInfoImpl.java Index: TagLibraryInfoImpl.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/j asper/compiler/TagLibraryInfoImpl.java,v retrieving revision 1.49 retrieving revision 1.50 diff -u -r1.49 -r1.50 --- TagLibraryInfoImpl.java 3 Jan 2004 12:17:18 - 1.49 +++ TagLibraryInfoImpl.java 3 Jan 2004 13:56:38 - 1.50 @@ -5,7 +5,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 1999 The Apache Software Foundation. All
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
markt 2004/01/06 16:37:47
Modified:jasper2/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java
jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
- Reverting previous patch. Clarification of the spec from Mark Roth has
indicated that a warning in the log would be more appropriate.
Revision ChangesPath
1.51 +2 -9
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
Index: TagLibraryInfoImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -r1.50 -r1.51
--- TagLibraryInfoImpl.java 3 Jan 2004 13:56:38 - 1.50
+++ TagLibraryInfoImpl.java 7 Jan 2004 00:37:47 - 1.51
@@ -5,7 +5,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999,2004 The Apache Software Foundation. All rights
+ * Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -200,13 +200,6 @@
}
} catch (FileNotFoundException ex) {
err.jspError(jsp.error.file.not.found, location[0]);
-}
-
-// Check TLD file location conforms to JSP.7.3.1
-if (!location[0].startsWith(/WEB-INF/)
-|| location[0].startsWith(/WEB-INF/classes/)
-|| location[0].startsWith(/WEB-INF/lib/)) {
-err.jspError(jsp.error.tld.invalid.location, location[0]);
}
parseTLD(ctxt, location[0], in, null);
1.139 +0 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.138
retrieving revision 1.139
diff -u -r1.138 -r1.139
--- messages.properties 3 Jan 2004 13:56:39 - 1.138
+++ messages.properties 7 Jan 2004 00:37:47 - 1.139
@@ -187,7 +187,6 @@
jsp.error.tld.unable_to_read=Unable to read TLD \{1}\ from JAR file \{0}\: {2}
jsp.error.tld.unable_to_get_jar=Unable to get JAR resource \{0}\ containing TLD:
{1}
jsp.error.tld.missing_jar=Missing JAR resource \{0}\ containing TLD
-jsp.error.tld.invalid.location=\{0}\ is not a valid location for a TLD as per JSP
specification JSP.7.3.1
jsp.error.webxml_not_found=Could not locate web.xml
jsp.cmd_line.usage=Usage: jsptoservlet [-dd path/to/outputDirectory]
[-keepgenerated] \
.jsp files
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
markt 2004/01/06 16:39:20
Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch TagLibraryInfoImpl.java
jasper2/src/share/org/apache/jasper/resources Tag:
tomcat_4_branch messages.properties
Log:
- Reverting previous patch. Clarification of the spec from Mark Roth has
indicated that a warning in the log would be more appropriate.
Revision ChangesPath
No revision
No revision
1.2.2.3 +2 -8
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
Index: TagLibraryInfoImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
retrieving revision 1.2.2.2
retrieving revision 1.2.2.3
diff -u -r1.2.2.2 -r1.2.2.3
--- TagLibraryInfoImpl.java 3 Jan 2004 13:58:39 - 1.2.2.2
+++ TagLibraryInfoImpl.java 7 Jan 2004 00:39:20 - 1.2.2.3
@@ -5,7 +5,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999,2004 The Apache Software Foundation. All rights
+ * Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -179,12 +179,6 @@
} catch (FileNotFoundException ex) {
err.jspError(jsp.error.file.not.found, location[0]);
}
-
-// Check TLD file location conforms to JSP.7.3.1
-if (!location[0].startsWith(/WEB-INF/)) {
-err.jspError(jsp.error.tld.invalid.location, location[0]);
-}
-
// Now parse the tld.
parseTLD(ctxt, location[0], in);
} else {
No revision
No revision
1.9.2.10 +0 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.9.2.9
retrieving revision 1.9.2.10
diff -u -r1.9.2.9 -r1.9.2.10
--- messages.properties 3 Jan 2004 13:58:39 - 1.9.2.9
+++ messages.properties 7 Jan 2004 00:39:20 - 1.9.2.10
@@ -148,7 +148,6 @@
jsp.error.missing_attribute=According to the TLD attribute {0} is mandatory for tag
{1}
jsp.error.bad_attribute=Attribute {0} invalid according to the specified TLD
jsp.error.tld_not_found=Could not locate TLD {0}
-jsp.error.tld.invalid.location=\{0}\ is not a valid location for a TLD as per JSP
specification JSP.7.3.1
jsp.error.webxml_not_found=Could not locate web.xml
jsp.cmd_line.usage=Usage: jsptoservlet [-o path/to/outputDirectory]
[-keepgenerated] \
.jsp files
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11069] - Tomcat not flag error if tld is outside of /WEB-INF
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11069. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11069 Tomcat not flag error if tld is outside of /WEB-INF [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-01-07 00:42 --- After clarification of the spec from Mark Roth (see Tomcat-Dev) I have reverted my previous patch. The preferred action is to accept .tld files in non-spec compliant locations but to log a warning if one is found. I have updated the severity of this bug to enhancement as a result of this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
No problem, Mark. Thanks, --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. Mark Thomas wrote: Mark, Thanks for the clarification. I must confess I has missed the 'should' and read it as 'must'. I'll revert my previous patch and modify the bugzilla report to an enhancement request to log a warning. Mark On Tuesday, January 06, 2004 11:45 PM, Mark Roth [SMTP:[EMAIL PROTECTED] wrote: Hi Mark, Kin-Man pointed me to this thread and I figured I'd contribute my interpretation. For reference, the JSP 2.0 specification, JSP.7.3.1 states: Tag library descriptor files have names that use the extension .tld, and the extension indicates a tag library descriptor file. When deployed inside a JAR file, the tag library descriptor files must be in the META-INF directory, or a subdirectory of it. When deployed directly into a web application, the tag library descriptor files must always be in the WEB-INF directory, or some subdirectory of it. TLD files should not be placed in /WEB-INF/classes or /WEB-INF/lib. A few notes: 1. The intent of this guideline is that the container can but need not recognize .tld files elsewhere. This is a requirement on the application, not the container. In other words, an application that places its TLD file in any other location is in violation of the specification, and a container can but need not handle that application. 2. The specification does not state that an error occurs if a TLD file appears elsewhere. It leaves it up to the container. 3. The specification says should not be placed in /WEB-INF/classes or /WEB-INF/lib, not must, so the requirement for these two locations is even less strong. So it seems we're free to do what we want in Tomcat. My recommendation would be to either leave it the way it was or log a warning to the user that the application is not spec-compliant. I don't like producing an error here - if prior versions of Tomcat handled this, I see no reason to go out of our way to change this and break applications that once worked. However, it might be appropriate to log a friendly warning to the user since the application is not following the specification. --- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. Mark Thomas wrote: Larry, AFAIK Tomcat behaviour does not depend on the version of the deployment descriptor schema apart from during the interpretation of the descriptor. On this basis, I am against setting a precedent here. Further, my understanding is that each version of Tomcat is written to support a single defined version of the spec. It is not written to support multiple spec versions. If a version of the spec is not 100% backwards compatible with the previous version I believe that this is a spec issue, not a tomcat issue. It is inevitable that in each new version of the spec there will be a number of areas that will cause problems with migrating applications from a previous version. I would be interested to hear the views of other tomcat developers on this issue. Mark On Tuesday, January 06, 2004 3:27 PM, Larry Isaacs [SMTP:[EMAIL PROTECTED] wrote: Mark, For backwards compatibility, I think the restrictions to the TLD location need to follow the spec level used by the web application. Since JSP 1.1 didn't include much in the way of restrictions, I know of some legacy Servlet 2.2/JSP 1.1 webapps that would fail these restrictions if deployed to Tomcat 5 with this change (or Tomcat 4.1 with the port of this change). If you want, I can take a look at fixing this. Cheers, Larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, January 03, 2004 8:57 AM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/reso urces messages.properties markt 2004/01/03 05:56:39 Modified:jasper2/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java jasper2/src/share/org/apache/jasper/resources messages.properties Log: - Fix bug 11069. Check that the location of the TLD file is spec compliant. Revision ChangesPath 1.50 +11 -4 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/comp iler/TagLibraryInfoImpl.java Index: TagLibraryInfoImpl.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/j asper/compiler/TagLibraryInfoImpl.java,v retrieving revision 1.49 retrieving revision 1.50 diff -u -r1.49 -r1.50 --- TagLibraryInfoImpl.java 3 Jan 2004 12:17:18 - 1.49 +++ TagLibraryInfoImpl.java 3 Jan 2004 13:56:38 - 1.50 @@ -5,7 +5,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 1999 The Apache Software Foundation. All rights + * Copyright (c) 1999,2004 The Apache Software Foundation. All rights * reserved. * *
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security SecurityClassLoad.java
billbarker2004/01/06 20:56:09
Modified:catalina/src/share/org/apache/catalina/security
SecurityClassLoad.java
Log:
reviting patch.
Revision ChangesPath
1.14 +4 -13
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityClassLoad.java
Index: SecurityClassLoad.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityClassLoad.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- SecurityClassLoad.java6 Jan 2004 08:39:20 - 1.13
+++ SecurityClassLoad.java7 Jan 2004 04:56:09 - 1.14
@@ -90,7 +90,6 @@
loadJavaxPackage(loader);
loadCoyotePackage(loader);
loadHttp11Package(loader);
-loadJkPackage(loader);
}
@@ -240,14 +239,6 @@
loader.loadClass
(basePackage +
CoyoteResponse$3);
-}
-
-private final static void loadJkPackage(ClassLoader loader)
-throws Exception {
-String basePackage = org.apache.tomcat.util.;
-loader.loadClass
-(basePackage +
- buf.C2BConverter);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteResponseFacade.java
billbarker2004/01/06 21:06:47
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteResponseFacade.java
Log:
It seems that setDateHeader requires a PA when running in the sandbox.
Revision ChangesPath
1.3 +37 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteResponseFacade.java
Index: CoyoteResponseFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteResponseFacade.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- CoyoteResponseFacade.java 2 Sep 2003 21:21:59 - 1.2
+++ CoyoteResponseFacade.java 7 Jan 2004 05:06:47 - 1.3
@@ -105,7 +105,27 @@
return null;
}
}
-
+
+private final class DateHeaderPrivilegedAction implements PrivilegedAction {
+private String name;
+private long value;
+private boolean add;
+
+DateHeaderPrivilegedAction(String name, long value, boolean add) {
+this.name = name;
+this.value = value;
+this.add = add;
+}
+
+public Object run() {
+if(add) {
+response.addDateHeader(name, value);
+} else {
+response.setDateHeader(name, value);
+}
+return null;
+}
+}
// --- Constructors
@@ -391,7 +411,12 @@
if (isCommitted())
return;
-response.setDateHeader(name, date);
+if(System.getSecurityManager() != null) {
+AccessController.doPrivileged(new DateHeaderPrivilegedAction
+ (name, date, false));
+} else {
+response.setDateHeader(name, date);
+}
}
@@ -401,7 +426,12 @@
if (isCommitted())
return;
-response.addDateHeader(name, date);
+if(System.getSecurityManager() != null) {
+AccessController.doPrivileged(new DateHeaderPrivilegedAction
+ (name, date, true));
+} else {
+response.addDateHeader(name, date);
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java
billbarker2004/01/06 21:32:44
Modified:jk/java/org/apache/jk/server JkCoyoteHandler.java
Log:
Adding the required PAs to allow the Coyote-Jk connector to play in the sandbox.
Fix for Bug #25819.
Reported By: Dario Bonino [EMAIL PROTECTED]
Revision ChangesPath
1.47 +39 -2
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
Index: JkCoyoteHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- JkCoyoteHandler.java 30 Sep 2003 04:17:37 - 1.46
+++ JkCoyoteHandler.java 7 Jan 2004 05:32:44 - 1.47
@@ -64,6 +64,10 @@
import java.net.InetAddress;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
+import java.security.PrivilegedExceptionAction;
+import java.security.AccessController;
+import java.security.PrivilegedActionException;
+import java.security.PrivilegedAction;
import javax.management.MBeanServer;
import javax.management.ObjectName;
@@ -106,6 +110,17 @@
private static org.apache.commons.logging.Log logTime=
org.apache.commons.logging.LogFactory.getLog( org.apache.jk.REQ_TIME );
+// --- DoPrivileged
+private final class StatusLinePrivilegedAction implements PrivilegedAction {
+ int status;
+ StatusLinePrivilegedAction(int status) {
+ this.status = status;
+ }
+ public Object run() {
+ return HttpMessages.getMessage(status);
+ }
+}
+
int headersMsgNote;
int c2bConvertersNote;
int tmpMessageBytesNote;
@@ -330,7 +345,24 @@
C2BConverter c2b=(C2BConverter)res.getNote( utfC2bNote );
if( c2b==null ) {
-c2b=new C2BConverter( UTF8 );
+if(System.getSecurityManager() != null) {
+try {
+c2b = (C2BConverter)
+AccessController.doPrivileged(
+ new PrivilegedExceptionAction () {
+ public Object run()
+ throws IOException{
+ return new C2BConverter( UTF8 );
+ }
+ });
+} catch(PrivilegedActionException pae) {
+Exception ex = pae.getException();
+if(ex instanceof IOException)
+throw (IOException)ex;
+}
+} else {
+c2b=new C2BConverter( UTF8 );
+ }
res.setNote( utfC2bNote, c2b );
}
@@ -347,7 +379,12 @@
}
String message=res.getMessage();
if( message==null ){
-message= HttpMessages.getMessage(res.getStatus());
+ if( System.getSecurityManager() != null ) {
+ message = (String)AccessController.doPrivileged(
+ new
StatusLinePrivilegedAction(res.getStatus()));
+ } else {
+ message= HttpMessages.getMessage(res.getStatus());
+ }
} else {
message = message.replace('\n', ' ').replace('\r', ' ');
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security SecurityClassLoad.java
billbarker2004/01/06 21:33:28
Modified:catalina/src/share/org/apache/catalina/security
SecurityClassLoad.java
Log:
Preload the new PAs.
Revision ChangesPath
1.15 +18 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityClassLoad.java
Index: SecurityClassLoad.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityClassLoad.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- SecurityClassLoad.java7 Jan 2004 04:56:09 - 1.14
+++ SecurityClassLoad.java7 Jan 2004 05:33:28 - 1.15
@@ -90,6 +90,7 @@
loadJavaxPackage(loader);
loadCoyotePackage(loader);
loadHttp11Package(loader);
+loadJkPackage(loader);
}
@@ -204,6 +205,9 @@
(basePackage +
CoyoteResponseFacade$SetContentTypePrivilegedAction);
loader.loadClass
+(basePackage +
+ CoyoteResponseFacade$DateHeaderPrivilegedAction);
+loader.loadClass
(basePackage +
CoyoteRequestFacade$GetSessionPrivilegedAction);
loader.loadClass
@@ -241,5 +245,15 @@
CoyoteResponse$3);
}
+private final static void loadJkPackage(ClassLoader loader)
+throws Exception {
+String basePackage = org.apache.jk.;
+loader.loadClass
+(basePackage +
+ server.JkCoyoteHandler$1);
+loader.loadClass
+(basePackage +
+ server.JkCoyoteHandler$StatusLinePrivilegedAction);
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardHostDeployer.java
Mark Thomas wrote: When I tested the deploy task, the behaviour I saw was that the original codedocBase = ExpandWar.expand(host, war, contextPath)code; failed to create any files at all in the webapp directory. The root context _was_ displayed in the manager app but when I tried to access it all I saw was a directory listing for the webapp directory. Hmmm, maybe, I still don't quite see the problem. Can I get an example of a deploy command which would fail ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25819] - java.lang.NoClassDefFoundError: org/apache/tomcat/util/buf/C2BConverter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25819. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25819 java.lang.NoClassDefFoundError: org/apache/tomcat/util/buf/C2BConverter [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-07 05:36 --- I got a chance to take-down one of my servers sooner than I thought :). This is fixed now in the CVS, and will appear in 5.0.17. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 06, 2004 9:32 PM Subject: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java billbarker2004/01/06 21:32:44 Modified:jk/java/org/apache/jk/server JkCoyoteHandler.java Log: Adding the required PAs to allow the Coyote-Jk connector to play in the sandbox. I'm not really happy with how this turned out. The C2BC issue could actually get solved by moving the check for 'null', but it just didn't seem worth it (since it is a re-used component, the PA is invoked rarely). However, invoking a PA for the status line bothers me. My suggestion is to change o.a.t.u.http.HttpMessages to make 'getMessage' an instance (instead of the current static) method, and make everyone that wants to use it create an instance (at a point where they know the call-stack is clean). Excess memory usage should be pretty small, and you avoid a big hit with the PA. As always, I'm volunteering to do the code-monkey (copy; Pier) part of the project for TC 3.3.x-5.x. 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]
