DO NOT REPLY [Bug 11318] New: - Wrong decoding in HttpServletRequest.getPathInfo()
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=11318. 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=11318 Wrong decoding in HttpServletRequest.getPathInfo() Summary: Wrong decoding in HttpServletRequest.getPathInfo() Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I call my servlet like this http://host/app/MyServlet/some/path/with_UTF-8_encoded/characters I have a filter installed that sets request character encoding to UTF-8 on all request. HttpServletRequest.getPathInfo() seems always treat the URL as US-ASCI encoded. On the other hand HttpServletRequest.getRequestURI() returs properly decoded String. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Problem with HttpSession.setAttribute
Hello Using Tomcat 4 (in this example 4.0.4) I have problems with HttpSession.setAttribute(String name, Object value). Tomcat implements this interface which StandardSessionFacade: StandardSessionFacade.setAttribute(String name, Object value) The method call is delegated to StandardSession: StandardSession.setAttribute(String name, Object value) On line 1185 a HttpSessionBindingEvent is created with the extended constructor: new HttpSessionBindingEvent((HttpSession) this, name, value) This constructor then throws the following java.lang.NoSuchMethodError at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.jav a:1186) at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessi onFacade.java:191) at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessi onFacade.java:191) at org.hip.kernel.servlet.impl.AbstractRequestHandler.getContext(AbstractReques tHandler.java:261) at org.hip.kernel.servlet.impl.AbstractRequestHandler.doGet(AbstractRequestHand ler.java:172) at org.hip.vif.admin.servlets.impl.VIFAdminRequestHandler.doGet(VIFAdminRequest Handler.java:80) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:190) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2347) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve. java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :174) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java: 1027) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1125 ) at java.lang.Thread.run(Thread.java:484) An acceptable workaround would be to create the HttpSessionBindingEvent without the value object, i.e. new HttpSessionBindingEvent((HttpSession)this, name). After modifying the code in this way, my application worked without problems with Tomcat 4. If I had the source-code of javax.servlet.http package, I could debug further and eventually locate and correct the error. Greetings Benno -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11324] New: - forward() doesnt add parameters to query string
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=11324. 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=11324 forward() doesnt add parameters to query string Summary: forward() doesnt add parameters to query string Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows XP Status: NEW Severity: Major Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In Tomcat 331 I could call forward(fred.dyn?id=222) from a servlet that had already been called with a set of parameters say name=fredlocation=uk and in the forwarded servlet (fred.dyn) I could get query string and it would contain: id=222name=fredlocation=uk in tomcat 404 (I havent tried 4.1) the query string only contains the id=222. Now I realise the spec if loose in this area and it doesnt say that the query string should be updated - why do other containers BEA 6.0/7, WebSphere4, Tomcat3 - I suspect Caucho and Jetty would too (and havent time to test them) - do this and TC4 has taken the decision not to ? Surely this means that there could be servlets out there that will not work in TC 4 if they process the query string and dont use getParameter(). I have an example web app if reqd. james -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11327] New: - HTTP 400 on any request with URL containig UTF-8 sequence staring with %C4
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=11327. 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=11327 HTTP 400 on any request with URL containig UTF-8 sequence staring with %C4 Summary: HTTP 400 on any request with URL containig UTF-8 sequence staring with %C4 Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Any request to the application with URL containing UTF-8 encoded character starting with %C4 e.g. http://host/some_app/wst%C4%99.html Result in Tomcat Error Report: Apache Tomcat/4.0.4 - HTTP Status 400 - /some_app/wst?.html type Status report message /some_app/wst?.html description The request sent by the client was syntactically incorrect (/some_app/wst?.html). Other UTF-8 sequences (e.g. '%C5%82') work No known workaround (other that use only plain ASCII in URL). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Embedded Tomcat and custom connector ?
Hi back That was not so clear. What I would like to do is to get *all* http requests and manage them trough another connector then the one that passes them to the filesystem. Example: a http request comes and it's a GET /Test instead of trying to fetch the local Test directory I want to redirect this to another resource like a sql procedure or something else. I think that it's possible to do this by creating the connector by myself instead of creating it on the high level with createConnector method of the Embedded class. Something like creating a HttpConnector with an associated EventHanlder ? Any tips ? Any idea ? Thanks in advance. Eriam Eriam Schaffter wrote: Hi all. I'm embedding tomcat in a java app using the Embedded class. What I would like to do know is to use the http connector but I would instantiate it by my own and not via the createConnector method so I handle requests and responses in my program. The goal is to have a connector that handles http request a bit differently then the one in tomcat (redirect get request on another resource). Any suggestions ? Eriam -- 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]
Tomcat 4.0
Hi, we are using Tomcat 3.2.4, we deliver to the customer a solution with Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0. Our product work fine with Tomcat 4.0 and Tomcat 3.2.4. Our customers develop their applications using Tomcat 3.2.4 and so it is easy for them to a have a free environment then if they wish they can go to a commercial server. As tomcat 4.0 provides some efficient way to manage log .., compilation JSP, a standard taglib (JSTL) compatible. We are asking ourself if it is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3 and jsp 1.2 compatible. Most of the commercials products are working today on 2.2 and 1.1 platform so this is why we are asking this? We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have some responses they are very welcomed. Thomas Colin de Verdière -- SCORT http://www.scort.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11328] New: - Invocation of getWriter() during RequestDispatcher.foward()
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=11328. 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=11328 Invocation of getWriter() during RequestDispatcher.foward() Summary: Invocation of getWriter() during RequestDispatcher.foward() Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When forwarding a request during this process response.getWriter() seems to be invoked - at least if the response is wrapped (see detailed report attached). As far as I can see, this is illegal since it breaks target resources that want to send binary data. I'll attach: - log files that show the invokation - an example project with build file to reproduce the error -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11328] - Invocation of getWriter() during RequestDispatcher.foward()
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=11328. 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=11328 Invocation of getWriter() during RequestDispatcher.foward() --- Additional Comments From [EMAIL PROTECTED] 2002-07-31 13:00 --- Created an attachment (id=2542) Request URL Sequence -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11328] - Invocation of getWriter() during RequestDispatcher.foward()
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=11328. 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=11328 Invocation of getWriter() during RequestDispatcher.foward() --- Additional Comments From [EMAIL PROTECTED] 2002-07-31 13:01 --- Created an attachment (id=2543) Web App Log showing the Invocation Stack Trace -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11328] - Invocation of getWriter() during RequestDispatcher.foward()
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=11328. 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=11328 Invocation of getWriter() during RequestDispatcher.foward() --- Additional Comments From [EMAIL PROTECTED] 2002-07-31 13:02 --- Created an attachment (id=2544) Application to create the phenomenon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0
Hi, The 2.3/1.2 spec requires implementations to be backward compatible. http://jakarta.apache.org/tomcat/ As required by the specifications, Tomcat 4.0 also supports web applications built for the Servlet 2.2 and JSP 1.1 specifications with no changes. As far as the choice between 3.3.1 and 4.x, people have their favorites. A lot of people run either very happily. There are arguments for both approaches, but I'd say the critical factor for you is how involved your users are in the administration of some Tomcat instance. The decision is yours; I suppose you could offer both environments as development for any of your customers interested in migration. Let them do the assessment for you :) Regards, Michael Locasto - Original Message - From: Thomas Colin de Verdière [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 31, 2002 8:48 AM Subject: Tomcat 4.0 Hi, we are using Tomcat 3.2.4, we deliver to the customer a solution with Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0. Our product work fine with Tomcat 4.0 and Tomcat 3.2.4. Our customers develop their applications using Tomcat 3.2.4 and so it is easy for them to a have a free environment then if they wish they can go to a commercial server. As tomcat 4.0 provides some efficient way to manage log .., compilation JSP, a standard taglib (JSTL) compatible. We are asking ourself if it is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3 and jsp 1.2 compatible. Most of the commercials products are working today on 2.2 and 1.1 platform so this is why we are asking this? We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have some responses they are very welcomed. Thomas Colin de Verdière -- SCORT http://www.scort.com -- 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]
mod_jk, mod_jk2 URI spaces
Hi, Just been working for a week on a real-life TC-mod_jk situation, and found some interesting limitations (well, point of views to the concept). What are we doing right now is 'favoring' TC over Apache URI resolving, meaning that if we set something like /*.html, then all the .html context will be server by the TC. Now I propose that we make something like _not_ URI space filtering. Meaning that one could be able to serve every .html file through TC except for the /*/some_space/ location. Right now we are checking and hoping that the TC will accept the context, and then we forget that immediately. I propose that we make the map_to_storage two way (If the TC accepts it and then checking if the Apache configuration rejects it). Does that make any sense? MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11307] - Deadlock in ClassLoader
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=11307. 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=11307 Deadlock in ClassLoader --- Additional Comments From [EMAIL PROTECTED] 2002-07-31 13:45 --- Could you provide more information about your configuration and the application you are running. One of the threads with the deadlock is not a thread created by Tomcat 4. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0
Well in fact we would like to use Tomcat 4.0 but our customers may want to use Bea Weblogic, ATG dynamo .. We don't want to force them to use a specific server. My question should be : is there a way in Tomcat 4.0 to make it behave as a servlet 2.2, jsp 1.1 server. I looked at web.xml and there is the path to the dtd which could be constraint to force the customer not to use filter (for example). But for my jsps can i make them specific to a JSP version. Since we are developping demos it could be great to port on any server the customer would like. Am i clear? Michael E. Locasto wrote: Hi, The 2.3/1.2 spec requires implementations to be backward compatible. http://jakarta.apache.org/tomcat/ As required by the specifications, Tomcat 4.0 also supports web applications built for the Servlet 2.2 and JSP 1.1 specifications with no changes. As far as the choice between 3.3.1 and 4.x, people have their favorites. A lot of people run either very happily. There are arguments for both approaches, but I'd say the critical factor for you is how involved your users are in the administration of some Tomcat instance. The decision is yours; I suppose you could offer both environments as development for any of your customers interested in migration. Let them do the assessment for you :) Regards, Michael Locasto - Original Message - From: Thomas Colin de Verdière [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 31, 2002 8:48 AM Subject: Tomcat 4.0 Hi, we are using Tomcat 3.2.4, we deliver to the customer a solution with Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0. Our product work fine with Tomcat 4.0 and Tomcat 3.2.4. Our customers develop their applications using Tomcat 3.2.4 and so it is easy for them to a have a free environment then if they wish they can go to a commercial server. As tomcat 4.0 provides some efficient way to manage log .., compilation JSP, a standard taglib (JSTL) compatible. We are asking ourself if it is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3 and jsp 1.2 compatible. Most of the commercials products are working today on 2.2 and 1.1 platform so this is why we are asking this? We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have some responses they are very welcomed. Thomas Colin de Verdière -- SCORT http://www.scort.com -- 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] -- Thomas Colin de Verdière SCORT http://www.scort.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk, mod_jk2 URI spaces
Now I propose that we make something like _not_ URI space filtering. Meaning that one could be able to serve every .html file through TC except for the /*/some_space/ location. Right now we are checking and hoping that the TC will accept the context, and then we forget that immediately. I propose that we make the map_to_storage two way (If the TC accepts it and then checking if the Apache configuration rejects it). Does that make any sense? After I read my mail, it doesn't make sense even for me :) For example (what I have in mind) using mod_jk: JkMount /examples/* (This will map /examples URI space and everything belonging to the /examples will be served by the TC). JkNotMount /examples/*.gif JkNotMount /examples/*.jpg (This will map /examples URI space and everything will be served by the TC except the gif and jpg files). MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] [5.0] jakarta-servletapi-5
The 2.4 Servlet spec adds a new constant. See section 15.1.5 in the June 24th public draft. Cheers, -bob Index: src/share/javax/servlet/http/HttpServletResponse.java === RCS file: /home/cvspublic/jakarta-servletapi-5/src/share/javax/servlet/http/HttpServletResponse.java,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 HttpServletResponse.java --- src/share/javax/servlet/http/HttpServletResponse.java 16 Jul 2002 16:38:41 - 1.1.1.1 +++ src/share/javax/servlet/http/HttpServletResponse.java 31 Jul 2002 14:07:12 - @@ -445,9 +445,24 @@ * Status code (302) indicating that the resource has temporarily * moved to another location, but that future references should * still use the original URI to access the resource. + * + * This definition is being retained for backwards compatibility. + * SC_FOUND is now the preferred definition. */ public static final int SC_MOVED_TEMPORARILY = 302; + +/** +* Status code (302) indicating that the resource reside +* temporarily under a different URI. Since the redirection might +* be altered on occasion, the client should continue to use the +* Request-URI for future requests.(HTTP/1.1) To represent the +* status code (302), it is recommended to use this variable. +* +*/ + +public static final int SC_FOUND = 302; + /** * Status code (303) indicating that the response to the request -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11307] - Deadlock in ClassLoader
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=11307. 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=11307 Deadlock in ClassLoader --- Additional Comments From [EMAIL PROTECTED] 2002-07-31 14:43 --- Sure. The application is a Struts application utilizing JSP and Servlets. The non-tomcat thread that you see in the ClassLoader is from one of the Jini LookupDiscovery threads handling a response from the LookupService informing it that a service matching the requested template was found. This necessitates the remote class loading to be able to unmarshall the response. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/bin launcher.xml
patrickl2002/07/31 08:24:10 Removed: catalina/src/bin launcher.xml Log: Remove sample XML file since it will be replaced by a new file catalina.xml in the near future. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
web-app_2_3.dtd and servlet spec and tomcat session-timeout expireat 0 problem.
Hi,
This came up on the xdoclet-devel mailing list. The xdoclet
implementation takes follows the dtd saying that a session expires if
the session-timeout is = 0, while the spec says it will never expire if
session-timeout is -1, Tomcat says it will not expire if session-timeout
is 0. Now xdoclet sets it to 0 by default while Tomcat defaults it to
-1 meaning that Tomcat session expire in under 30 seconds if the
web.xml is created with xdoclet (or is manually set to 0).
http://cvs.apache.org/viewcvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java?rev=1.8content-type=text/vnd.viewcvs-markup
/**
* Indicate whether the session has been idle for longer
* than its expiration date as of the supplied time.
*
* FIXME: Probably belongs in the Session class.
*/
protected boolean isSessionStale(Session session, long timeNow) {
int maxInactiveInterval = session.getMaxInactiveInterval();
if (maxInactiveInterval = 0) {
int timeIdle = // Truncate, do not round up
(int) ((timeNow - session.getLastAccessedTime()) / 1000L);
if (timeIdle = maxInactiveInterval)
return true;
}
return false;
}
It this a bug in the dtd comment (see below)?
James
[EMAIL PROTECTED] wrote:
No. Check the DTD (http://java.sun.com/dtd/web-app_2_3.dtd). It clearly states this:
The session-timeout element defines the default session timeout
interval for all sessions created in this web application. The
specified timeout must be expressed in a whole number of minutes.
If the timeout is 0 or less, the container ensures the default
behaviour of sessions is never to time out.
Mathias
James Cooley [EMAIL PROTECTED] wrote:
Hi,
I noticed Tomcat 4.0.4 was timing out after about 30 seconds and on
looking at the servlet (2.3) spec it says that if the session timeout is
-1 then the session will not expire which seems at odds with the xdoclet
statement that:
If the timeout is 0 or less, the container ensures the default
behavior of sessions is never to time out.
So I guess the default should be -1 instead of 0.
James
---
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
___
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties messages_es.properties messages_ja.properties
luehe 2002/07/31 09:04:39
Modified:jasper2/src/share/org/apache/jasper/compiler Validator.java
jasper2/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
messages_ja.properties
Log:
Replaced call to TagExtraInfo.isValid() with the new
TagExtraInfo.validate(), as required by JSP 2.0.
Revision ChangesPath
1.15 +22 -6
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
Index: Validator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Validator.java22 Jul 2002 20:35:27 - 1.14
+++ Validator.java31 Jul 2002 16:04:39 - 1.15
@@ -837,9 +837,25 @@
err.jspError(n, jsp.error.missing.tagInfo, n.getName());
}
- if (!tagInfo.isValid(n.getTagData())) {
- err.jspError(n, jsp.error.invalid.attributes);
- }
+ ValidationMessage[] errors = tagInfo.validate(n.getTagData());
+if (errors != null errors.length != 0) {
+ StringBuffer errMsg = new StringBuffer();
+errMsg.append(h3);
+errMsg.append(err.getString(jsp.error.tei.invalid.attributes,
+ n.getName()));
+errMsg.append(/h3);
+for (int i=0; ierrors.length; i++) {
+errMsg.append(p);
+ if (errors[i].getId() != null) {
+ errMsg.append(errors[i].getId());
+ errMsg.append(: );
+ }
+errMsg.append(errors[i].getMessage());
+errMsg.append(/p);
+}
+
+ err.jspError(n, errMsg.toString());
+}
visitBody(n);
}
1.19 +3 -3
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.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- messages.properties 29 Jul 2002 22:29:01 - 1.18
+++ messages.properties 31 Jul 2002 16:04:39 - 1.19
@@ -160,7 +160,6 @@
jsp.error.unable.to_find_method=Unable to find setter method for attribute: {0}
jsp.error.unable.to_convert_string=Unable to convert a String to {0} for attribute
{1}
jsp.error.unable.to_introspect=Unable to introspect on tag handler class: {0}
because of {1}
-jsp.error.invalid_attributes=Attributes are invalid according to TagInfo
jsp.error.bad_tag=No such tag {0} in the tag library imported with prefix {1}
jsp.error.bad_string_Character=Cannot extract a Character from a zero length array
jsp.error.bad_string_char=Cannot extract a char from a zero length array
@@ -225,7 +224,8 @@
jspc.error.emptyWebApp=-webapp requires a trailing file argument
jsp.error.library.invalid=JSP page is invalid according to library {0}: {1}
jsp.warning.tlvclass.is.null=Could not load TagLibraryValidator class {0}: {1}
-jsp.error.taglibraryvalidator.invalidpage=Validation error messages from tag
library {0}
+jsp.error.tlv.invalid.page=Validation error messages from TagLibraryValidator for
{0}
+jsp.error.tei.invalid.attributes=Validation error messages from TagExtraInfo for {0}
jsp.parser.sax.propertynotsupported=SAX property not supported: {0}
jsp.parser.sax.propertynotrecognized=SAX property not recognized: {0}
jsp.parser.sax.featurenotsupported=SAX feature not supported: {0}
1.4 +4 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties
Index: messages_es.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- messages_es.properties8 Jul 2002 17:28:58 - 1.3
+++ messages_es.properties31 Jul 2002 16:04:39 - 1.4
@@ -133,7 +133,6 @@
jsp.error.unable.to_load_taghandler_class=No se puede cargar clase manejadora {0}
del tag acausa de {1}
jsp.error.unable.to_find_method=No se puede encontrar el metodo de escritura para
el atributo: {0}
jsp.error.unable.to_introspect=No se puede introspect on tag handler clase: {0} a
causa de {1}
-jsp.error.invalid_attributes=Los atributos no son validos de acuerdo con TagInfo
jsp.error.bad_tag=No
Re: Tomcat 4.0
There are not very involved since they should use another servlet container, even an application server. We have many of our customers using Tomcat 3.2.4 but some use Websphere, other WebLogic ... Our product work on tomcat we have our own Servlets and taglib delivered in WEB-INF/lib/ of our demos applications, we have configuration files in a subdirectory of the conf directory. There are some properties file for jndi access. Our product can be customized. This customization is on the properties file but also on jsps and servlets we deliver. For example we can have the customer can change an init-param for a servlet and he could also want to modify a Jsp page by adding custom tags. This customization the customer can do it anytime. But if he wants to port his customized application to another server we don't want him to use some jsp 1.2 specific features like using JSTL in our jsp since most of products are not jsp 1.2 compatible. The fact is that i want to migrate my taglib to jsp 1.2 compatible and i don't want to write (and support) it for both jsp 1.1 and jsp 1.2 server. We want a smooth migration .. Michael E. Locasto wrote: Hi, The 2.3/1.2 spec requires implementations to be backward compatible. http://jakarta.apache.org/tomcat/ As required by the specifications, Tomcat 4.0 also supports web applications built for the Servlet 2.2 and JSP 1.1 specifications with no changes. As far as the choice between 3.3.1 and 4.x, people have their favorites. A lot of people run either very happily. There are arguments for both approaches, but I'd say the critical factor for you is how involved your users are in the administration of some Tomcat instance. The decision is yours; I suppose you could offer both environments as development for any of your customers interested in migration. Let them do the assessment for you :) Regards, Michael Locasto - Original Message - From: Thomas Colin de Verdière [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 31, 2002 8:48 AM Subject: Tomcat 4.0 Hi, we are using Tomcat 3.2.4, we deliver to the customer a solution with Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0. Our product work fine with Tomcat 4.0 and Tomcat 3.2.4. Our customers develop their applications using Tomcat 3.2.4 and so it is easy for them to a have a free environment then if they wish they can go to a commercial server. As tomcat 4.0 provides some efficient way to manage log .., compilation JSP, a standard taglib (JSTL) compatible. We are asking ourself if it is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3 and jsp 1.2 compatible. Most of the commercials products are working today on 2.2 and 1.1 platform so this is why we are asking this? We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have some responses they are very welcomed. Thomas Colin de Verdière -- SCORT http://www.scort.com -- 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] -- Thomas Colin de Verdière SCORT http://www.scort.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0
On Wed, 31 Jul 2002, Thomas Colin de Verdière wrote: Date: Wed, 31 Jul 2002 18:04:55 +0200 From: Thomas Colin de Verdière [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Tomcat 4.0 There are not very involved since they should use another servlet container, even an application server. We have many of our customers using Tomcat 3.2.4 but some use Websphere, other WebLogic ... Our product work on tomcat we have our own Servlets and taglib delivered in WEB-INF/lib/ of our demos applications, we have configuration files in a subdirectory of the conf directory. There are some properties file for jndi access. Our product can be customized. This customization is on the properties file but also on jsps and servlets we deliver. For example we can have the customer can change an init-param for a servlet and he could also want to modify a Jsp page by adding custom tags. This customization the customer can do it anytime. But if he wants to port his customized application to another server we don't want him to use some jsp 1.2 specific features like using JSTL in our jsp since most of products are not jsp 1.2 compatible. The fact is that i want to migrate my taglib to jsp 1.2 compatible and i don't want to write (and support) it for both jsp 1.1 and jsp 1.2 server. We want a smooth migration .. As with web.xml files, tag library descriptors declare which version of JSP they are written for (1.1 or 1.2). Tomcat 4 runs apps with JSP 1.1 tag library descriptors just fine, with no changes. Craig Michael E. Locasto wrote: Hi, The 2.3/1.2 spec requires implementations to be backward compatible. http://jakarta.apache.org/tomcat/ As required by the specifications, Tomcat 4.0 also supports web applications built for the Servlet 2.2 and JSP 1.1 specifications with no changes. As far as the choice between 3.3.1 and 4.x, people have their favorites. A lot of people run either very happily. There are arguments for both approaches, but I'd say the critical factor for you is how involved your users are in the administration of some Tomcat instance. The decision is yours; I suppose you could offer both environments as development for any of your customers interested in migration. Let them do the assessment for you :) Regards, Michael Locasto - Original Message - From: Thomas Colin de Verdière [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 31, 2002 8:48 AM Subject: Tomcat 4.0 Hi, we are using Tomcat 3.2.4, we deliver to the customer a solution with Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0. Our product work fine with Tomcat 4.0 and Tomcat 3.2.4. Our customers develop their applications using Tomcat 3.2.4 and so it is easy for them to a have a free environment then if they wish they can go to a commercial server. As tomcat 4.0 provides some efficient way to manage log .., compilation JSP, a standard taglib (JSTL) compatible. We are asking ourself if it is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3 and jsp 1.2 compatible. Most of the commercials products are working today on 2.2 and 1.1 platform so this is why we are asking this? We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have some responses they are very welcomed. Thomas Colin de Verdière -- SCORT http://www.scort.com -- 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] -- Thomas Colin de Verdière SCORT http://www.scort.com -- 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]
DO NOT REPLY [Bug 11335] New: - RequestDispatcher.forward() is not 2.3 spec compliant
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=11335. 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=11335 RequestDispatcher.forward() is not 2.3 spec compliant Summary: RequestDispatcher.forward() is not 2.3 spec compliant Product: Tomcat 4 Version: 4.0.4 Final Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In SRV.8.4 of the servlet spec it says: The path elements of the request object exposed to the target servlet must reflect the path used to obtain the RequestDispatcher. The only exception to this is if the RequestDispatcher was obtained via the getNamedDispatcher method. With tomcat 4, if the request passed to forward has been wrapped (either by the current servlet/filter or by a previous servlet/filter) and that wrapper changes the value of the path methods - then the forward method exposes the wrapped values rather than the values used to obtain the request dispatcher. The Jetty container wraps the forwarded request and re-implements the path methods so that the correct values are exposed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: how to do auto update/reload of a class?
Hi All, Thank you, for your response. Do you have any thoughts as to how to auto re-load the classes, which have been loaded into JVM using Custom Class loader? I tried writing custom class loader and loaded all the classes, but don't know how to re-load the same class, if it has been modified (re-compiled) without shutting down JVM, similar to JSP engine, where if we put updated JSP file, it picks up the new file. Note: I learnt that, we need to recreate new class loader and load all the classes again, but don't know exactly how to apply that technique in the system. Any help is greatly appreciated. Thank you, Babu --- Ian Darwin [EMAIL PROTECTED] wrote: On July 28, 2002 10:32 pm, you wrote: Does anyone know, how to do auto update of classes into the JVM? I tried to write my own custom class loader, and loaded all the classes through it, however if I put new updated class, it won't reload the class again. Have anyone tried this before? Help is very much appreciated. This better asked on an advanced-java list; not tomcat specific. For all the cleverness of Java's dynamic loading mechanism (ClassLoader, Class.forName, newInstance(), etc.), there is no published API for unloading or reloading. They just didn't think of it in time, perhaps. What I think Tomcat and others do is basically to manage the class loader for each Context (which has to be separate from the CL for each other Context for configuration and security reasons anyway) in such a way that you can delete it (un-reference it) and assign a new one and reload the classes for the given Context. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: how to do auto update/reload of a class?
Hi All, Does anyone have any thoughts as to how to auto re-load the classes, which have been loaded into JVM using Custom Class loader? I tried writing custom class loader and loaded all the classes, but don't know how to re-load the same class, if it has been modified (re-compiled) without shutting down JVM, similar to JSP engine, where if we put updated JSP file, it picks up the new file. Note: I learnt that, we need to recreate new class loader and load all the classes again, but don't know exactly how to apply that technique in the system. Any help is greatly appreciated. Thank you, Babu --- Ian Darwin [EMAIL PROTECTED] wrote: On July 28, 2002 10:32 pm, you wrote: Does anyone know, how to do auto update of classes into the JVM? I tried to write my own custom class loader, and loaded all the classes through it, however if I put new updated class, it won't reload the class again. Have anyone tried this before? Help is very much appreciated. This better asked on an advanced-java list; not tomcat specific. For all the cleverness of Java's dynamic loading mechanism (ClassLoader, Class.forName, newInstance(), etc.), there is no published API for unloading or reloading. They just didn't think of it in time, perhaps. What I think Tomcat and others do is basically to manage the class loader for each Context (which has to be separate from the CL for each other Context for configuration and security reasons anyway) in such a way that you can delete it (un-reference it) and assign a new one and reload the classes for the given Context. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk, mod_jk2 URI spaces
On Wed, 31 Jul 2002, Mladen Turk wrote: Now I propose that we make something like _not_ URI space filtering. Meaning that one could be able to serve every .html file through TC except for the /*/some_space/ location. Right now we are checking and hoping that the TC will accept the context, and then we forget that immediately. I propose that we make the map_to_storage two way (If the TC accepts it and then checking if the Apache configuration rejects it). Does that make any sense? After I read my mail, it doesn't make sense even for me :) I actually understood the orginal mail, it's not that bad ( i.e. I've written worse messages :-) For example (what I have in mind) using mod_jk: JkMount /examples/* (This will map /examples URI space and everything belonging to the /examples will be served by the TC). JkNotMount /examples/*.gif JkNotMount /examples/*.jpg (This will map /examples URI space and everything will be served by the TC except the gif and jpg files). +1 The goal is to have tomcat serve dynamic content and apache static content, respecting as strictly as possible the web.xml semantic. Anything that helps that goal is good. However, I would like to see this in jk2 - JkMount is going to be deprecated and there is the issue of supporting multiple servers ( it won't be trivial to fix iis/nes in jk1.2 to support the same thing ). Plus jk1.2 is stable and close to a release. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 BUILDING.txt build.properties.default
patrickl2002/07/31 10:27:01
Modified:.BUILDING.txt build.properties.default
Log:
Update required commons-digester version to include XML schema support patch
Revision ChangesPath
1.7 +2 -2 jakarta-tomcat-5/BUILDING.txt
Index: BUILDING.txt
===
RCS file: /home/cvs/jakarta-tomcat-5/BUILDING.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- BUILDING.txt 31 Jul 2002 03:12:34 - 1.6
+++ BUILDING.txt 31 Jul 2002 17:27:01 - 1.7
@@ -201,7 +201,7 @@
(8) Download and Install the Commons Digester Binary Distribution
-* Download a binary distribution (nightly build 20020731 or later) from:
+* Download a binary distribution (nightly build 20020801 or later) from:
http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester
1.11 +2 -2 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- build.properties.default 31 Jul 2002 03:12:34 - 1.10
+++ build.properties.default 31 Jul 2002 17:27:01 - 1.11
@@ -71,7 +71,7 @@
commons-daemon.loc=jakarta-commons-sandbox/daemon
-# - Commons Digester, version 20020731 or later -
+# - Commons Digester, version 20020801 or later -
commons-digester.home=${base.path}/commons-digester
commons-digester.lib=${commons-digester.home}
commons-digester.jar=${commons-digester.lib}/commons-digester.jar
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: how to do auto update/reload of a class?
On Wed, 31 Jul 2002, Babu Wisor wrote: Date: Wed, 31 Jul 2002 10:15:08 -0700 (PDT) From: Babu Wisor [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: how to do auto update/reload of a class? Hi All, Does anyone have any thoughts as to how to auto re-load the classes, which have been loaded into JVM using Custom Class loader? I tried writing custom class loader and loaded all the classes, but don't know how to re-load the same class, if it has been modified (re-compiled) without shutting down JVM, similar to JSP engine, where if we put updated JSP file, it picks up the new file. Jasper does this by creating a class loader for each page, and throwing away the class loader when the page is recompiled. The JVM doesn't let you do things any other way. Note: I learnt that, we need to recreate new class loader and load all the classes again, but don't know exactly how to apply that technique in the system. Any help is greatly appreciated. My personal advice, after living through (barely :-) getting a class loader that would reload a webapp to work, is to abandon this approach unless you are just doing it for fun and learning how class loading works. You are going to find that the fundamental architecture of Java isn't really oriented towards incremental replacement of classes (although there is a little bit better support in 1.4). Thank you, Babu Craig --- Ian Darwin [EMAIL PROTECTED] wrote: On July 28, 2002 10:32 pm, you wrote: Does anyone know, how to do auto update of classes into the JVM? I tried to write my own custom class loader, and loaded all the classes through it, however if I put new updated class, it won't reload the class again. Have anyone tried this before? Help is very much appreciated. This better asked on an advanced-java list; not tomcat specific. For all the cleverness of Java's dynamic loading mechanism (ClassLoader, Class.forName, newInstance(), etc.), there is no published API for unloading or reloading. They just didn't think of it in time, perhaps. What I think Tomcat and others do is basically to manage the class loader for each Context (which has to be separate from the CL for each other Context for configuration and security reasons anyway) in such a way that you can delete it (un-reference it) and assign a new one and reload the classes for the given Context. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- 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: how to do auto update/reload of a class?
Hello Craig, Thank you, very much for your thought. You mentioned that, Jasper does this by creating a class loader for each page, can you please explain little bit more as to how the system over all works? I mean, how does the jasper creates invidual class loader for each page and make it available to other classes (servlet/another JSP) loaded by other class loader(Servlet/another Jasper), since classes loaded by one class loader is not visible to other class loader. Please, note that i would like to take similar approach in my current project, where it requires auto update of classes in the run time. Note: In the tomcat documentation, I found that these things work with Servlet Context, but no documents are available as to what technique has been used there. Thank you, very much for your time, Babu --- Craig R. McClanahan [EMAIL PROTECTED] wrote: On Wed, 31 Jul 2002, Babu Wisor wrote: Date: Wed, 31 Jul 2002 10:15:08 -0700 (PDT) From: Babu Wisor [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: how to do auto update/reload of a class? Hi All, Does anyone have any thoughts as to how to auto re-load the classes, which have been loaded into JVM using Custom Class loader? I tried writing custom class loader and loaded all the classes, but don't know how to re-load the same class, if it has been modified (re-compiled) without shutting down JVM, similar to JSP engine, where if we put updated JSP file, it picks up the new file. Jasper does this by creating a class loader for each page, and throwing away the class loader when the page is recompiled. The JVM doesn't let you do things any other way. Note: I learnt that, we need to recreate new class loader and load all the classes again, but don't know exactly how to apply that technique in the system. Any help is greatly appreciated. My personal advice, after living through (barely :-) getting a class loader that would reload a webapp to work, is to abandon this approach unless you are just doing it for fun and learning how class loading works. You are going to find that the fundamental architecture of Java isn't really oriented towards incremental replacement of classes (although there is a little bit better support in 1.4). Thank you, Babu Craig --- Ian Darwin [EMAIL PROTECTED] wrote: On July 28, 2002 10:32 pm, you wrote: Does anyone know, how to do auto update of classes into the JVM? I tried to write my own custom class loader, and loaded all the classes through it, however if I put new updated class, it won't reload the class again. Have anyone tried this before? Help is very much appreciated. This better asked on an advanced-java list; not tomcat specific. For all the cleverness of Java's dynamic loading mechanism (ClassLoader, Class.forName, newInstance(), etc.), there is no published API for unloading or reloading. They just didn't think of it in time, perhaps. What I think Tomcat and others do is basically to manage the class loader for each Context (which has to be separate from the CL for each other Context for configuration and security reasons anyway) in such a way that you can delete it (un-reference it) and assign a new one and reload the classes for the given Context. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- 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] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: how to do auto update/reload of a class?
Craig, who controls loading and reloading jasper class loaders? and how is it being managed? I'm also working on a project where I need to auto-reload Java classes at runtime. If you could point me to any kind of documentation, that'd be greatly appreciated. thanks, Adrian --- Craig R. McClanahan [EMAIL PROTECTED] wrote: On Wed, 31 Jul 2002, Babu Wisor wrote: Date: Wed, 31 Jul 2002 10:15:08 -0700 (PDT) From: Babu Wisor [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: how to do auto update/reload of a class? Hi All, Does anyone have any thoughts as to how to auto re-load the classes, which have been loaded into JVM using Custom Class loader? I tried writing custom class loader and loaded all the classes, but don't know how to re-load the same class, if it has been modified (re-compiled) without shutting down JVM, similar to JSP engine, where if we put updated JSP file, it picks up the new file. Jasper does this by creating a class loader for each page, and throwing away the class loader when the page is recompiled. The JVM doesn't let you do things any other way. Note: I learnt that, we need to recreate new class loader and load all the classes again, but don't know exactly how to apply that technique in the system. Any help is greatly appreciated. My personal advice, after living through (barely :-) getting a class loader that would reload a webapp to work, is to abandon this approach unless you are just doing it for fun and learning how class loading works. You are going to find that the fundamental architecture of Java isn't really oriented towards incremental replacement of classes (although there is a little bit better support in 1.4). Thank you, Babu Craig --- Ian Darwin [EMAIL PROTECTED] wrote: On July 28, 2002 10:32 pm, you wrote: Does anyone know, how to do auto update of classes into the JVM? I tried to write my own custom class loader, and loaded all the classes through it, however if I put new updated class, it won't reload the class again. Have anyone tried this before? Help is very much appreciated. This better asked on an advanced-java list; not tomcat specific. For all the cleverness of Java's dynamic loading mechanism (ClassLoader, Class.forName, newInstance(), etc.), there is no published API for unloading or reloading. They just didn't think of it in time, perhaps. What I think Tomcat and others do is basically to manage the class loader for each Context (which has to be separate from the CL for each other Context for configuration and security reasons anyway) in such a way that you can delete it (un-reference it) and assign a new one and reload the classes for the given Context. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- 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] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: how to do auto update/reload of a class?
On Wed, 31 Jul 2002, Babu Wisor wrote: Date: Wed, 31 Jul 2002 11:15:21 -0700 (PDT) From: Babu Wisor [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: how to do auto update/reload of a class? Hello Craig, Thank you, very much for your thought. You mentioned that, Jasper does this by creating a class loader for each page, can you please explain little bit more as to how the system over all works? I mean, how does the jasper creates invidual class loader for each page and make it available to other classes (servlet/another JSP) loaded by other class loader(Servlet/another Jasper), since classes loaded by one class loader is not visible to other class loader. The Tomcat source code is the best place to get the long answer. The short answer: your final sentence above is not quite accurate. Classes loaded by a particular class loader can indeed see the classes loaded from a *parent* class loader -- that's why, for example, your webapp classes can see things from common/lib. The JSP page compiler sets up a class loader whose parent is the webapp class loader. Therefore, the JSP page's generated class can see everything in the webapp, but not the other way around. Please, note that i would like to take similar approach in my current project, where it requires auto update of classes in the run time. Note: In the tomcat documentation, I found that these things work with Servlet Context, but no documents are available as to what technique has been used there. What these things are you talking about? if it's the reload attribute on a Context element in server.xml, you should note that this reloads the entire webapp anytime it detects a change -- not just a single class. Thank you, very much for your time, Babu Craig --- Craig R. McClanahan [EMAIL PROTECTED] wrote: On Wed, 31 Jul 2002, Babu Wisor wrote: Date: Wed, 31 Jul 2002 10:15:08 -0700 (PDT) From: Babu Wisor [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: how to do auto update/reload of a class? Hi All, Does anyone have any thoughts as to how to auto re-load the classes, which have been loaded into JVM using Custom Class loader? I tried writing custom class loader and loaded all the classes, but don't know how to re-load the same class, if it has been modified (re-compiled) without shutting down JVM, similar to JSP engine, where if we put updated JSP file, it picks up the new file. Jasper does this by creating a class loader for each page, and throwing away the class loader when the page is recompiled. The JVM doesn't let you do things any other way. Note: I learnt that, we need to recreate new class loader and load all the classes again, but don't know exactly how to apply that technique in the system. Any help is greatly appreciated. My personal advice, after living through (barely :-) getting a class loader that would reload a webapp to work, is to abandon this approach unless you are just doing it for fun and learning how class loading works. You are going to find that the fundamental architecture of Java isn't really oriented towards incremental replacement of classes (although there is a little bit better support in 1.4). Thank you, Babu Craig --- Ian Darwin [EMAIL PROTECTED] wrote: On July 28, 2002 10:32 pm, you wrote: Does anyone know, how to do auto update of classes into the JVM? I tried to write my own custom class loader, and loaded all the classes through it, however if I put new updated class, it won't reload the class again. Have anyone tried this before? Help is very much appreciated. This better asked on an advanced-java list; not tomcat specific. For all the cleverness of Java's dynamic loading mechanism (ClassLoader, Class.forName, newInstance(), etc.), there is no published API for unloading or reloading. They just didn't think of it in time, perhaps. What I think Tomcat and others do is basically to manage the class loader for each Context (which has to be separate from the CL for each other Context for configuration and security reasons anyway) in such a way that you can delete it (un-reference it) and assign a new one and reload the classes for the given Context. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- To unsubscribe, e-mail:
Re: how to do auto update/reload of a class?
On Wed, 31 Jul 2002, Adrian Prezioso wrote: Date: Wed, 31 Jul 2002 11:36:45 -0700 (PDT) From: Adrian Prezioso [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: how to do auto update/reload of a class? Craig, who controls loading and reloading jasper class loaders? and how is it being managed? I'm also working on a project where I need to auto-reload Java classes at runtime. If you could point me to any kind of documentation, that'd be greatly appreciated. The source code for JspServlet and friends is the best bet for figuring this out. thanks, Adrian Craig --- Craig R. McClanahan [EMAIL PROTECTED] wrote: On Wed, 31 Jul 2002, Babu Wisor wrote: Date: Wed, 31 Jul 2002 10:15:08 -0700 (PDT) From: Babu Wisor [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: how to do auto update/reload of a class? Hi All, Does anyone have any thoughts as to how to auto re-load the classes, which have been loaded into JVM using Custom Class loader? I tried writing custom class loader and loaded all the classes, but don't know how to re-load the same class, if it has been modified (re-compiled) without shutting down JVM, similar to JSP engine, where if we put updated JSP file, it picks up the new file. Jasper does this by creating a class loader for each page, and throwing away the class loader when the page is recompiled. The JVM doesn't let you do things any other way. Note: I learnt that, we need to recreate new class loader and load all the classes again, but don't know exactly how to apply that technique in the system. Any help is greatly appreciated. My personal advice, after living through (barely :-) getting a class loader that would reload a webapp to work, is to abandon this approach unless you are just doing it for fun and learning how class loading works. You are going to find that the fundamental architecture of Java isn't really oriented towards incremental replacement of classes (although there is a little bit better support in 1.4). Thank you, Babu Craig --- Ian Darwin [EMAIL PROTECTED] wrote: On July 28, 2002 10:32 pm, you wrote: Does anyone know, how to do auto update of classes into the JVM? I tried to write my own custom class loader, and loaded all the classes through it, however if I put new updated class, it won't reload the class again. Have anyone tried this before? Help is very much appreciated. This better asked on an advanced-java list; not tomcat specific. For all the cleverness of Java's dynamic loading mechanism (ClassLoader, Class.forName, newInstance(), etc.), there is no published API for unloading or reloading. They just didn't think of it in time, perhaps. What I think Tomcat and others do is basically to manage the class loader for each Context (which has to be separate from the CL for each other Context for configuration and security reasons anyway) in such a way that you can delete it (un-reference it) and assign a new one and reload the classes for the given Context. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- 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] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- 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]
prob with tomcat3.2.3 to tomcat 4.0
Hi,Everybody, I have a question about migrating tomcat3.2.3 to Tomcat 4.0. I 've written some web apps on Tomcat 3.2.3 + Wind98 + jdk1.3.1_02. How can I migrate my web applications to Tomcat 4.0 + windows XP + J2SE1.4? I've tried it ,but fail, when start tomcat 4.0 , it showed me an error msg: Can't find Include method in jasper.jar runtime library. what's that mean? how to solve the prob? Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServletWrapper.java
kinman 2002/07/31 14:42:28
Modified:jasper2/src/share/org/apache/jasper
JspCompilationContext.java
jasper2/src/share/org/apache/jasper/compiler Compiler.java
Generator.java JspDocumentParser.java Node.java
Parser.java ParserController.java
TagFileProcessor.java TagLibraryInfoImpl.java
Validator.java
jasper2/src/share/org/apache/jasper/resources
messages.properties
jasper2/src/share/org/apache/jasper/servlet
JspServletWrapper.java
Log:
- First cut at triggering compilations of tag files on demand.
Node: Not fully working yet. Implicit tag file library not tested.
Use absolute path for tag file in TLD.
Revision ChangesPath
1.11 +43 -5
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java
Index: JspCompilationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- JspCompilationContext.java25 Jul 2002 22:28:45 - 1.10
+++ JspCompilationContext.java31 Jul 2002 21:42:27 - 1.11
@@ -65,6 +65,8 @@
import java.net.*;
import java.util.Set;
import javax.servlet.ServletContext;
+import javax.servlet.jsp.tagext.TagInfo;
+
import org.apache.jasper.compiler.JspRuntimeContext;
import org.apache.jasper.compiler.JspReader;
import org.apache.jasper.compiler.ServletWriter;
@@ -116,6 +118,9 @@
protected URL [] outUrls = new URL[1];
protected Class servletClass;
+protected boolean isTagFile;
+protected TagInfo tagInfo;
+
// jspURI _must_ be relative to the context
public JspCompilationContext(String jspUri, boolean isErrPage, Options options,
ServletContext context, JspServletWrapper jsw,
@@ -141,6 +146,17 @@
this.rctxt=rctxt;
}
+public JspCompilationContext(String tagfile, TagInfo tagInfo,
+ Options options,
+ ServletContext context, JspServletWrapper jsw,
+ JspRuntimeContext rctxt) {
+
+this(tagfile, false, options, context, jsw, rctxt);
+this.isTagFile = true;
+this.tagInfo = tagInfo;
+return;
+}
+
/* Methods to override */
/** -- Class path and loader -- */
@@ -304,6 +320,14 @@
this.isErrPage = isErrPage;
}
+public boolean isTagFile() {
+ return isTagFile;
+}
+
+public TagInfo getTagInfo() {
+ return tagInfo;
+}
+
/**
* Package name for the generated class.
*/
@@ -351,6 +375,14 @@
return options;
}
+public ServletContext getServletContext() {
+ return context;
+}
+
+public JspRuntimeContext getRuntimeContext() {
+ return rctxt;
+}
+
/**
* Path of the JSP relative to the work directory.
*/
@@ -503,8 +535,14 @@
rctxt.getPermissionCollection(),
rctxt.getCodeSource());
-servletClass = jspLoader.loadClass(
- getServletPackageName() + . + getServletClassName());
+String className;
+if (isTagFile()) {
+className = tagInfo.getTagClassName();
+} else {
+className = getServletPackageName() + . +
+getServletClassName();
+}
+servletClass = jspLoader.loadClass(className);
} catch (FileNotFoundException ex) {
jspCompiler.removeGeneratedFiles();
throw ex;
1.22 +7 -3
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.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- Compiler.java 19 Jul 2002 01:13:46 - 1.21
+++ Compiler.java 31 Jul 2002 21:42:27 - 1.22
@@ -241,6 +241,10 @@
// Collect page info
Collector.collect(this, pageNodes);
+ // Compile (if necessar) and load the tag files referenced in
+ // this compilation unit.
+ TagFileProcessor.loadTagFiles(this, pageNodes);
+
// generate servlet .java file
Generator.generate(writer,
RE: mod_jk, mod_jk2 URI spaces
On Wed, 2002-07-31 at 23:55, Mladen Turk wrote: Now I propose that we make something like _not_ URI space filtering. Meaning that one could be able to serve every .html file through TC except for the /*/some_space/ location. Right now we are checking and hoping that the TC will accept the context, and then we forget that immediately. I propose that we make the map_to_storage two way (If the TC accepts it and then checking if the Apache configuration rejects it). This above sentence is confusing. You probably meant configuration options as a series of include/exclude switches, rsync style. After I read my mail, it doesn't make sense even for me :) For example (what I have in mind) using mod_jk: JkMount /examples/* (This will map /examples URI space and everything belonging to the /examples will be served by the TC). JkNotMount /examples/*.gif JkNotMount /examples/*.jpg (This will map /examples URI space and everything will be served by the TC except the gif and jpg files). I see your point here. You are running a setup where anything not specifically targeted for Apache goes to Tomcat. As long as this doesn't affect current situation (and I don't see how it would) where I can set up that Tomcat only gets what's not specifically targeted for Apache, I'm +1. This would make mod_jk configuration really flexible. Bojan PS. Given 1.2.0 is due for a release when Henri comes back from holidays (in about 2 weeks time), are you planning the patches for this before of after the release? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11208] - form-based authentication failed to use the proper error page
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=11208. 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=11208 form-based authentication failed to use the proper error page --- Additional Comments From [EMAIL PROTECTED] 2002-07-31 22:26 --- I found this only happens when a user submitted the right username and password, but doesn't have the required role. In all the other cases, the user will be bounced back to the error page. I think Tomcat should provide a way to allow developers to display a default error page as long as the user is not authenticated. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler ImplicitTagLibraryInfo.java
luehe 2002/07/31 15:46:27
Modified:jasper2/src/share/org/apache/jasper/compiler
ImplicitTagLibraryInfo.java
Log:
Supply name parameter to TagFileProcessor.parseTagFile()
Revision ChangesPath
1.4 +8 -6
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java
Index: ImplicitTagLibraryInfo.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ImplicitTagLibraryInfo.java 26 Jul 2002 23:21:00 - 1.3
+++ ImplicitTagLibraryInfo.java 31 Jul 2002 22:46:27 - 1.4
@@ -119,9 +119,11 @@
tldFile = path;
break;
} else if (path.endsWith(.tag)) {
- tagVector.addElement(TagFileProcessor.parseTagFile(pc,
-path,
-this));
+ tagVector.addElement(
+TagFileProcessor.parseTagFile(pc,
+ shortname,
+ path,
+ this));
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11352] New: - clientauth=false equivalent to clientauth=true
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=11352. 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=11352 clientauth=false equivalent to clientauth=true Summary: clientauth=false equivalent to clientauth=true Product: Tomcat 3 Version: 3.3.1 Final Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Auth AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Environment: J2SDK1.4, Red Hat Linux 7.3, using Tomcat as the web server (no other web server on the machine). Used both Netscape Communicator 4.79 and Mozilla 0.9.9 with same results. As per jakarta-tomcat-3.3.1/doc/tomcat-ssl-howto.html, I wrote this entry in server.xml and then restarted Tomcat: Http10Connector port=8443 secure=true keystore=/home/davpfg2/jakarta-tomcat-3.3.1/JSSEkeystore keypass=keypass clientauth=false SSLImplementation=org.apache.tomcat.util.net.JSSEImplementation / When I opened https://localhost:8443/index.html in my Netscape browser, I received several certificate dialogs (as expected, and which demonstrate that Tomcat successfully found the keystore) and then I received an error message that stated that localhost had requested client authorization but that I did not have a personal certificate. For what it's worth, Tomcat also complained about the missing client certificate: Using classpath: /home/davpfg2/jakarta-tomcat-3.3.1/bin/../lib/tomcat.jar Using JAVA_HOME: /usr/java/j2sdk1.4.0_01 Using TOMCAT_HOME: /home/davpfg2/jakarta-tomcat-3.3.1 2002-07-30 20:45:29 - SessionIdGenerator: Opening /dev/urandom 2002-07-30 20:45:29 - ServerXmlReader: Config=$TOMCAT_HOME/conf/server.xml 2002-07-30 20:45:29 - PathSetter: home=/home/davpfg2/jakarta-tomcat-3.3.1 2002-07-30 20:45:29 - ContextXmlReader: Context config=$TOMCAT_HOME/conf/apps-127.0.0.1.xml 2002-07-30 20:45:29 - ContextXmlReader: Context config=$TOMCAT_HOME/conf/apps-admin.xml 2002-07-30 20:45:29 - ContextXmlReader: Context config=$TOMCAT_HOME/conf/apps-examples.xml 2002-07-30 20:45:29 - AutoWebApp: Loaded from config: DEFAULT:/admin 2002-07-30 20:45:29 - AutoWebApp: Auto-Adding DEFAULT:/ 2002-07-30 20:45:29 - AutoWebApp: Loaded from config: DEFAULT:/examples 2002-07-30 20:45:29 - AutoWebApp: Auto-Adding DEFAULT:/soap 2002-07-30 20:45:29 - ContextManager: Tomcat configured and in stable state 2002-07-30 20:45:29 - ContextManager: Adding DEFAULT:/admin 2002-07-30 20:45:29 - ContextManager: Adding DEFAULT:/examples 2002-07-30 20:45:29 - ContextManager: Adding DEFAULT:/ROOT 2002-07-30 20:45:29 - ContextManager: Adding DEFAULT:/soap EmbededTomcat: Init time 1603 2002-07-30 20:45:30 - Http10Interceptor: Starting on 8080 2002-07-30 20:45:30 - Http10Interceptor: Starting on 8443 2002-07-30 20:45:30 - Ajp12Interceptor: Starting on 8007 2002-07-30 20:45:30 - Ajp13Interceptor: Starting on 8009 EmbededTomcat: Startup time 680 PoolTcpEndpoint: Handshake failed javax.net.ssl.SSLHandshakeException: javax.net.ssl.SSLProtocolException: handshake alert: no_certificate at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275) at java.io.OutputStream.write(OutputStream.java:58) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275) at org.apache.tomcat.util.net.JSSESocketFactory.handshake(JSSESocketFactory.java:270) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:479) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) ThreadPool: Caught exception executing org.apache.tomcat.util.net.TcpWorkerThread@f4f44a, terminating thread java.lang.NullPointerException at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:498) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) Stop reaper SUPER org.apache.tomcat.util.qlog.LogDaemon@4c4975 Exiting ContextManager: Exiting Workaround: I double-checked the manual and found that the default is clientauth=false, so I simply removed the clientauth line from server.xml and restarted Tomcat. When I tried the URL again, my browser successfully displayed index.html. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail:
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
luehe 2002/07/31 16:04:47 Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java Log: Added note that JSP 2.0 spec still needs to clarify what the variable name for a dynamic attribute looks like Revision ChangesPath 1.52 +5 -3 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java Index: Generator.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v retrieving revision 1.51 retrieving revision 1.52 diff -u -r1.51 -r1.52 --- Generator.java31 Jul 2002 21:42:27 - 1.51 +++ Generator.java31 Jul 2002 23:04:47 - 1.52 @@ -2907,6 +2907,8 @@ out.pushIndent(); out.printil(if (uri != null)); out.pushIndent(); + // XXX Specification still needs to clarify what the variable name + // looks like. Assume uri_localName for now. out.printil(dynamicAttrs.put(uri + \_\ + localName, value);); out.popIndent(); out.printil(else); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] jakarta-servletapi-5
The attached archive contains three files that should be added to jakarta-servletapi-5 to enable parsing of DDs and TLDs without needing to fetch these schemas from their global URL each time. Contains: src/share/dtd/xml.xsd src/share/dtd/XMLSchema.dtd src/share/dtd/datatypes.dtd Please let me know if there are any questions or concerns. -- Mark Roth, Java Software JSP 2.0 Specification co-lead Sun Microsystems, Inc. jakarta-servletapi-5-localschemas-patch.tar Description: Unix tar archive -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler ImplicitTagLibraryInfo.java TagFileProcessor.java
luehe 2002/07/31 16:45:50
Modified:jasper2/src/share/org/apache/jasper/compiler
ImplicitTagLibraryInfo.java TagFileProcessor.java
Log:
Modified implicit taglibrary generator to populate new tagFiles
field in TagLibraryInfo
Revision ChangesPath
1.5 +22 -14
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java
Index: ImplicitTagLibraryInfo.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ImplicitTagLibraryInfo.java 31 Jul 2002 22:46:27 - 1.4
+++ ImplicitTagLibraryInfo.java 31 Jul 2002 23:45:50 - 1.5
@@ -63,6 +63,7 @@
import java.util.*;
import javax.servlet.jsp.tagext.TagLibraryInfo;
import javax.servlet.jsp.tagext.TagInfo;
+import javax.servlet.jsp.tagext.TagFileInfo;
import org.apache.jasper.JspCompilationContext;
import org.apache.jasper.JasperException;
@@ -101,7 +102,8 @@
err.jspError(jsp.error.invalid.tagdir, tagdir);
}
- // Determine the value of the short-name element
+ // Determine the value of the short-name subelement of the
+ // imaginary taglib element
if (tagdir.equals(WEB_INF_TAGS)) {
shortname = TAGS_SHORTNAME;
} else {
@@ -111,24 +113,30 @@
Set dirList = ctxt.getResourcePaths(tagdir);
if (dirList != null) {
- Vector tagVector = new Vector();
+ Vector vec = new Vector();
Iterator it = dirList.iterator();
while (it.hasNext()) {
String path = (String) it.next();
- if (path.endsWith(.tld)) {
+ if (path.endsWith(TLD_SUFFIX)) {
tldFile = path;
break;
- } else if (path.endsWith(.tag)) {
- tagVector.addElement(
-TagFileProcessor.parseTagFile(pc,
- shortname,
- path,
- this));
+ } else if (path.endsWith(TAG_FILE_SUFFIX)) {
+ // use the filename of the tag file, without the .tag
+ // extension, as the name subelement of the imaginary
+ // tag-file element
+ String tagName = path.substring(path.lastIndexOf(/) + 1);
+ tagName = tagName.substring(0,
+ tagName.lastIndexOf(TAG_FILE_SUFFIX));
+ TagInfo tagInfo = TagFileProcessor.parseTagFile(pc,
+ tagName,
+ path,
+ this);
+ vec.addElement(new TagFileInfo(tagName, path, tagInfo));
}
}
- tags = new TagInfo[tagVector.size()];
- tagVector.copyInto (this.tags);
+ this.tagFiles = new TagFileInfo[vec.size()];
+ vec.copyInto(this.tagFiles);
}
}
1.6 +6 -6
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java
Index: TagFileProcessor.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TagFileProcessor.java 31 Jul 2002 21:42:27 - 1.5
+++ TagFileProcessor.java 31 Jul 2002 23:45:50 - 1.6
@@ -311,8 +311,9 @@
* handler that it represents is referenced. The tag file is not compiled
* here.
* @param pc the current ParserController used in this compilation
- * @param tagile the path for the tagfile
- * @param tagLibInfo the TaglibraryInfo object associated with this TagInfo
+ * @param name the tag name as specified in the TLD
+ * @param tagfile the path for the tagfile
+ * @param tagLibInfo the TagLibraryInfo object associated with this TagInfo
* @return a TagInfo object assembled from the directives in the tag file.
*/
public static TagInfo parseTagFile(ParserController pc,
@@ -321,7 +322,6 @@
TagLibraryInfo tagLibInfo)
throws JasperException {
-
Node.Nodes page = null;
try {
page = pc.parse(tagfile);
@@ -342,7 +342,7 @@
* Compiles and loads a tagfile.
cvs commit: jakarta-servletapi-5/src/share/javax/servlet ServletRequestAttributeEvent.java ServletRequestAttributeListener.java ServletRequestEvent.java ServletRequestListener.java
kinman 2002/07/31 16:58:11
Added: src/share/javax/servlet ServletRequestAttributeEvent.java
ServletRequestAttributeListener.java
ServletRequestEvent.java
ServletRequestListener.java
Log:
- Justyna Horwat supplied this patch.
adds support for Servlet 2.4 servlet request events.
Revision ChangesPath
1.1
jakarta-servletapi-5/src/share/javax/servlet/ServletRequestAttributeEvent.java
Index: ServletRequestAttributeEvent.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*
*
* This source code implements specifications defined by the Java
* Community Process. In order to remain compliant with the specification
* DO NOT add / change / or delete method signatures!
*/
package javax.servlet;
/**
* This is the event class for notifications about changes to the
* attributes of the servlet request of a web application.
* @see ServletRequestAttributeListener
* @sincev 2.4
*/
public class ServletRequestAttributeEvent extends ServletRequestEvent {
private String name;
private Object value;
/** Construct a ServletRequestAttributeEvent from the given context for the
* given attribute name and attribute value.
*
* @param sc - the ServletContext that is sending the event.
* @param request - the ServletRequest that is sending the event.
* @param name - the name of the request attribute.
* @param value - the value of the request attribute.
*/
public ServletRequestAttributeEvent(ServletContext sc, ServletRequest request,
String name, Object value) {
super(sc, request);
this.name = name;
this.value = value;
}
/**
* Return the name of the attribute that changed on the ServletRequest.
*
* @return String - the name of the changed request attribute.
*/
public String getName() {
return this.name;
}
/**
* Returns the value of the attribute that has been added removed or
* replaced. If the attribute was
cvs commit: jakarta-servletapi-5/src/share/javax/servlet/http HttpServletResponse.java
kinman 2002/07/31 17:05:58 Modified:src/share/javax/servlet/http HttpServletResponse.java Log: - Patch supplied by Bob Herrmann. The 2.4 Servlet spec adds a new constant. See section 15.1.5 in the June 24th public draft. Revision ChangesPath 1.2 +13 -0 jakarta-servletapi-5/src/share/javax/servlet/http/HttpServletResponse.java Index: HttpServletResponse.java === RCS file: /home/cvs/jakarta-servletapi-5/src/share/javax/servlet/http/HttpServletResponse.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- HttpServletResponse.java 16 Jul 2002 16:38:41 - 1.1 +++ HttpServletResponse.java 1 Aug 2002 00:05:58 - 1.2 @@ -445,9 +445,22 @@ * Status code (302) indicating that the resource has temporarily * moved to another location, but that future references should * still use the original URI to access the resource. + * + * This definition is being retained for backwards compatibility. + * SC_FOUND is now the preferred definition. */ public static final int SC_MOVED_TEMPORARILY = 302; + +/** +* Status code (302) indicating that the resource reside +* temporarily under a different URI. Since the redirection might +* be altered on occasion, the client should continue to use the +* Request-URI for future requests.(HTTP/1.1) To represent the +* status code (302), it is recommended to use this variable. +*/ + +public static final int SC_FOUND = 302; /** * Status code (303) indicating that the response to the request -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-servletapi-5/src/share/dtd XMLSchema.dtd datatypes.dtd xml.xsd
kinman 2002/07/31 17:12:24 Added: src/share/dtd XMLSchema.dtd datatypes.dtd xml.xsd Log: - Patfh supplied by Mark Roth. three files should be added to enable parsing of DDs and TLDs without needing to fetch these schemas from their global URL each time: src/share/dtd/xml.xsd src/share/dtd/XMLSchema.dtd src/share/dtd/datatypes.dtd Revision ChangesPath 1.1 jakarta-servletapi-5/src/share/dtd/XMLSchema.dtd Index: XMLSchema.dtd === !-- DTD for XML Schemas: Part 1: Structures Public Identifier: -//W3C//DTD XMLSCHEMA 200102//EN Official Location: http://www.w3.org/2001/XMLSchema.dtd -- !-- $Id: XMLSchema.dtd,v 1.1 2002/08/01 00:12:24 kinman Exp $ -- !-- Note this DTD is NOT normative, or even definitive. -- !--d-- !-- prose copy in the structures REC is the definitive version --!--d-- !-- (which shouldn't differ from this one except for this -- !--d-- !-- comment and entity expansions, but just in case) -- !--d-- !-- With the exception of cases with multiple namespace prefixes for the XML Schema namespace, any XML document which is not valid per this DTD given redefinitions in its internal subset of the 'p' and 's' parameter entities below appropriate to its namespace declaration of the XML Schema namespace is almost certainly not a valid schema. -- !-- The simpleType element and its constituent parts are defined in XML Schema: Part 2: Datatypes -- !ENTITY % xs-datatypes PUBLIC 'datatypes' 'datatypes.dtd' !ENTITY % p 'xs:' !-- can be overriden in the internal subset of a schema document to establish a different namespace prefix -- !ENTITY % s ':xs' !-- if %p is defined (e.g. as foo:) then you must also define %s as the suffix for the appropriate namespace declaration (e.g. :foo) -- !ENTITY % nds 'xmlns%s;' !-- Define all the element names, with optional prefix -- !ENTITY % schema %p;schema !ENTITY % complexType %p;complexType !ENTITY % complexContent %p;complexContent !ENTITY % simpleContent %p;simpleContent !ENTITY % extension %p;extension !ENTITY % element %p;element !ENTITY % unique %p;unique !ENTITY % key %p;key !ENTITY % keyref %p;keyref !ENTITY % selector %p;selector !ENTITY % field %p;field !ENTITY % group %p;group !ENTITY % all %p;all !ENTITY % choice %p;choice !ENTITY % sequence %p;sequence !ENTITY % any %p;any !ENTITY % anyAttribute %p;anyAttribute !ENTITY % attribute %p;attribute !ENTITY % attributeGroup %p;attributeGroup !ENTITY % include %p;include !ENTITY % import %p;import !ENTITY % redefine %p;redefine !ENTITY % notation %p;notation !-- annotation elements -- !ENTITY % annotation %p;annotation !ENTITY % appinfo %p;appinfo !ENTITY % documentation %p;documentation !-- Customisation entities for the ATTLIST of each element type. Define one of these if your schema takes advantage of the anyAttribute='##other' in the schema for schemas -- !ENTITY % schemaAttrs '' !ENTITY % complexTypeAttrs '' !ENTITY % complexContentAttrs '' !ENTITY % simpleContentAttrs '' !ENTITY % extensionAttrs '' !ENTITY % elementAttrs '' !ENTITY % groupAttrs '' !ENTITY % allAttrs '' !ENTITY % choiceAttrs '' !ENTITY % sequenceAttrs '' !ENTITY % anyAttrs '' !ENTITY % anyAttributeAttrs '' !ENTITY % attributeAttrs '' !ENTITY % attributeGroupAttrs '' !ENTITY % uniqueAttrs '' !ENTITY % keyAttrs '' !ENTITY % keyrefAttrs '' !ENTITY % selectorAttrs '' !ENTITY % fieldAttrs '' !ENTITY % includeAttrs '' !ENTITY % importAttrs '' !ENTITY % redefineAttrs '' !ENTITY % notationAttrs '' !ENTITY % annotationAttrs '' !ENTITY % appinfoAttrs '' !ENTITY % documentationAttrs '' !ENTITY % complexDerivationSet CDATA !-- #all or space-separated list drawn from derivationChoice -- !ENTITY % blockSet CDATA !-- #all or space-separated list drawn from derivationChoice + 'substitution' -- !ENTITY % mgs '%all; | %choice; | %sequence;' !ENTITY % cs '%choice; | %sequence;' !ENTITY % formValues '(qualified|unqualified)' !ENTITY % attrDecls'((%attribute;| %attributeGroup;)*,(%anyAttribute;)?)' !ENTITY % particleAndAttrs '((%mgs; | %group;)?, %attrDecls;)' !-- This is used in part2 -- !ENTITY % restriction1 '((%mgs; | %group;)?)' %xs-datatypes; !-- the duplication below is to produce an unambiguous content model which allows annotation everywhere -- !ELEMENT %schema; ((%include; | %import; | %redefine; | %annotation;)*, ((%simpleType; | %complexType; | %element; | %attribute; | %attributeGroup; |
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Constants.java ContextConfig.java
amyroh 2002/07/31 17:21:30
Modified:catalina/src/share/org/apache/catalina/startup
Constants.java ContextConfig.java
Log:
Add support for Web App Deployment Descriptor that uses XML Schema (Servlet 2.4)
Submitted by Jeanfrancois Arcand.
Revision ChangesPath
1.2 +30 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Constants.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Constants.java18 Jul 2002 16:47:48 - 1.1
+++ Constants.java1 Aug 2002 00:21:30 - 1.2
@@ -69,6 +69,7 @@
* String constants for the startup package.
*
* @author Craig R. McClanahan
+ * @author Jean-Francois Arcand
* @version $Revision$ $Date$
*/
@@ -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 =
@@ -102,5 +108,25 @@
public static final String WebDtdResourcePath_23 =
// conf/web_23.dtd;
/javax/servlet/resources/web-app_2_3.dtd;
+
+public static final String WebSchemaPubliId_24 =
+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;
+public static final String J2eeSchemaResourcePath_14 =
+/javax/servlet/resources/j2ee_1_4.xsd;
+
+public static final String W3cSchemaPublicId_10 =
+xml.xsd;
+public static final String W3cSchemaResourcePath_10 =
+/javax/servlet/resources/xml.xsd;
+
+public static final String JspSchemaPublicId_20 =
+jsp_2_0.xsd;
+public static final String JspSchemaResourcePath_20 =
+/javax/servlet/resources/jsp_2_0.xsd;
}
1.3 +63 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
Index: ContextConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ContextConfig.java30 Jul 2002 03:58:27 - 1.2
+++ ContextConfig.java1 Aug 2002 00:21:30 - 1.3
@@ -133,6 +133,7 @@
* of that Context, and the associated defined servlets.
*
* @author Craig R. McClanahan
+ * @author Jean-Francois Arcand
* @version $Revision$ $Date$
*/
@@ -483,6 +484,34 @@
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());
+}
+
+// Add local copy of Servlet 2.4 XML Schema instance.
+url = ContextConfig.class.getResource(Constants.J2eeSchemaResourcePath_14);
+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());
+
+url = ContextConfig.class.getResource(Constants.W3cSchemaResourcePath_10);
+tldDigester.register(Constants.W3cSchemaPublicId_10,
+ url.toString());
+
+url = ContextConfig.class.getResource(Constants.TldSchemaResourcePath_20);
+tldDigester.register(Constants.TldSchemaPublicId_20,
+ url.toString());
+
tldDigester.addRuleSet(new TldRuleSet());
return (tldDigester);
@@ -504,6 +533,35 @@
url =
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
luehe 2002/07/31 17:32:29
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
fixed some compilation errors in generated tag handler file
Revision ChangesPath
1.53 +16 -11
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- Generator.java31 Jul 2002 23:04:47 - 1.52
+++ Generator.java1 Aug 2002 00:32:29 - 1.53
@@ -1815,13 +1815,13 @@
out.print(name);
out.print(, jspContext.getAttribute();
out.print(name);
- out.println(););
+ out.println()););
} else {
String getter =
toGetterMethod(tagVars[i].getNameFromAttribute());
out.print(getter);
out.print(, jspContext.getAttribute();
out.print(getter);
- out.println(););
+ out.println()););
}
}
}
@@ -2757,7 +2757,8 @@
out.print( extends javax.servlet.jsp.tagext.SimpleTagSupport);
if (tagInfo.hasDynamicAttributes())
out.print( implements javax.servlet.jsp.tagext.DynamicAttributes);
- out.print( {);
+ out.println( {);
+ out.println();
out.pushIndent();
// Class body begins here
@@ -2767,14 +2768,14 @@
if (tagInfo.hasDynamicAttributes())
generateSetDynamicAttribute();
- out.printil(public int doTag() throws JspException {);
+ out.printil(public int doTag() throws javax.servlet.jsp.JspException {);
out.pushIndent();
// Declare parameter map for fragment/body invocation
- out.println(java.util.Map params = null;);
+ out.printil(java.util.Map params = null;);
// Declare writer used for storing result of fragment/body invocation
// if 'varReader' attribute is specified
- out.println(java.io.Writer sout = null;);
+ out.printil(java.io.Writer sout = null;);
out.printil(javax.servlet.jsp.JspWriter out = jspContext.getOut(););
out.printil(jspContext.pushPageScope(););
@@ -2820,6 +2821,7 @@
out.print(attrInfos[i].getName());
out.println(;);
}
+ out.println();
}
// Declare fragment attributes
@@ -2829,6 +2831,7 @@
out.print(fragAttrInfos[i].getName());
out.println(;);
}
+ out.println();
}
// Define getter and setter methods for normal attributes
@@ -2860,6 +2863,7 @@
out.println(;);
out.popIndent();
out.printil(});
+ out.println();
}
}
@@ -2892,6 +2896,7 @@
out.println(;);
out.popIndent();
out.printil(});
+ out.println();
}
}
}
@@ -2931,7 +2936,7 @@
if (attrInfos != null) {
for (int i=0; iattrInfos.length; i++) {
String attrName = attrInfos[i].getName();
- out.printin(this.jspContext.setAttribute(\);
+ out.printin(jspContext.setAttribute(\);
out.print(attrName);
out.print(\, );
out.print(toGetterMethod(attrName));
@@ -2945,7 +2950,7 @@
if (fragAttrInfos != null) {
for (int i=0; ifragAttrInfos.length; i++) {
String attrName = fragAttrInfos[i].getName();
- out.printin(this.jspContext.setAttribute(\);
+ out.printin(jspContext.setAttribute(\);
out.print(attrName);
out.print(\, );
out.print(toGetterMethod(attrName));
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Performace: Tomcat 4.0.x vs. Tomcat 4.1.x
Is there a large performance gain from Tomcat 4.0.x to Tomcat 4.1.x? Also are there performance gains from JVM 1.3 to 1.4 as well? Thanks, Jason Vasquez
[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]
New coyote branch
I looked in jakarta-tomcat-connectors and it doesn't look like jakarta-tomcat-connectors has been branched yet. I checked the archives and saw the vote results where it was decided that the HEAD of jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would be branched. I'd like to request that this branch be created. Remy? The reason I ask is that I'm working on a servlet 2.4 servlet request events implementation which involves modifying CoyoteRequest.java. Thanks! Justy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardHostDeployer.java
amyroh 2002/07/31 18:40:49
Modified:catalina/src/share/org/apache/catalina/core
StandardHostDeployer.java
Log:
Minor change that fixes a bug when an application is undeployed (removed),
ContatinerEvent with the value of REMOVE_EVENT is fired.
Submitted by Jeanfrancois Arcand.
Revision ChangesPath
1.2 +5 -4
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.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- StandardHostDeployer.java 18 Jul 2002 16:48:05 - 1.1
+++ StandardHostDeployer.java 1 Aug 2002 01:40:49 - 1.2
@@ -418,6 +418,7 @@
host.log(sm.getString(standardHost.removing, contextPath));
try {
host.removeChild(context);
+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]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardHostDeployer.java
amyroh 2002/07/31 18:41:43
Modified:catalina/src/share/org/apache/catalina/core
StandardHostDeployer.java
Log:
Minor change that fixes a bug when an application is undeployed (removed),
ContatinerEvent with the value of REMOVE_EVENT is fired.
Submitted by Jeanfrancois Arcand.
Revision ChangesPath
1.10 +5 -4
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.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- StandardHostDeployer.java 9 Apr 2002 23:48:21 - 1.9
+++ StandardHostDeployer.java 1 Aug 2002 01:41:43 - 1.10
@@ -418,6 +418,7 @@
host.log(sm.getString(standardHost.removing, contextPath));
try {
host.removeChild(context);
+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]
Re: New coyote branch
I believe remmy is on vacation and is moving to france :) I guess someone else will have to do it. peter Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it doesn't look like jakarta-tomcat-connectors has been branched yet. I checked the archives and saw the vote results where it was decided that the HEAD of jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would be branched. I'd like to request that this branch be created. Remy? The reason I ask is that I'm working on a servlet 2.4 servlet request events implementation which involves modifying CoyoteRequest.java. Thanks! Justy -- To unsubscribe, e-mail: For additional commands, e-mail: - Do You Yahoo!? Yahoo! Health - Feel better, live better
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
luehe 2002/07/31 19:12:06
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
more compilation error fixes for generated tag handler files
Revision ChangesPath
1.54 +25 -25
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- Generator.java1 Aug 2002 00:32:29 - 1.53
+++ Generator.java1 Aug 2002 02:12:05 - 1.54
@@ -1736,7 +1736,7 @@
public void visit(Node.ParamAction n) throws JasperException {
out.printin(params.put();
- out.print(n.getAttributeValue(name));
+ out.print(quote(n.getAttributeValue(name)));
out.print(, );
out.print(attributeValue(n.getValue(), false,
String.class, null));
@@ -1765,9 +1765,9 @@
// Store varReader in appropriate scope
if (varReader != null) {
String scopeName = n.getAttributeValue(scope);
- out.printin(jspContext.setAttribute(\);
- out.print(varReader);
- out.print(\, new java.io.StringReader(sout.toString()));
+ out.printin(getJspContext().setAttribute();
+ out.print(quote(varReader));
+ out.print(, new java.io.StringReader(sout.toString()));
if (scopeName != null) {
out.print(, );
out.print(getScopeConstant(scopeName));
@@ -1785,7 +1785,7 @@
public void visit(Node.ParamAction n) throws JasperException {
out.printin(params.put();
- out.print(n.getAttributeValue(name));
+ out.print(quote(n.getAttributeValue(name)));
out.print(, );
out.print(attributeValue(n.getValue(), false,
String.class, null));
@@ -1812,14 +1812,14 @@
out.printin(params.put();
String name = tagVars[i].getNameGiven();
if (name != null) {
- out.print(name);
- out.print(, jspContext.getAttribute();
- out.print(name);
+ out.print(quote(name));
+ out.print(, getJspContext().getAttribute();
+ out.print(quote(name));
out.println()););
} else {
String getter =
toGetterMethod(tagVars[i].getNameFromAttribute());
out.print(getter);
- out.print(, jspContext.getAttribute();
+ out.print(, getJspContext().getAttribute();
out.print(getter);
out.println()););
}
@@ -1838,9 +1838,9 @@
// Store varReader in appropriate scope
if (varReader != null) {
String scopeName = n.getAttributeValue(scope);
- out.printin(jspContext.setAttribute(\);
- out.print(varReader);
- out.print(\, new java.io.StringReader(sout.toString()));
+ out.printin(getJspContext().setAttribute();
+ out.print(quote(varReader));
+ out.print(, new java.io.StringReader(sout.toString()));
if (scopeName != null) {
out.print(, );
out.print(getScopeConstant(scopeName));
@@ -2777,8 +2777,8 @@
// if 'varReader' attribute is specified
out.printil(java.io.Writer sout = null;);
- out.printil(javax.servlet.jsp.JspWriter out = jspContext.getOut(););
- out.printil(jspContext.pushPageScope(););
+ out.printil(javax.servlet.jsp.JspWriter out = getJspContext().getOut(););
+ out.printil(getJspContext().pushPageScope(null););
generatePageScopedVariables(tagInfo);
out.printil(try {);
out.pushIndent();
@@ -2788,7 +2788,7 @@
out.popIndent();
out.printil(} finally {);
out.pushIndent();
-out.printil(jspContext.popPageScope(););
+out.printil(getJspContext().popPageScope(););
out.popIndent();
out.printil(});
out.println();
@@ -2936,9 +2936,9 @@
if (attrInfos != null) {
for (int i=0; iattrInfos.length; i++) {
String attrName = attrInfos[i].getName();
- out.printin(jspContext.setAttribute(\);
- out.print(attrName);
- out.print(\, );
+
Re: webapp/apr cvs tags?
Neil, I will try tonight if I encounter the same problem. BTW, if you can choose, why not move to httpd 2.0? At least Pier and me support it! ;-) Punky Neil Cronin wrote: I'm trying to build mod_webapp for apache 1.3.26. I grabbed webapp and apr from cvs.apache.org. it seems to build fine: # ./configure --with-apr=../apr/ --with-apxs (configure output) # make (make output) Coonfiguration details: module version: mod_webapp/1.2.0-dev httpd version: Apache/1.3.26 (Unix) host machine/os: i686-pc-linux-gnu cration date:Tue Jul 30 04:58:30 PDT 2002 All done... # cp apache-1.3/mod_webapp.so /etc/apache/modules # /usr/sbin/apache Syntax error on line 63 of /etc/apache/conf/apache.conf: Cannot load /etc/apache/modules/mod_webapp.so into server: /etc/apache/modules/mod_webapp.so: undefined symbol: apr_thread_mutex_lock I've tried mod_webapp 1.0.1 with similar results. is this a known issue? is there a 1.1 branch of webapp that I can try? or another version of apr? thanks, neil -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] jakarta-servletapi-5
Please apply the attached patch. It adds all of the new *.xsd files to
the servlet.jar.
Also, please cvs remove the following file as it does not appear to be used:
src/share/dtd/web-app_2_3.dtd.backup
Thanks,
Patrick
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-servletapi-5/build.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 build.xml
--- build.xml 16 Jul 2002 16:38:40 - 1.1.1.1
+++ build.xml 1 Aug 2002 04:24:42 -
@@ -71,16 +71,21 @@
!-- Servlet resources --
copy todir=${servletapi.build}/classes/javax/servlet/resources
-fileset dir=src/share/dtd
- include name=web-app*.dtd/
+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
!-- JSP resources --
copy todir=${servletapi.build}/classes/javax/servlet/jsp/resources
fileset dir=src/share/dtd
- include name=web-jsptaglibrary*.dtd/
- include name=jspxml.*/
+ include name=jsp*.dtd/
+ include name=jsp*.xsd/
+ include name=web-jsp*.dtd/
+ include name=web-jsp*.xsd/
/fileset
/copy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk, mod_jk2 URI spaces
-Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 12:00 AM To: Tomcat Dev List Subject: RE: mod_jk, mod_jk2 URI spaces This above sentence is confusing. You probably meant configuration options as a series of include/exclude switches, rsync style. Yes something like that. This will allow to serve the compiled applications and still deliver the static context from those locations, overlaying Apache URI space (if set) over already resolved TC uri space. Well, at least the configuration will be IMHO easier. PS. Given 1.2.0 is due for a release when Henri comes back from holidays (in about 2 weeks time), are you planning the patches for this before of after the release? After 1.2.0, If I figure out how to do that cross-server. I'll make that for jk2 first, I hope :). MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: webapp/apr cvs tags?
Punky Tse [EMAIL PROTECTED] wrote: Neil, I will try tonight if I encounter the same problem. BTW, if you can choose, why not move to httpd 2.0? At least Pier and me support it! ;-) That's for sure! :) Apache 2.0 rocks :) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Constants.java ContextConfig.java
patrickl2002/07/31 21:53:03
Modified:catalina/src/share/org/apache/catalina/startup
Constants.java ContextConfig.java
Log:
Correct resource locations to match patch to jakarta-servletapi-5 build
Revision ChangesPath
1.3 +7 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Constants.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Constants.java1 Aug 2002 00:21:30 - 1.2
+++ Constants.java1 Aug 2002 04:53:03 - 1.3
@@ -95,7 +95,7 @@
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;
+/javax/servlet/jsp/resources/web-jsptaglibrary_2_0.xsd;
public static final String WebDtdPublicId_22 =
-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN;
@@ -109,7 +109,7 @@
// conf/web_23.dtd;
/javax/servlet/resources/web-app_2_3.dtd;
-public static final String WebSchemaPubliId_24 =
+public static final String WebSchemaPublicId_24 =
web-app_2_4.xsd;
public static final String WebSchemaResourcePath_24 =
/javax/servlet/resources/web-app_2_4.xsd;
@@ -127,6 +127,6 @@
public static final String JspSchemaPublicId_20 =
jsp_2_0.xsd;
public static final String JspSchemaResourcePath_20 =
-/javax/servlet/resources/jsp_2_0.xsd;
+/javax/servlet/jsp/resources/jsp_2_0.xsd;
}
1.4 +7 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
Index: ContextConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ContextConfig.java1 Aug 2002 00:21:30 - 1.3
+++ ContextConfig.java1 Aug 2002 04:53:03 - 1.4
@@ -535,6 +535,9 @@
url.toString());
url = ContextConfig.class.getResource(Constants.WebSchemaResourcePath_24);
+webDigester.register(Constants.WebSchemaPublicId_24,
+ url.toString());
+
// to support servlet.jar that does not contains the schema
if (url != null){
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaLaunchFilter.java
patrickl2002/07/31 21:59:24
Modified:catalina build.xml
catalina/src/bin shutdown.bat shutdown.sh startup.bat
startup.sh
catalina/src/conf catalina.policy
Added: catalina/src/bin catalina.xml
catalina/src/share/org/apache/catalina/startup
CatalinaLaunchFilter.java
Removed: catalina/src/bin catalina.sh
Log:
Converted the catalina.[sh|bat] scripts to use commons-launcher. Also, since all of
the scripting options in the catalina.[sh|bat] scripts to catalina.xml, the
catalina.[sh|bat] scripts are no longer needed and have been removed.
Revision ChangesPath
1.7 +3 -3 jakarta-tomcat-catalina/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- build.xml 30 Jul 2002 20:03:08 - 1.6
+++ build.xml 1 Aug 2002 04:59:24 - 1.7
@@ -700,6 +700,7 @@
target name=build-static
depends=flags,flags.display,build-prepare,copy-activation.jar,copy-dbcp.jar,copy-jaas.jar,copy-jdbc20ext.jar,copy-jmx.jar,copy-jndi.jar,copy-jsse.jar,copy-jta.jar,copy-ldap.jar,copy-modeler.jar,copy-pool.jar,copy-tyrex.jar,copy-xerces2.jars
!-- Copy the launcher classes --
+copy todir=${catalina.build}/common/lib file=${ant.jar}/
copy todir=${catalina.build}/bin file=${commons-daemon.jar}/
copy todir=${catalina.build}/bin file=${commons-daemon-launcher.jar}/
copy todir=${catalina.build}/bin
file=${commons-daemon-launcher-bootstrap.class}/
@@ -710,7 +711,6 @@
/copy
fixcrlf srcdir=${catalina.build}/bin includes=*.sh eol=lf/
fixcrlf srcdir=${catalina.build}/bin includes=*.bat eol=crlf/
-chmod perm=+x file=${catalina.build}/bin/catalina.sh/
chmod perm=+x file=${catalina.build}/bin/digest.sh/
chmod perm=+x file=${catalina.build}/bin/startup.sh/
chmod perm=+x file=${catalina.build}/bin/shutdown.sh/
@@ -999,7 +999,6 @@
/copy
fixcrlf srcdir=${catalina.deploy}/bin includes=*.sh eol=lf/
fixcrlf srcdir=${catalina.deploy}/bin includes=*.bat eol=crlf/
-chmod perm=+x file=${catalina.deploy}/bin/catalina.sh/
chmod perm=+x file=${catalina.deploy}/bin/digest.sh/
chmod perm=+x file=${catalina.deploy}/bin/startup.sh/
chmod perm=+x file=${catalina.deploy}/bin/shutdown.sh/
@@ -1041,6 +1040,7 @@
fileset dir=${catalina.build}/server/classes
include name=org/apache/catalina/startup/Bootstrap.class /
include name=org/apache/catalina/startup/BootstrapService.class /
+include name=org/apache/catalina/startup/CatalinaLaunchFilter.class /
include name=org/apache/catalina/startup/ClassLoaderFactory.class /
include name=org/apache/catalina/startup/Tool.class /
include name=org/apache/catalina/loader/StandardClassLoader*.class /
@@ -1058,6 +1058,7 @@
exclude name=org/apache/naming/** /
exclude name=org/apache/catalina/startup/Bootstrap.class /
exclude name=org/apache/catalina/startup/BootstrapService.class /
+exclude name=org/apache/catalina/startup/CatalinaLaunchFilter.class /
exclude name=org/apache/catalina/startup/ClassLoaderFactory.class /
exclude name=org/apache/catalina/startup/Tool.class /
exclude name=org/apache/catalina/loader/StandardClassLoader*.class /
@@ -1174,7 +1175,6 @@
/copy
fixcrlf srcdir=${catalina.dist}/bin includes=*.sh eol=lf/
fixcrlf srcdir=${catalina.dist}/bin includes=*.bat eol=crlf/
-chmod perm=+x file=${catalina.dist}/bin/catalina.sh/
chmod perm=+x file=${catalina.dist}/bin/digest.sh/
chmod perm=+x file=${catalina.dist}/bin/startup.sh/
chmod perm=+x file=${catalina.dist}/bin/shutdown.sh/
1.2 +21 -22jakarta-tomcat-catalina/catalina/src/bin/shutdown.bat
Index: shutdown.bat
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/shutdown.bat,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- shutdown.bat 18 Jul 2002 16:48:14 - 1.1
+++ shutdown.bat 1 Aug 2002 04:59:24 - 1.2
@@ -1,33 +1,31 @@
@echo off
if %OS% == Windows_NT setlocal
+
rem ---
-rem Stop script for the CATALINA Server
rem
-rem $Id$
+rem Script for shutting down Catalina using the Launcher
+rem
rem ---
-rem Guess CATALINA_HOME if not defined
-if not %CATALINA_HOME% == goto gotHome
-set CATALINA_HOME=.
-if exist %CATALINA_HOME%\bin\catalina.bat
RE: mod_jk, mod_jk2 URI spaces
Cool! Bojan Quoting Mladen Turk [EMAIL PROTECTED]: -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 12:00 AM To: Tomcat Dev List Subject: RE: mod_jk, mod_jk2 URI spaces This above sentence is confusing. You probably meant configuration options as a series of include/exclude switches, rsync style. Yes something like that. This will allow to serve the compiled applications and still deliver the static context from those locations, overlaying Apache URI space (if set) over already resolved TC uri space. Well, at least the configuration will be IMHO easier. PS. Given 1.2.0 is due for a release when Henri comes back from holidays (in about 2 weeks time), are you planning the patches for this before of after the release? After 1.2.0, If I figure out how to do that cross-server. I'll make that for jk2 first, I hope :). MT. -- 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]
cvs commit: jakarta-tomcat-5 BUILDING.txt build.properties.default build.xml
patrickl2002/07/31 22:52:59
Modified:.BUILDING.txt build.properties.default build.xml
Log:
Updated build instructions, build.properties, and download target to use the latest
Xerces 2 nightly build since it is the official Xerces 2 releases do not support XML
schemas properly. Thanks go to Jean-Francois Arcand for helping find a parser that
handles XML schemas properly.
Revision ChangesPath
1.8 +6 -7 jakarta-tomcat-5/BUILDING.txt
Index: BUILDING.txt
===
RCS file: /home/cvs/jakarta-tomcat-5/BUILDING.txt,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- BUILDING.txt 31 Jul 2002 17:27:01 - 1.7
+++ BUILDING.txt 1 Aug 2002 05:52:59 - 1.8
@@ -84,17 +84,16 @@
* This is optional with JDK 1.3 or later.
-(4) Download and Install the Xerces 2.0.2 or Higher Distribution
+(4) Download and Install the Xerces 2 nightly build July 31, 2002 or Higher
+Distribution
-* Download a binary distribution from:
+* Download the xercesImpl.jar and xmlParserAPIs.jar files from:
- http://xml.apache.org/dist/xerces-j/
+ http://gump.covalent.net/jars/latest/xml-xerces2/
-* Unpack the binary distribution into a convenient location so that the
+* Place the downloaded files in a convenient location so that the
distribution resides in its own directory (conventionally named
xerces-x_y_z).
-
-* This is optional with JDK 1.4 or later.
(5) Download and Install Subproject Source Code
1.12 +7 -5 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- build.properties.default 31 Jul 2002 17:27:01 - 1.11
+++ build.properties.default 1 Aug 2002 05:52:59 - 1.12
@@ -102,13 +102,15 @@
regexp.loc=http://jakarta.apache.org/builds/jakarta-regexp/release/v1.2/jakarta-regexp-1.2.tar.gz
-# - Xerces XML Parser, version 2.0.2 or later -
-# Note: Optional with JDK 1.4+
-xerces.home=${base.path}/xerces-2_0_2
+# - Xerces XML Parser, version 2 nightly build July 31, 2002 or later -
+#xerces.home=${base.path}/xerces-2_0_2
+xerces.home=${base.path}/xerces-2-latest
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/Xerces-J-bin.2.0.2.tar.gz
+#xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.0.2.tar.gz
+xercesImpl.loc=http://gump.covalent.net/jars/latest/xml-xerces2/xercesImpl.jar
+xmlParserAPIs.loc=http://gump.covalent.net/jars/latest/xml-xerces2/xmlParserAPIs.jar
# --
1.14 +18 -1 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- build.xml 31 Jul 2002 03:09:19 - 1.13
+++ build.xml 1 Aug 2002 05:52:59 - 1.14
@@ -517,10 +517,27 @@
param name=destfile value=${regexp.jar}/
/antcall
+!--
+ Can't download a released version of Xerces since they have a XML
+ Schema bug
+--
+!--
antcall target=downloadgz
- !-- xerces2 brings 2 files, test for one of them --
param name=sourcefile value=${xerces.loc}/
param name=destfile value=${xmlParserAPIs.jar}/
+/antcall
+--
+
+!-- latest xerces2 requires download of 2 separate jars --
+antcall target=downloadfile
+ param name=sourcefile value=${xercesImpl.loc}/
+ param name=destfile value=${xercesImpl.jar}/
+ param name=destdir value=${xerces.home}/
+/antcall
+antcall target=downloadfile
+ param name=sourcefile value=${xmlParserAPIs.loc}/
+ param name=destfile value=${xmlParserAPIs.jar}/
+ param name=destdir value=${xerces.home}/
/antcall
antcall target=cvsbuild
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11307] - Deadlock in ClassLoader
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=11307. 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=11307 Deadlock in ClassLoader --- Additional Comments From [EMAIL PROTECTED] 2002-08-01 05:58 --- Could you provide a simple example web application and instructions on how to reproduce this? Also, what JVM are you using? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
