DO NOT REPLY [Bug 14973] - wildcards using mod_jk
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=14973. 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=14973 wildcards using mod_jk --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 08:42 --- Thanks to check with latest release and tell us more : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1/bin/win32/mod_jk-1.3.27.dll -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14973] - wildcards using mod_jk
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=14973. 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=14973 wildcards using mod_jk --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 08:43 --- Oups, you should get the Apache 2.0 dll : mod_jk-2.0.43.dll -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.16a] A feeedback from an Initial Installation on WinNT
Ok. I admit that I have not check the list before I was posting. And I can take your comment on MBean part, but not the deploying part. :-) Thanks for your comments, Pae This is really a tomcat-user question (and, has been covered, ad nausium, on that list :) The short form is that you can either use the Ajp13Connector without MBeans, or you can use the Jk2 CoyoteConnector with MBeans. If you have a serious need for the Ajp13Connector with MBeans, patches are always welcome. - Original Message - From: Pae Choi [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, December 02, 2002 9:42 PM Subject: [4.1.16a] A feeedback from an Initial Installation on WinNT This is a feedback after trying to install v4.1.16a and mod_jk(JK1). And the some parts seem not working as it used be in v4.1.12. The change made in the server.xml as follows: !-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 -- !-- commeted Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=0 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ -- !-- Define an AJP 1.3 Connector on port 8009 -- !-- uncommented -- Connector className=org.apache.ajp.tomcat4.Ajp13Connector port=8009 minProcessors=5 maxProcessors=75 acceptCount=10 debug=0/ !-- -- And the exception dusring the startup is as follows: ServerLifecycleListener: createMBeans: MBeanException java.lang.Exception: ManagedBean is not found with Ajp13Connector at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:224) ... But it did not crashed so that I tested the index.jsp as follows: http://localhost/index.jsp http://localhost:8080/index.jsp https://real-domain/index.jsp https://real-domain:8443/index.jsp All above work as it suppose to be. However, a web app, demowa.war, did not deployed. And the exception is as follows: 2002-12-03 00:21:51 HostConfig[localhost]: Undeploying web application at context path /demowa 2002-12-03 00:21:51 StandardHost[localhost]: Removing web application at context path /demowa 2002-12-03 00:21:51 StandardHost[localhost]: ContainerBase.removeChild: stop: LifecycleException: Container StandardContext[/demowa] has not been started at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3643) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1036) at org.apache.catalina.core.StandardHostDeployer.remove(StandardHostDeployer.ja va:420) at org.apache.catalina.core.StandardHost.remove(StandardHost.java:852) at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:919) at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:899) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:370) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor t.java:166) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1221) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1233) at org.apache.catalina.core.StandardService.stop(StandardService.java:554) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:2224) at org.apache.catalina.startup.Catalina.start(Catalina.java:543) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) Thanks, Pae -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.16] [VOTE] Stability rating
Remy Maucherat wrote: Note: I know many people are away this weekend, so this vote will run until Monday COB (on the west coast), which more or less means Tuesday morning GMT. ballot [ ] Alpha [ ] Beta [ ] Stable (aka GA) /ballot I vote beta. There's 1.5 votes for beta, and 1.5 for stable, so 4.1.16 Alpha will be released as 4.1.16 Beta. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14359] - largefile option has no effect
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=14359. 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=14359 largefile option has no effect [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |High -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jasper Classloader question
I am trying to access the jasper class loader directly. I want to do this so that I can get a jsp class file out of it at runtime vs having to do a jsp:include to call the jsp. I am having a little trouble getting through the jasper code and would like a little direction please. I know that I am going to have to change some classes and this is a temp solution for us but something that is needed. Again any help is great.. Thanks, john -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper DOM API
Hi, I'm also interested in this sort of functionality - I asked a similar question last week. Is it on the roadmap or has any earlier voting process already rejected it as a viable feature? If it hasn't already been rubished as a suggested feature, would I (or Udo) be out of order making an initial proposal/suggestion on how it might be implemented (to get the ball rolling so to speak!!)? If this isn't appropriate - no prob!! Regards, T. From: Udo Walker [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Jasper DOM API Date: Mon, 02 Dec 2002 15:15:23 +0100 Hi, will there be a XML-DOM API in Jasper to access parsed JSP pages? I found an internal structure of Node.Nodes but how can I access it with the API? I want to give the API a JSP filename and get back a DOM structure of that JSP page or an error (line number and error message) if the JSP couldn't be parsed correctly. Is there something planed? With regards, Udo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bug with Logger? (could be shorter...)
With 4.1.12 (4.0.x is ok) I experience a problem with logging. There seems to be some strange buffering. I have a Servlet in my webapp which does some initialisation. It prints progress information to STDOUT and error information (exception.printStackTrace()) to STDERR. I have a System.exit call if something fails. (It is really important for me that *nothing* is running in the case of an initialisation-error). The problem is, that I never see my progress information and no error-messages (if the System.exit part is reached). That makes finding the error *real* hard (it took me several hours yesterday to find that one of my XML-configuration files was not well formatted...). So the question is: Is there some buffering of output? BTW, if everything works fine during init then the progress information is shown *after* everything's done - so not really a progress information. As said above, nothing of that kind happened with 4.0.x. Peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] change jndi auth in tomcat
Hi,
I tried to get a ldap-authentification with domino but noticed that the
current code (I checked tomcat 4.0.6 so if this is obsolete in a newer
version forgive me) checks the given password with the retrieved one. This
doesn't work as domino uses a different hash algorithm.
So I changed the getUserDN method from the JNDIRealm to auth with a bind.
Here's my code:
-
protected String getUserDN(DirContext context,
String username, String credentials)
throws NamingException {
if (debug = 2)
log(getUserDN( + username + ));
if (username == null)
return (null);
if ((userFormat == null) || (userPassword == null))
return (null);
// Retrieve the user password attribute for this user
String dn = userFormat.format(new String[] { username });
if (debug = 3)
log( dn= + dn);
context.addToEnvironment(Context.SECURITY_PRINCIPAL, dn);
context.addToEnvironment(Context.SECURITY_CREDENTIALS, credentials);
if (debug = 3)
log(Doing a lookup);
Object user = context.lookup(dn);
if (user == null)
{
log(Lookup failed);
return (null);
}
return (dn);
}
-
--
Dipl. Inf. Carsten Burghardt
Login Solutions AG
email: [EMAIL PROTECTED]
Tel: 0821/2488-311 Fax: 0821/2488-180
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15002] - Tag files in different directories not belonging to different tag libraries
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=15002. 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=15002 Tag files in different directories not belonging to different tag libraries [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 14:43 --- I tried building the whole of tomcat-5 from scratch on a different machine and got the same error. After investigating it more it seems that the problem is that the tagfile java file is being created in the wrong directory. When I hit the hello world tagfile example the helloWorld.java is in this directory : \Standalone\localhost\jsp-examples\tags when it should be in \Standalone\localhost\jsp-examples\tags\org\apache\jsp\tag\web After copying the java file to this directory and hitting the jsp again it works So to reiterate i get this with a complete fresh checkout of all of tomcat-5. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5Constants.java CoyoteResponse.java
Hi Bill, doesn't seems to work if I only set the locale in recycle. I can add a condition when getting the locale to check if equal to null, then it will work. Is there a reason to not have a default locale? Thanks, -- Jeanfrancois Bill Barker wrote: I'm not really happy with having a default Locale in the o.a.c.Response. I'd like it better if o.a.c.tc5.CoyoteResponse set the default Locale in recycle. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 02, 2002 6:29 PM Subject: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 Constants.java CoyoteResponse.java jfarcand2002/12/02 18:29:14 Modified:coyote/src/java/org/apache/coyote Response.java coyote/src/java/org/apache/coyote/tomcat5 Constants.java CoyoteResponse.java Log: Servlet 2.4 section 5.4 will be modified: A servlet should set the locale and the character encoding of a response. The locale is set using the ServletResponse.setLocale method, and communicated to the client using the Content-Language header. The character encoding can be set explicitly using the ServletResponse methods setCharacterEncoding and setContentType, or implicitly using the ServletResponse.setLocale method, and is communicated to the client using the charset parameter of the Content-Type header. Explicit specifications take precedence over implicit specifications. [...] The character encoding should be specified before the getWriter method of the ServletResponse interface is called; otherwise the default ISO-8859-1 is used. - That means if setContentType is called, then setLocale should do reset the content type. Same for setCharacterEncoding. If getWriter is called, then ignore any call to setContentType, setCharacterEncoding and setLocale. Please review. Revision ChangesPath 1.17 +10 -4 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java Index: Response.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Respon se.java,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- Response.java 9 Nov 2002 17:12:04 - 1.16 +++ Response.java 3 Dec 2002 02:29:14 - 1.17 @@ -91,8 +91,14 @@ // - Instance Variables + + +/** + * Default locale + */ +private static Locale DEFAULT_LOCALE = new Locale(en, US); - + /** * Status code. */ @@ -142,7 +148,7 @@ protected String contentLanguage = null; protected String characterEncoding = Constants.DEFAULT_CHARACTER_ENCODING; protected int contentLength = -1; -private Locale locale = null;//Constants.DEFAULT_LOCALE; +private Locale locale = DEFAULT_LOCALE; /** * Holds request error exception. @@ -311,7 +317,7 @@ // Reset the headers only if this is the main request, // not for included contentType = Constants.DEFAULT_CONTENT_TYPE; -locale = null;//Constants.DEFAULT_LOCALE; +locale = DEFAULT_LOCALE; contentLanguage = null; characterEncoding = Constants.DEFAULT_CHARACTER_ENCODING; contentLength = -1; @@ -525,7 +531,7 @@ contentType = Constants.DEFAULT_CONTENT_TYPE; contentLanguage = null; -locale = null;//Constants.DEFAULT_LOCALE; +locale = DEFAULT_LOCALE; characterEncoding = Constants.DEFAULT_CHARACTER_ENCODING; contentLength = -1; status = 200; 1.4 +1 -2 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/Constant s.java Index: Constants.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat 5/Constants.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- Constants.java 10 Oct 2002 09:45:30 - 1.3 +++ Constants.java 3 Dec 2002 02:29:14 - 1.4 @@ -58,8 +58,6 @@ */ package org.apache.coyote.tomcat5; -import java.util.Locale; - /** * Constants. * @@ -92,5 +90,6 @@ */ protected static final boolean SECURITY = (System.getSecurityManager() != null); + } 1.12 +50 -13 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRe sponse.java Index: CoyoteResponse.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat 5/CoyoteResponse.java,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- CoyoteResponse.java 11 Nov 2002 11:01:04 - 1.11 +++ CoyoteResponse.java 3 Dec 2002
Re: Jasper Classloader question
John Trollinger wrote: I am trying to access the jasper class loader directly. I want to do this so that I can get a jsp class file out of it at runtime vs having to do a jsp:include to call the jsp. I am having a little trouble getting through the jasper code and would like a little direction please. Use jspc, that will generate regular servlets that are loaded in the same loader. Costin I know that I am going to have to change some classes and this is a temp solution for us but something that is needed. Again any help is great.. Thanks, john -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14896] - Pager Tag Library prb under Tomcat 4.1.12
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=14896. 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=14896 Pager Tag Library prb under Tomcat 4.1.12 [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |High -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
getUserPrincipal
Hi all, Why are getUserPrincipal and getRemoteUser returnnig null? I know that they are supposed to return null if the user is not authenticated. What does that mean exactly? I have Tomcat running locally on my machine. What does 'authentication' mean in my context? Thanks RA -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteResponse.java
jfarcand2002/12/03 08:04:02
Modified:coyote/src/java/org/apache/coyote Response.java
coyote/src/java/org/apache/coyote/tomcat5
CoyoteResponse.java
Log:
As Bill's recommends, do not set a default locale in Response directly.
Revision ChangesPath
1.18 +4 -10
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java
Index: Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- Response.java 3 Dec 2002 02:29:14 - 1.17
+++ Response.java 3 Dec 2002 16:04:02 - 1.18
@@ -92,13 +92,7 @@
// - Instance Variables
-
-/**
- * Default locale
- */
-private static Locale DEFAULT_LOCALE = new Locale(en, US);
-
-
+
/**
* Status code.
*/
@@ -148,7 +142,7 @@
protected String contentLanguage = null;
protected String characterEncoding = Constants.DEFAULT_CHARACTER_ENCODING;
protected int contentLength = -1;
-private Locale locale = DEFAULT_LOCALE;
+private Locale locale = null;
/**
* Holds request error exception.
@@ -317,7 +311,7 @@
// Reset the headers only if this is the main request,
// not for included
contentType = Constants.DEFAULT_CONTENT_TYPE;
-locale = DEFAULT_LOCALE;
+locale = null;
contentLanguage = null;
characterEncoding = Constants.DEFAULT_CHARACTER_ENCODING;
contentLength = -1;
@@ -531,7 +525,7 @@
contentType = Constants.DEFAULT_CONTENT_TYPE;
contentLanguage = null;
-locale = DEFAULT_LOCALE;
+locale = null;
characterEncoding = Constants.DEFAULT_CHARACTER_ENCODING;
contentLength = -1;
status = 200;
1.13 +14 -6
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java
Index: CoyoteResponse.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- CoyoteResponse.java 3 Dec 2002 02:29:14 - 1.12
+++ CoyoteResponse.java 3 Dec 2002 16:04:02 - 1.13
@@ -136,7 +136,12 @@
// - Instance Variables
+ /**
+ * Default locale as mandated by the spec.
+ */
+private static Locale DEFAULT_LOCALE = new Locale(en, US);
+
/**
* The date format we will use for creating date headers.
*/
@@ -326,13 +331,13 @@
error = false;
isContentTypeSet = false;
isCharacterEncodingSet = false;
+
cookies.clear();
if ((Constants.SECURITY) (facade != null)) {
facade.clear();
facade = null;
}
-
}
@@ -607,6 +612,10 @@
* Return the Locale assigned to this response.
*/
public Locale getLocale() {
+// Lazy setting. If the local is null, then return the default one.
+if ( coyoteResponse.getLocale() == null){
+coyoteResponse.setLocale(DEFAULT_LOCALE);
+}
return (coyoteResponse.getLocale());
}
@@ -652,7 +661,6 @@
coyoteResponse.reset();
outputBuffer.reset();
-
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5CoyoteResponse.java
[EMAIL PROTECTED] wrote: jfarcand2002/12/03 08:04:02 Modified:coyote/src/java/org/apache/coyote Response.java coyote/src/java/org/apache/coyote/tomcat5 CoyoteResponse.java Log: As Bill's recommends, do not set a default locale in Response directly. That seems like a bad idea. AFAIK, a default locale was set before, and I removed it when I refactored the header handling; I think your patch was fine. OTOH, calling setLocale does not do the same thing (it ends up setting the content-language header, which may not be what you want to do). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5CoyoteResponse.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2002/12/03 08:04:02 Modified:coyote/src/java/org/apache/coyote Response.java coyote/src/java/org/apache/coyote/tomcat5 CoyoteResponse.java Log: As Bill's recommends, do not set a default locale in Response directly. That seems like a bad idea. AFAIK, a default locale was set before, and I removed it when I refactored the header handling; I think your patch was fine. OTOH, calling setLocale does not do the same thing (it ends up setting the content-language header, which may not be what you want to do). That's true. What I'm trying to do is to only set the locale attribute to confrom with the 2.4 spec. I will take a look at the spec 2.2/2.3. I'm surprised there is no local by default. -- Jeanfrancois Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Apache Tomcat 4.1.16 AJP not working
Looking at the netstat on the machine I can see tomcat is bound to the port 8009 and can connect to it with telnet, apache works if I go back to tomcat 4.1.14. From the apache logs: [Tue Dec 03 16:04:22 2002] [jk_connect.c (143)]: jk_open_socket, connect() failed errno = 111 [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (196)]: In jk_endpoint_t::connect_to_tomcat, failed errno = 111 [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (635)]: Error connecting to the Tomcat process. [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (848)]: In jk_endpoint_t::service, send_request failed in send loop 0 As we're using apache 1.3 and can't use warp it's fairly critical to us... should I raise a bug report? -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5CoyoteResponse.java
Jeanfrancois Arcand wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2002/12/03 08:04:02 Modified:coyote/src/java/org/apache/coyote Response.java coyote/src/java/org/apache/coyote/tomcat5 CoyoteResponse.java Log: As Bill's recommends, do not set a default locale in Response directly. That seems like a bad idea. AFAIK, a default locale was set before, and I removed it when I refactored the header handling; I think your patch was fine. OTOH, calling setLocale does not do the same thing (it ends up setting the content-language header, which may not be what you want to do). That's true. What I'm trying to do is to only set the locale attribute to confrom with the 2.4 spec. I will take a look at the spec 2.2/2.3. I'm surprised there is no local by default. I think I made a mistake when I removed the default locale. It was there in version 1.16. I think you should go back to version 1.17. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteResponse.java
jfarcand2002/12/03 08:37:59
Modified:coyote/src/java/org/apache/coyote Response.java
coyote/src/java/org/apache/coyote/tomcat5
CoyoteResponse.java
Log:
Go back and set the locale in Response (required by 2.3 and 2.4). Watchdog is
falling if the getLocale returns null ;-)
Revision ChangesPath
1.19 +9 -3
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java
Index: Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- Response.java 3 Dec 2002 16:04:02 - 1.18
+++ Response.java 3 Dec 2002 16:37:59 - 1.19
@@ -92,6 +92,12 @@
// - Instance Variables
+
+ /**
+ * Default locale as mandated by the spec.
+ */
+private static Locale DEFAULT_LOCALE = new Locale(en, US);
+
/**
* Status code.
@@ -142,7 +148,7 @@
protected String contentLanguage = null;
protected String characterEncoding = Constants.DEFAULT_CHARACTER_ENCODING;
protected int contentLength = -1;
-private Locale locale = null;
+private Locale locale = DEFAULT_LOCALE;
/**
* Holds request error exception.
@@ -311,7 +317,7 @@
// Reset the headers only if this is the main request,
// not for included
contentType = Constants.DEFAULT_CONTENT_TYPE;
-locale = null;
+locale = DEFAULT_LOCALE;
contentLanguage = null;
characterEncoding = Constants.DEFAULT_CHARACTER_ENCODING;
contentLength = -1;
@@ -525,7 +531,7 @@
contentType = Constants.DEFAULT_CONTENT_TYPE;
contentLanguage = null;
-locale = null;
+locale = DEFAULT_LOCALE;
characterEncoding = Constants.DEFAULT_CHARACTER_ENCODING;
contentLength = -1;
status = 200;
1.14 +4 -14
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java
Index: CoyoteResponse.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- CoyoteResponse.java 3 Dec 2002 16:04:02 - 1.13
+++ CoyoteResponse.java 3 Dec 2002 16:37:59 - 1.14
@@ -136,12 +136,6 @@
// - Instance Variables
- /**
- * Default locale as mandated by the spec.
- */
-private static Locale DEFAULT_LOCALE = new Locale(en, US);
-
-
/**
* The date format we will use for creating date headers.
*/
@@ -612,10 +606,6 @@
* Return the Locale assigned to this response.
*/
public Locale getLocale() {
-// Lazy setting. If the local is null, then return the default one.
-if ( coyoteResponse.getLocale() == null){
-coyoteResponse.setLocale(DEFAULT_LOCALE);
-}
return (coyoteResponse.getLocale());
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Apache Tomcat 4.1.16 AJP not working
M wrote: Looking at the netstat on the machine I can see tomcat is bound to the port 8009 and can connect to it with telnet, apache works if I go back to tomcat 4.1.14. From the apache logs: [Tue Dec 03 16:04:22 2002] [jk_connect.c (143)]: jk_open_socket, connect() failed errno = 111 [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (196)]: In jk_endpoint_t::connect_to_tomcat, failed errno = 111 [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (635)]: Error connecting to the Tomcat process. [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (848)]: In jk_endpoint_t::service, send_request failed in send loop 0 As we're using apache 1.3 and can't use warp it's fairly critical to us... should I raise a bug report? Which release of mod_jk ? You should try the 1.2.1 release -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5CoyoteResponse.java
[EMAIL PROTECTED] wrote: jfarcand2002/12/03 08:37:59 Modified:coyote/src/java/org/apache/coyote Response.java coyote/src/java/org/apache/coyote/tomcat5 CoyoteResponse.java Log: Go back and set the locale in Response (required by 2.3 and 2.4). Watchdog is falling if the getLocale returns null ;-) I'm sorry for the trouble, when I did the refactoring of the header handling, I nulled a few fields, and forgot to put that one back to its original value :-( BTW, there's a constant already there (Constants.DEFAULT_LOCALE), although you should update it to en-us. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5.0] Cluster features
Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Remy Maucherat wrote: Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? I could be a full +1, if we could convince them to make JavaGroups BSD/Apache licence. Or use something related with BSD license (see mod_backend) Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [5.0] Cluster features
Hi, In a rush on my way to (yet another ;() meeting, so: - The current cluster API is dead. - JavaGroups is good. - Clustering is important. = Your approach seems reasonable, +1 IMHO. Yoav Shapira Millennium ChemInformatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 11:50 AM To: Tomcat Developers List Subject: [5.0] Cluster features Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5CoyoteResponse.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2002/12/03 08:37:59 Modified:coyote/src/java/org/apache/coyote Response.java coyote/src/java/org/apache/coyote/tomcat5 CoyoteResponse.java Log: Go back and set the locale in Response (required by 2.3 and 2.4). Watchdog is falling if the getLocale returns null ;-) I'm sorry for the trouble, when I did the refactoring of the header handling, I nulled a few fields, and forgot to put that one back to its original value :-( BTW, there's a constant already there (Constants.DEFAULT_LOCALE), although you should update it to en-us. I could'nt find the constant with the last commit (1.1 - 1.4). The import is there but the DEFAULT_LOCALE is not set. I'm experiencing a strange problem when I set the variable in the interface instead of the class. When I put DEFAULT_LOCALE in Constants, getLocale().getCountry() return instead of US (but getLanguage() works fine). I suspect a bug somewhere in the VM (at least in 1.4) If I put the DEFAULT_LOCALE in Response, then getLocale returns US (..very strange). Will leave it like that until I figure out what is not working. Thanks, -- Jeanfrancois Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 bldjk.qcsrc
hgomez 2002/12/03 09:22:37
Modified:jk/native/apache-2.0 bldjk.qcsrc
Log:
iSeries should use teraspace model and use full optimization
Revision ChangesPath
1.5 +57 -0 jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qcsrc
Index: bldjk.qcsrc
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qcsrc,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- bldjk.qcsrc 1 Oct 2002 11:01:30 - 1.4
+++ bldjk.qcsrc 3 Dec 2002 17:22:36 - 1.5
@@ -3,9 +3,12 @@
SRCSTMF('/home/apache/jk/native/apache-2.0/mod_jk.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5') +
TEXT('mod_jk.c')+
+OPTIMIZE(40) +
SYSIFCOPT(*IFSIO) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG )+
+TERASPACE(*YES) +
+STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
@@ -13,10 +16,13 @@
SRCSTMF('/home/apache/jk/native/common/jk_ajp_common.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5') +
TEXT('jk_ajp_common.c') +
+OPTIMIZE(40) +
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG ) +
+TERASPACE(*YES) +
+STGMDL(*TERASPACE)+
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
@@ -24,10 +30,13 @@
SRCSTMF('/home/apache/jk/native/common/jk_ajp12_worker.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5')+
TEXT('jk_ajp12_worker.c') +
+OPTIMIZE(40)+
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG ) +
+TERASPACE(*YES) +
+STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
@@ -35,10 +44,13 @@
SRCSTMF('/home/apache/jk/native/common/jk_ajp13.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5') +
TEXT('jk_ajp13.c') +
+OPTIMIZE(40) +
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG )+
+TERASPACE(*YES) +
+STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
@@ -46,10 +58,13 @@
SRCSTMF('/home/apache/jk/native/common/jk_ajp13_worker.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5')+
TEXT('jk_ajp13_worker.c') +
+OPTIMIZE(40)+
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG ) +
+TERASPACE(*YES) +
+STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
@@ -57,10 +72,13 @@
SRCSTMF('/home/apache/jk/native/common/jk_ajp14.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5') +
TEXT('jk_ajp14.c') +
+OPTIMIZE(40) +
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
Re: [5.0] Cluster features
Henri Gomez wrote: Remy Maucherat wrote: Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? I could be a full +1, if we could convince them to make JavaGroups BSD/Apache licence. Or donate it ;-) One other project I have been working with (Slide) could definitely use a distributed cache. Or use something related with BSD license (see mod_backend) I forgot to mention it, but one missing piece of the puzzle is the HTTP proxy(ies) sitting in front of the cluster. It could be: - Some webserver + JK - Apache 2 + mod_proxy - some yet-to-be-written NIO based proxy (which probably wouldn't need to know anything about HTTP; doing a dumb TCP proxy might be enough) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 bldjk.qclsrc bldjk.qcsrc
hgomez 2002/12/03 09:25:11
Added: jk/native/apache-2.0 bldjk.qclsrc
Removed: jk/native/apache-2.0 bldjk.qcsrc
Log:
Should be called QCLSRC instead of QCSRC
Revision ChangesPath
1.1 jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qclsrc
Index: bldjk.qclsrc
===
PGM
CRTCMOD MODULE(MOD_JK/MOD_JK) +
SRCSTMF('/home/apache/jk/native/apache-2.0/mod_jk.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5') +
TEXT('mod_jk.c')+
OPTIMIZE(40) +
SYSIFCOPT(*IFSIO) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG )+
TERASPACE(*YES) +
STGMDL(*TERASPACE)+
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
CRTCMOD MODULE(MOD_JK/JK_AJP_COM)+
SRCSTMF('/home/apache/jk/native/common/jk_ajp_common.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5') +
TEXT('jk_ajp_common.c') +
OPTIMIZE(40) +
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG ) +
TERASPACE(*YES)+
STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
CRTCMOD MODULE(MOD_JK/JK_AJP12_W) +
SRCSTMF('/home/apache/jk/native/common/jk_ajp12_worker.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5')+
TEXT('jk_ajp12_worker.c') +
OPTIMIZE(40) +
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG ) +
TERASPACE(*YES) +
STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
CRTCMOD MODULE(MOD_JK/JK_AJP13) +
SRCSTMF('/home/apache/jk/native/common/jk_ajp13.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5') +
TEXT('jk_ajp13.c') +
OPTIMIZE(40) +
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG )+
TERASPACE(*YES) +
STGMDL(*TERASPACE)+
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
CRTCMOD MODULE(MOD_JK/JK_AJP13_W) +
SRCSTMF('/home/apache/jk/native/common/jk_ajp13_worker.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5')+
TEXT('jk_ajp13_worker.c') +
OPTIMIZE(40) +
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG ) +
TERASPACE(*YES) +
STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
CRTCMOD MODULE(MOD_JK/JK_AJP14) +
SRCSTMF('/home/apache/jk/native/common/jk_ajp14.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5') +
TEXT('jk_ajp14.c') +
OPTIMIZE(40) +
SYSIFCOPT(*IFSIO) +
Re: Apache Tomcat 4.1.16 AJP not working
Henri Gomez wrote: M wrote: Looking at the netstat on the machine I can see tomcat is bound to the port 8009 and can connect to it with telnet, apache works if I go back to tomcat 4.1.14. From the apache logs: [Tue Dec 03 16:04:22 2002] [jk_connect.c (143)]: jk_open_socket, connect() failed errno = 111 [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (196)]: In jk_endpoint_t::connect_to_tomcat, failed errno = 111 [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (635)]: Error connecting to the Tomcat process. [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (848)]: In jk_endpoint_t::service, send_request failed in send loop 0 As we're using apache 1.3 and can't use warp it's fairly critical to us... should I raise a bug report? Which release of mod_jk ? Not sure, it's the debian default... It says its from tomcat (3.3a-4) in the changelog. You should try the 1.2.1 release Grabbed the one: http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1/bin/linux/i386/mod_jk-1.3-eapi.so.asc Still the same problem. -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 bldjk.qclsrc
hgomez 2002/12/03 09:45:43
Modified:jk/native/apache-2.0 bldjk.qclsrc
Log:
Small cleanup
Revision ChangesPath
1.2 +18 -18jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qclsrc
Index: bldjk.qclsrc
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qclsrc,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- bldjk.qclsrc 3 Dec 2002 17:25:11 - 1.1
+++ bldjk.qclsrc 3 Dec 2002 17:45:42 - 1.2
@@ -6,7 +6,7 @@
OPTIMIZE(40) +
SYSIFCOPT(*IFSIO) +
TGTCCSID(*JOB) +
-OPTION(*LOGMSG )+
+OPTION(*LOGMSG) +
TERASPACE(*YES) +
STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
@@ -20,7 +20,7 @@
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
-OPTION(*LOGMSG ) +
+OPTION(*LOGMSG) +
TERASPACE(*YES) +
STGMDL(*TERASPACE)+
INCDIR('/home/apache/jk/native/common' +
@@ -34,7 +34,7 @@
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
-OPTION(*LOGMSG ) +
+OPTION(*LOGMSG)+
TERASPACE(*YES) +
STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
@@ -48,7 +48,7 @@
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
-OPTION(*LOGMSG )+
+OPTION(*LOGMSG) +
TERASPACE(*YES) +
STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
@@ -62,7 +62,7 @@
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
-OPTION(*LOGMSG ) +
+OPTION(*LOGMSG)+
TERASPACE(*YES) +
STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
@@ -76,7 +76,7 @@
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
-OPTION(*LOGMSG )+
+OPTION(*LOGMSG) +
TERASPACE(*YES) +
STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
@@ -90,7 +90,7 @@
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
-OPTION(*LOGMSG ) +
+OPTION(*LOGMSG)+
TERASPACE(*YES) +
STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
@@ -104,7 +104,7 @@
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
-OPTION(*LOGMSG )+
+OPTION(*LOGMSG) +
TERASPACE(*YES) +
STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
@@ -118,7 +118,7 @@
Re: [5.0] Cluster features
Remy Maucherat wrote: Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I think it is time to stop bloating the base tomcat source and binaries. BTW, it may be a good time to move some of the current features in separate modules as well. ( SSI, WebDAV, etc ). For webdav - I would rather see slide bundled with tomcat and the current code deprecated. I'm not talking ( for now ) about a real module with descriptors or anything, just separate dirs in the CVS and a .jar target that can be included or not. It may be worth reopening the minimal tomcat discussion :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 bldjk.qclsrc
hgomez 2002/12/03 09:50:29
Modified:jk/native/apache-2.0 bldjk.qclsrc
Log:
No TAB should be in this file ;[
Revision ChangesPath
1.3 +58 -58jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qclsrc
Index: bldjk.qclsrc
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qclsrc,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- bldjk.qclsrc 3 Dec 2002 17:45:42 - 1.2
+++ bldjk.qclsrc 3 Dec 2002 17:50:29 - 1.3
@@ -3,12 +3,12 @@
SRCSTMF('/home/apache/jk/native/apache-2.0/mod_jk.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5') +
TEXT('mod_jk.c')+
-OPTIMIZE(40) +
+OPTIMIZE(40)+
SYSIFCOPT(*IFSIO) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG) +
-TERASPACE(*YES) +
-STGMDL(*TERASPACE) +
+TERASPACE(*YES) +
+STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
@@ -16,13 +16,13 @@
SRCSTMF('/home/apache/jk/native/common/jk_ajp_common.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5') +
TEXT('jk_ajp_common.c') +
-OPTIMIZE(40) +
-SYSIFCOPT(*IFSIO) +
+OPTIMIZE(40) +
+SYSIFCOPT(*IFSIO)+
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG) +
-TERASPACE(*YES) +
-STGMDL(*TERASPACE)+
+TERASPACE(*YES) +
+STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
@@ -30,13 +30,13 @@
SRCSTMF('/home/apache/jk/native/common/jk_ajp12_worker.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5')+
TEXT('jk_ajp12_worker.c') +
-OPTIMIZE(40)+
+OPTIMIZE(40) +
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG)+
-TERASPACE(*YES) +
-STGMDL(*TERASPACE) +
+TERASPACE(*YES)+
+STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
@@ -44,13 +44,13 @@
SRCSTMF('/home/apache/jk/native/common/jk_ajp13.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5') +
TEXT('jk_ajp13.c') +
-OPTIMIZE(40) +
+OPTIMIZE(40)+
SYSIFCOPT(*IFSIO) +
LANGLVL(*ANSI) +
TGTCCSID(*JOB) +
OPTION(*LOGMSG) +
-TERASPACE(*YES) +
-STGMDL(*TERASPACE) +
+TERASPACE(*YES) +
+STGMDL(*TERASPACE) +
INCDIR('/home/apache/jk/native/common' +
'/QIBM/ProdData/HTTPA/Include')
@@ -58,13 +58,13 @@
SRCSTMF('/home/apache/jk/native/common/jk_ajp13_worker.c') +
DEFINE('AS400' 'HAVE_JNI' 'USE_APACHE_MD5')+
TEXT('jk_ajp13_worker.c') +
-OPTIMIZE(40)+
+OPTIMIZE(40) +
SYSIFCOPT(*IFSIO) +
Re: [5.0] Cluster features
Costin Manolache wrote: Remy Maucherat wrote: Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I wanted to, however I can't do that without changing the API some stuff in the session package (the damn classes are all package private) :-P I suppose it's a lot better to stop the hacks *now*, fix that, and put everything in the cluster package. I think it is time to stop bloating the base tomcat source and binaries. BTW, it may be a good time to move some of the current features in separate modules as well. ( SSI, WebDAV, etc ). For webdav - I would rather see slide bundled with tomcat and the current code deprecated. I'm not talking ( for now ) about a real module with descriptors or anything, just separate dirs in the CVS and a .jar target that can be included or not. Ok. It may be worth reopening the minimal tomcat discussion :-) Maybe. If the difference is only a couple MBs, then it's not worth it, though. If we do an alternate distribution, it would have to be radically different IMO (like for example, being a simple set of JARs without the complex dir structure). The laucher + the catalina.properties + future mods to the config system should make that easy. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/conf server.xml
remm2002/12/03 10:41:21 Modified:catalina/src/conf server.xml Log: - Modify the default configuration: - the upload timeout control is IMO a great feature in specific cases, but isn't useful in many others. As I think JNI calls are far from beiing free, I would disable it by default. - the pool used now is symetrical (ie, it doesn't have a dedicated thread dedicated to accepting), so I need it could need a higher socket backlog. The default value is now the default value specified in the endpoint class (I hope it wasn't selected randomly ;-) ) Revision ChangesPath 1.10 +9 -11 jakarta-tomcat-catalina/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/server.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- server.xml22 Oct 2002 09:48:15 - 1.9 +++ server.xml3 Dec 2002 18:41:21 - 1.10 @@ -84,10 +84,10 @@ !-- Define a non-SSL Coyote HTTP/1.1 Connector on port 8080 -- Connector className=org.apache.coyote.tomcat5.CoyoteConnector - port=8080 minProcessors=5 maxProcessors=75 - enableLookups=true redirectPort=8443 - acceptCount=10 debug=0 connectionTimeout=2 - useURIValidationHack=false / + port=8080 minProcessors=5 maxProcessors=100 + enableLookups=trueredirectPort=8443 acceptCount=100 + debug=0 connectionTimeout=2 + disableUploadTimeout=true / !-- Note : To disable connection timeouts, set connectionTimeout value to -1 -- @@ -95,9 +95,8 @@ !-- Connector className=org.apache.coyote.tomcat5.CoyoteConnector port=8443 minProcessors=5 maxProcessors=75 - enableLookups=true -acceptCount=10 debug=0 scheme=https secure=true - useURIValidationHack=false + enableLookups=true disableUploadTimeout=true +acceptCount=100 debug=0 scheme=https secure=true Factory className=org.apache.coyote.tomcat5.CoyoteServerSocketFactory clientAuth=false protocol=TLS / /Connector @@ -107,8 +106,7 @@ Connector className=org.apache.coyote.tomcat5.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 - acceptCount=10 debug=0 connectionTimeout=2 - useURIValidationHack=false + acceptCount=10 debug=0 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ !-- Define a Proxied HTTP/1.1 Connector on port 8082 -- @@ -117,8 +115,8 @@ Connector className=org.apache.coyote.tomcat5.CoyoteConnector port=8082 minProcessors=5 maxProcessors=75 enableLookups=true - acceptCount=10 debug=0 connectionTimeout=2 - proxyPort=80 useURIValidationHack=false / + acceptCount=100 debug=0 connectionTimeout=2 + proxyPort=80 disableUploadTimeout=true / -- !-- An Engine represents the entry point (within Catalina) that processes -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/conf server.xml
remm2002/12/03 10:44:51 Modified:catalina/src/conf server.xml Log: - Oops ... Revision ChangesPath 1.11 +1 -1 jakarta-tomcat-catalina/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/server.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- server.xml3 Dec 2002 18:41:21 - 1.10 +++ server.xml3 Dec 2002 18:44:51 - 1.11 @@ -85,7 +85,7 @@ !-- Define a non-SSL Coyote HTTP/1.1 Connector on port 8080 -- Connector className=org.apache.coyote.tomcat5.CoyoteConnector port=8080 minProcessors=5 maxProcessors=100 - enableLookups=trueredirectPort=8443 acceptCount=100 + enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / !-- Note : To disable connection timeouts, set connectionTimeout value -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5/resources/confinstall server_2.xml
remm2002/12/03 10:45:16 Modified:resources/confinstall server_2.xml Log: - Oops ... Revision ChangesPath 1.7 +1 -1 jakarta-tomcat-5/resources/confinstall/server_2.xml Index: server_2.xml === RCS file: /home/cvs/jakarta-tomcat-5/resources/confinstall/server_2.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- server_2.xml 3 Dec 2002 18:41:31 - 1.6 +++ server_2.xml 3 Dec 2002 18:45:16 - 1.7 @@ -1,5 +1,5 @@ minProcessors=5 maxProcessors=100 - enableLookups=trueredirectPort=8443 acceptCount=100 + enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / !-- Note : To disable connection timeouts, set connectionTimeout value -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Remy Maucherat wrote: +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I wanted to, however I can't do that without changing the API some stuff in the session package (the damn classes are all package private) :-P I suppose it's a lot better to stop the hacks *now*, fix that, and put everything in the cluster package. Well, if you must - you must. But we shouldn't have the core depend on the clustering, just add the minimal stuff that you need in the session. If we can stop the hacks and clean something - I think 5.0 is the best chance. I would preffer to have a consistent hook mechanism for everything - I'm not sure what callbacks will be involved in the clustering. It may be worth reopening the minimal tomcat discussion :-) Maybe. If the difference is only a couple MBs, then it's not worth it, though. Bloat is not about MB or storage. It's about code complexity, potential security, etc. If we do an alternate distribution, it would have to be radically different IMO (like for example, being a simple set of JARs without the complex dir structure). The laucher + the catalina.properties + future mods to the config system should make that easy. That's what I was thinking about - a set of jars and minimal configuration. Eventually using only MBeans for configuration and setup. BTW, we could use MBeans for the optional packages too. I think it works pretty well. We'll need to get a consensus on requiring JMX for tomcat5, but so far it doesn't seem it'll have a big impact on the code ( I did all kind of experiments with modeler and ant lately ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15032] New: - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43
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=15032.
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=15032
Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43
Summary: Headers get corrupted when used with mod_jk/mod_jk2 and
apache 2.0.43
Product: Tomcat 4
Version: 4.1.12
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Major
Priority: Other
Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Using the following test case the header values show content from the output
stream. This happens only when the response is relatively large and the headers
have not been requested until after a relatively large response has been
written. Definitely happens with Mozilla 1.0.1 when a user does a shift reload.
to test:
compare the output between
http://localhost:8080/search/jk_test.jsp?lines=500 (no mod_jk)
http://localhost/search/jk_test.jsp?lines=500 (with mod_jk)
%@ page language=java %
%@ page import=java.util.*, java.io.* %
%! void writeHeaders(HttpServletRequest request, JspWriter out)
throws IOException {
Enumeration enum = request.getHeaderNames();
while(enum.hasMoreElements()) {
String name = (String) enum.nextElement();
String headerString = Header Name: + name + Header Value: +
request.getHeader(name);
out.print(headerString);
//print to std out to make sure it is not getting
//corrupted on the way out
System.out.println(headerString);
out.println(br);
}
}
%
%! static final DEFAULT_COUNT = 400; /*default no of lines to write*/ %
%
boolean writeBefore = false;
int lineCount = DEFAULT_COUNT; //should be large enought to invoke demo errors
String doWriteBefore = request.getParameter(write_before);
String lnCount = request.getParameter(lines);
writeBefore = Boolean.valueOf(doWriteBefore).booleanValue();
try {
lineCount = Integer.parseInt(lnCount);
} catch (NumberFormatException ne) {
lineCount = DEFAULT_COUNT;
} catch (NullPointerException ne) {
lineCount = DEFAULT_COUNT;
}
%
html
body
%-- write headers before we write a large response--%
% if (writeBefore) { %
% writeHeaders(request, out); %
% } %
%for (int i=0; i lineCount; i++) {%
This is a really big html file... with lots of databr
% } %
%-- write headers after we have a written a response --%
% writeHeaders(request, out); %
/body
/html
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43
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=15032. 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=15032 Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 18:55 --- Created an attachment (id=4025) test case file that shows the bug -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43
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=15032. 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=15032 Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 19:05 --- Created an attachment (id=4026) workers2.properties for mod_jk2 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43
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=15032. 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=15032 Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 19:05 --- Created an attachment (id=4027) jk2 properties file for tomcat 4.1.12 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Costin Manolache wrote: Remy Maucherat wrote: +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I wanted to, however I can't do that without changing the API some stuff in the session package (the damn classes are all package private) :-P I suppose it's a lot better to stop the hacks *now*, fix that, and put everything in the cluster package. Well, if you must - you must. But we shouldn't have the core depend on the clustering, just add the minimal stuff that you need in the session. If we can stop the hacks and clean something - I think 5.0 is the best chance. I would preffer to have a consistent hook mechanism for everything - I'm not sure what callbacks will be involved in the clustering. I'll remove stuff in the Cluster API, modify some of the session classes to allow extending them in a different package, and everything in the core is then independent of the clustering. It may be worth reopening the minimal tomcat discussion :-) Maybe. If the difference is only a couple MBs, then it's not worth it, though. Bloat is not about MB or storage. It's about code complexity, potential security, etc. Ok. All distributions need to be thought as secure, though. If we do an alternate distribution, it would have to be radically different IMO (like for example, being a simple set of JARs without the complex dir structure). The laucher + the catalina.properties + future mods to the config system should make that easy. That's what I was thinking about - a set of jars and minimal configuration. Eventually using only MBeans for configuration and setup. I thought this was supposed to be JNDI. JMX does not have any support for bean state serialization, right ? BTW, we could use MBeans for the optional packages too. I think it works pretty well. We'll need to get a consensus on requiring JMX for tomcat5, but so far it doesn't seem it'll have a big impact on the code ( I did all kind of experiments with modeler and ant lately ). +1 for JMX (as there's MX4J); as well as JNDI, BTW. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Costin Manolache wrote: Remy Maucherat wrote: +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I wanted to, however I can't do that without changing the API some stuff in the session package (the damn classes are all package private) :-P I suppose it's a lot better to stop the hacks *now*, fix that, and put everything in the cluster package. Well, if you must - you must. But we shouldn't have the core depend on the clustering, just add the minimal stuff that you need in the session. If we can stop the hacks and clean something - I think 5.0 is the best chance. I would preffer to have a consistent hook mechanism for everything - I'm not sure what callbacks will be involved in the clustering. Are you thinking about having coyote Action(s)? If yes, we might one to extend the current API having in mind that we will need to supports Clustering, Authentification, Authorization, etc. It may be worth reopening the minimal tomcat discussion :-) Maybe. If the difference is only a couple MBs, then it's not worth it, though. Bloat is not about MB or storage. It's about code complexity, potential security, etc. If we do an alternate distribution, it would have to be radically different IMO (like for example, being a simple set of JARs without the complex dir structure). The laucher + the catalina.properties + future mods to the config system should make that easy. That's what I was thinking about - a set of jars and minimal configuration. Eventually using only MBeans for configuration and setup. BTW, we could use MBeans for the optional packages too. I think it works pretty well. We'll need to get a consensus on requiring JMX for tomcat5, but so far it doesn't seem it'll have a big impact on the code ( I did all kind of experiments with modeler and ant lately ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I wanted to, however I can't do that without changing the API some stuff in the session package (the damn classes are all package private) :-P I suppose it's a lot better to stop the hacks *now*, fix that, and put everything in the cluster package. Well, if you must - you must. But we shouldn't have the core depend on the clustering, just add the minimal stuff that you need in the session. If we can stop the hacks and clean something - I think 5.0 is the best chance. I would preffer to have a consistent hook mechanism for everything - I'm not sure what callbacks will be involved in the clustering. I'll remove stuff in the Cluster API, modify some of the session classes to allow extending them in a different package, and everything in the core is then independent of the clustering. No security problems if we kept the current package protection mechanism. Making those classes public can be dangerous if the package protection is not enabled. It may be worth reopening the minimal tomcat discussion :-) Maybe. If the difference is only a couple MBs, then it's not worth it, though. Bloat is not about MB or storage. It's about code complexity, potential security, etc. Ok. All distributions need to be thought as secure, though. Does that implies re-writting the current set of classloader? It might be a good time to revisit classloader and security :-) If we do an alternate distribution, it would have to be radically different IMO (like for example, being a simple set of JARs without the complex dir structure). The laucher + the catalina.properties + future mods to the config system should make that easy. That's what I was thinking about - a set of jars and minimal configuration. Eventually using only MBeans for configuration and setup. I thought this was supposed to be JNDI. JMX does not have any support for bean state serialization, right ? BTW, we could use MBeans for the optional packages too. I think it works pretty well. We'll need to get a consensus on requiring JMX for tomcat5, but so far it doesn't seem it'll have a big impact on the code ( I did all kind of experiments with modeler and ant lately ). +1 for JMX (as there's MX4J); as well as JNDI, BTW. +1 -- Jeanfrancois Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Strange Tomcat 4.1.x release versions
The last official final release was Tomcat 4.1.12 We now have a Tomcat 4.1.16 beta. What is up with this weird release numbering? What happened to Tomcat 4.1.13? Maybe Remy got infected by Sun's marketing. I'm still curious how Sun is going to deal with releasing Java 2.0 and the confusion that is going to create with Java2. What a brain dead idea that one was. I'm also not seeing a vote taking on the list about whether or not to do a release...or at least some sort of advance warning. I just love how this place turns into a free for all. Not. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid url-pattern in servlet mapping
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=13014. 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=13014 OS/390/USS - Invalid url-pattern in servlet mapping --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 19:33 --- After applying the changes described by Seyed Ali Madani, and rebuilding Tomcat, (and converting several script files, etc. to EBCDIC) I can confirm that Tomcat 4.0.6 will work on USS systems. Thanks very much for this advice! After this all of the example servlets and jsp operate correctly. There is one other change we found necessary, in order that error messages are properly displayed...this involves the getReporter() function in ResponseBase.java. I will attach the updated version of ResponseBase.java that we are using in case anyone wants to see it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid url-pattern in servlet mapping
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=13014. 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=13014 OS/390/USS - Invalid url-pattern in servlet mapping --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 19:36 --- Created an attachment (id=4028) Revisions to getReporter() so that encoding is observed -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Strange Tomcat 4.1.x release versions
On Tue, 3 Dec 2002, Jon Scott Stevens wrote: Date: Tue, 03 Dec 2002 11:29:54 -0800 From: Jon Scott Stevens [EMAIL PROTECTED] Reply-To: Jakarta Project Management Committee List [EMAIL PROTECTED] To: tomcat-dev [EMAIL PROTECTED] Cc: Jakarta Project Management Committee List [EMAIL PROTECTED] Subject: Strange Tomcat 4.1.x release versions The last official final release was Tomcat 4.1.12 We now have a Tomcat 4.1.16 beta. What is up with this weird release numbering? What happened to Tomcat 4.1.13? Maybe Remy got infected by Sun's marketing. I'm still curious how Sun is going to deal with releasing Java 2.0 and the confusion that is going to create with Java2. What a brain dead idea that one was. I'm also not seeing a vote taking on the list about whether or not to do a release...or at least some sort of advance warning. http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgNo=52475 I just love how this place turns into a free for all. Not. Someone obviously hasn't been keeping up on TOMCAT-DEV mail :-). See the discussions and vote that took place in April 2003, where the Tomcat developers agreed to adopt the version numbering approach that Apache 2.0 (and several other projects) use. A good starting point: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgNo=39859 -jon Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Strange Tomcat 4.1.x release versions
on 2002/12/3 11:51 AM, Craig R. McClanahan [EMAIL PROTECTED] wrote: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]. orgmsgNo=52475 Someone obviously hasn't been keeping up on TOMCAT-DEV mail :-). See the discussions and vote that took place in April 2003, where the Tomcat developers agreed to adopt the version numbering approach that Apache 2.0 (and several other projects) use. A good starting point: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]. orgmsgNo=39859 Ok, I understand the version number part now. I actually read those discussions but forgot about them. Full brain. But are you also saying that the HTTPd project doesn't announce on the list in advance when a new release is going to happen? -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Strange Tomcat 4.1.x release versions
on 2002/12/3 11:57 AM, Costin Manolache [EMAIL PROTECTED] wrote: It was voted on the list, Remy sent the proposal last week. Ok, I guess I missed that email. Sorry. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Jeanfrancois Arcand wrote: +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). I wanted to, however I can't do that without changing the API some stuff in the session package (the damn classes are all package private) :-P I suppose it's a lot better to stop the hacks *now*, fix that, and put everything in the cluster package. Well, if you must - you must. But we shouldn't have the core depend on the clustering, just add the minimal stuff that you need in the session. If we can stop the hacks and clean something - I think 5.0 is the best chance. I would preffer to have a consistent hook mechanism for everything - I'm not sure what callbacks will be involved in the clustering. Are you thinking about having coyote Action(s)? If yes, we might one to extend the current API having in mind that we will need to supports Clustering, Authentification, Authorization, etc. I don't care too much if it is called Coyote Action, Jk2 Handler, 3.3 Interceptor(with a single method), or 4.0 Valve ( in multiple chains ) or Axis Handler/Chain. Or even Event/Listener. Some time ago I started a package to implement yet-another hook, as a replacement for Action in coyote. I remove it because there is absolutely no point for yet another API - any of those APIs can do the job. All I want is a single and simple and consistent hook mechanism that is used for callbacks in all extension points ( simple is quite important :-) Since Coyote is now used in all tomcat versions and also jk - I think it is a good idea to use with coyote Action. But I'm +1 on anything else - as long as we converge on a single mechanism ( it is simple to wrap any hook - Vavle, interceptor, action. into any interface ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Strange Tomcat 4.1.x release versions
On Tue, 2002-12-03 at 11:29, Jon Scott Stevens wrote: The last official final release was Tomcat 4.1.12 We now have a Tomcat 4.1.16 beta. What is up with this weird release numbering? What happened to Tomcat 4.1.13? Maybe Remy got infected by Sun's marketing. I'm still curious how Sun is going to deal with releasing Java 2.0 and the confusion that is going to create with Java2. What a brain dead idea that one was. We follow exactly the same numbering scheme as apache2. 13,14,15 had problems and followed the same path as apache2.0.13,14,15 ( i.e. they are not released as beta or stable ). Hopefully 4.1.17 will be a release quality - and we'll not get to 40s. I'm also not seeing a vote taking on the list about whether or not to do a release...or at least some sort of advance warning. It was voted on the list, Remy sent the proposal last week. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Jeanfrancois Arcand wrote: I'll remove stuff in the Cluster API, modify some of the session classes to allow extending them in a different package, and everything in the core is then independent of the clustering. No security problems if we kept the current package protection mechanism. Making those classes public can be dangerous if the package protection is not enabled. That depends on the class loader - if tomcat is embedded in something else ( like J2EE or some other app ) I'm not sure how it'll protect this. Also, a number of classes are public because they are intended to be used, and a number of security problems may happen ( as we learned ) even if the class is not accessible ( like the recent web.xml entity issues ). Bloat is not about MB or storage. It's about code complexity, potential security, etc. Ok. All distributions need to be thought as secure, though. Does that implies re-writting the current set of classloader? It might be a good time to revisit classloader and security :-) Do you have so much free time :-) ? I'm +1 BTW. If we reach consensus on JMX - it may be a good idea to use its class loading mechanism, or something very close - the model in theory is very good. You have full control ( using mlet tags or API ) over the class loaders and hierarchy. +1 for JMX (as there's MX4J); as well as JNDI, BTW. +1 I'll send a separate mail with a VOTE subject. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] Making JMX required in tomcat5
The subject should be clear. The benefit is that we'll be able to build more JMX awareness in the code without doing tricks - each component will know about its ObjectName and will be able to return ObjectName[]. I'm not proposing MBeans all over tomcat - modeler works very well in transforming our components into model mbeans. We already have 3 +1 votes ( costin, Remy and Jean Francois ). The only possible problem is the classical licensing issue ( we must use mx4j - but I don't know if they passed the TCK or if they will or if the TCK is available yet, etc ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Costin Manolache wrote: Jeanfrancois Arcand wrote: I'll remove stuff in the Cluster API, modify some of the session classes to allow extending them in a different package, and everything in the core is then independent of the clustering. No security problems if we kept the current package protection mechanism. Making those classes public can be dangerous if the package protection is not enabled. That depends on the class loader - if tomcat is embedded in something else ( like J2EE or some other app ) I'm not sure how it'll protect this. It will work if, in their classloader implementation, they call securityManager.checkPackageDefinition(...). The current J2EE 1.4 RI doesn't., and most of the EE implementation doesn't because of the Security Manager performance hit. Also, a number of classes are public because they are intended to be used, and a number of security problems may happen ( as we learned ) even if the class is not accessible ( like the recent web.xml entity issues ). Bloat is not about MB or storage. It's about code complexity, potential security, etc. Ok. All distributions need to be thought as secure, though. Does that implies re-writting the current set of classloader? It might be a good time to revisit classloader and security :-) Do you have so much free time :-) ? I'm +1 BTW. What do you do when its -20 celcius? ;-) Try to find something to warm yourself :-) I was under the impression Remy was having a proposal for the classloader stuff. (IMBW). Once I have a clear understanding on all the hooks (inclusing Axis/Apache), I would certainly work on his proposal :-) -- Jeanfrancois If we reach consensus on JMX - it may be a good idea to use its class loading mechanism, or something very close - the model in theory is very good. You have full control ( using mlet tags or API ) over the class loaders and hierarchy. +1 for JMX (as there's MX4J); as well as JNDI, BTW. +1 I'll send a separate mail with a VOTE subject. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Making JMX required in tomcat5
+1 Amy Costin Manolache wrote: The subject should be clear. The benefit is that we'll be able to build more JMX awareness in the code without doing tricks - each component will know about its ObjectName and will be able to return ObjectName[]. I'm not proposing MBeans all over tomcat - modeler works very well in transforming our components into model mbeans. We already have 3 +1 votes ( costin, Remy and Jean Francois ). The only possible problem is the classical licensing issue ( we must use mx4j - but I don't know if they passed the TCK or if they will or if the TCK is available yet, etc ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspContextWrapper.java
luehe 2002/12/03 15:17:48
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
jasper2/src/share/org/apache/jasper/runtime
JspContextWrapper.java
Log:
Performance improvement:
Pass ArrayList (instead of Vector) of scripting variables to
JSP Context Wrapper constructor: ArrayList is not synchronized.
Revision ChangesPath
1.134 +12 -12
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.133
retrieving revision 1.134
diff -u -r1.133 -r1.134
--- Generator.java28 Nov 2002 04:18:08 - 1.133
+++ Generator.java3 Dec 2002 23:17:48 - 1.134
@@ -3043,9 +3043,9 @@
out.pushIndent();
out.printil(super.setJspContext(ctx););
TagVariableInfo[] tagVars = tagInfo.getTagVariableInfos();
- out.printil(java.util.Vector _jspx_nested = null;);
- out.printil(java.util.Vector _jspx_at_begin = null;);
- out.printil(java.util.Vector _jspx_at_end = null;);
+ out.printil(java.util.ArrayList _jspx_nested = null;);
+ out.printil(java.util.ArrayList _jspx_at_begin = null;);
+ out.printil(java.util.ArrayList _jspx_at_end = null;);
for (int i=0; itagVars.length; i++) {
@@ -3053,25 +3053,25 @@
case VariableInfo.NESTED:
out.printil(if (_jspx_nested == null));
out.pushIndent();
- out.printil(_jspx_nested = new java.util.Vector(););
+ out.printil(_jspx_nested = new java.util.ArrayList(););
out.popIndent();
- out.printin(_jspx_nested.addElement();
+ out.printin(_jspx_nested.add();
break;
case VariableInfo.AT_BEGIN:
out.printil(if (_jspx_at_begin == null));
out.pushIndent();
- out.printil(_jspx_at_begin = new java.util.Vector(););
+ out.printil(_jspx_at_begin = new java.util.ArrayList(););
out.popIndent();
- out.printin(_jspx_at_begin.addElement();
+ out.printin(_jspx_at_begin.add();
break;
case VariableInfo.AT_END:
out.printil(if (_jspx_at_end == null));
out.pushIndent();
- out.printil(_jspx_at_end = new java.util.Vector(););
+ out.printil(_jspx_at_end = new java.util.ArrayList(););
out.popIndent();
- out.printin(_jspx_at_end.addElement();
+ out.printin(_jspx_at_end.add();
break;
} // switch
1.9 +12 -12
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspContextWrapper.java
Index: JspContextWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspContextWrapper.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- JspContextWrapper.java13 Nov 2002 17:40:41 - 1.8
+++ JspContextWrapper.java3 Dec 2002 23:17:48 - 1.9
@@ -66,7 +66,7 @@
import java.util.Enumeration;
import java.util.Hashtable;
-import java.util.Vector;
+import java.util.ArrayList;
import java.util.Iterator;
import javax.servlet.Servlet;
@@ -106,19 +106,19 @@
private transient Hashtable pageAttributes;
-// Vector of NESTED scripting variables
-private Vector nestedVars;
+// ArrayList of NESTED scripting variables
+private ArrayList nestedVars;
-// Vector of AT_BEGIN scripting variables
-private Vector atBeginVars;
+// ArrayList of AT_BEGIN scripting variables
+private ArrayList atBeginVars;
-// Vector of AT_END scripting variables
-private Vector atEndVars;
+// ArrayList of AT_END scripting variables
+private ArrayList atEndVars;
private Hashtable originalNestedVars;
-public JspContextWrapper(JspContext jspContext, Vector nestedVars,
- Vector atBeginVars, Vector atEndVars) {
+public JspContextWrapper(JspContext jspContext, ArrayList nestedVars,
+ ArrayList atBeginVars, ArrayList atEndVars) {
this.invokingJspCtxt = (PageContext) jspContext;
this.nestedVars = nestedVars;
this.atBeginVars = atBeginVars;
--
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 Generator.java
luehe 2002/12/03 15:49:46
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
Do not call the setParent() method on SimpleTag handlers if the value
being passed is null, since SimpleTag instances are not reused
Revision ChangesPath
1.135 +11 -7
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.134
retrieving revision 1.135
diff -u -r1.134 -r1.135
--- Generator.java3 Dec 2002 23:17:48 - 1.134
+++ Generator.java3 Dec 2002 23:49:46 - 1.135
@@ -2378,10 +2378,14 @@
out.println(););
}
} else {
- out.printin(tagHandlerVar);
- out.print(.setParent();
- out.print(parent);
- out.println(););
+ // The setParent() method need not be called if the value being
+ // passed is null, since SimpleTag instances are not reused
+ if (parent != null) {
+ out.printin(tagHandlerVar);
+ out.print(.setParent();
+ out.print(parent);
+ out.println(););
+ }
}
Node.JspAttribute[] attrs = n.getJspAttributes();
--
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/tagplugin TagPlugin.java TagPluginContext.java TagPluginFactory.java
kinman 2002/12/03 16:48:43
Modified:jasper2/src/share/org/apache/jasper
EmbededServletOptions.java JspC.java Options.java
jasper2/src/share/org/apache/jasper/compiler Compiler.java
Node.java TagPluginManager.java
jasper2/src/share/org/apache/jasper/compiler/tagplugin
TagPlugin.java TagPluginContext.java
Removed: jasper2/src/share/org/apache/jasper/compiler/tagplugin
TagPluginFactory.java
Log:
- First cut in defining the tag plugin interface and an implementation
of framework in Jasper.
WARNING: This is still experimental and subject to change.
Revision ChangesPath
1.14 +15 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbededServletOptions.java
Index: EmbededServletOptions.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbededServletOptions.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- EmbededServletOptions.java28 Nov 2002 04:18:07 - 1.13
+++ EmbededServletOptions.java4 Dec 2002 00:48:42 - 1.14
@@ -70,6 +70,7 @@
import org.apache.jasper.compiler.TldLocationsCache;
import org.apache.jasper.compiler.JspConfig;
+import org.apache.jasper.compiler.TagPluginManager;
import org.apache.jasper.xmlparser.ParserUtils;
import java.util.*;
@@ -175,6 +176,11 @@
private JspConfig jspConfig = null;
/**
+ * TagPluginManager
+ */
+private TagPluginManager tagPluginManager = null;
+
+/**
* Java platform encoding to generate the JSP
* page servlet.
*/
@@ -301,6 +307,10 @@
return jspConfig;
}
+public TagPluginManager getTagPluginManager() {
+ return tagPluginManager;
+}
+
/**
* Create an EmbededServletOptions object using data available from
* ServletConfig and ServletContext.
@@ -475,6 +485,8 @@
// Setup the jsp config info for this web app.
jspConfig = new JspConfig(context);
+ // Create a Tag plugin instance
+ tagPluginManager = new TagPluginManager(context);
}
}
1.19 +15 -6
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- JspC.java 16 Nov 2002 04:20:09 - 1.18
+++ JspC.java 4 Dec 2002 00:48:42 - 1.19
@@ -74,6 +74,8 @@
import org.apache.jasper.logging.Logger;
import org.apache.jasper.logging.JasperLogger;
import org.apache.jasper.compiler.JspConfig;
+import org.apache.jasper.compiler.JspConfig;
+import org.apache.jasper.compiler.TagPluginManager;
/**
* Shell for the jspc compiler. Handles all options associated with the
@@ -197,6 +199,9 @@
*/
private TldLocationsCache tldLocationsCache = null;
+private JspConfig jspConfig = null;
+private TagPluginManager tagPluginManager = null;
+
private boolean listErrors = false;
private boolean showSuccess = false;
@@ -737,6 +742,8 @@
} catch (MalformedURLException me) {
System.out.println(** + me);
}
+ jspConfig = new JspConfig(context);
+ tagPluginManager = new TagPluginManager(context);
}
@@ -945,10 +952,12 @@
* Obtain JSP configuration informantion specified in web.xml.
*/
public JspConfig getJspConfig() {
-// XXX - Stubbed out so Jasper compiles.
-initServletContext();
-return new JspConfig( context );
+ return jspConfig;
}
+
+public TagPluginManager getTagPluginManager() {
+return tagPluginManager;
+}
}
1.10 +9 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Options.java
Index: Options.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Options.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- Options.java 16 Nov 2002 04:20:09 - 1.9
+++ Options.java 4 Dec 2002 00:48:42 - 1.10
@@ -68,6 +68,7 @@
import org.apache.jasper.compiler.TldLocationsCache;
import org.apache.jasper.compiler.JspConfig;
+import org.apache.jasper.compiler.TagPluginManager;
/**
* A class to hold all init parameters specific to the JSP engine.
@@ -172,4 +173,9 @@
* Obtain JSP configuration informantion
RE: [5.0] Cluster features
we have a project on sourceforge to continue development of this. but we would love to integrate this into Tomcat where it really belongs. http://sourceforge.net/projects/tomcat-jg Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 8:50 AM To: Tomcat Developers List Subject: [5.0] Cluster features Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/tagplugin TagPlugin.java TagPluginContext.java
kinman 2002/12/03 17:41:19
Modified:jasper2/src/share/org/apache/jasper/compiler/tagplugin
TagPlugin.java TagPluginContext.java
Log:
- Some doc editing
Revision ChangesPath
1.3 +11 -7
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/tagplugin/TagPlugin.java
Index: TagPlugin.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/tagplugin/TagPlugin.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TagPlugin.java4 Dec 2002 00:48:43 - 1.2
+++ TagPlugin.java4 Dec 2002 01:41:19 - 1.3
@@ -63,15 +63,19 @@
/**
* This interface is to be implemented by the plugin author, to supply
- * an alternate implementation of the tag handlers. Used to specify
- * the Java codes that need to be generated when a tag is referenced.
+ * an alternate implementation of the tag handlers. It can be used to
+ * specify the Java codes to be generated when a tag is referenced.
+ *
+ * An implementation of this interface must be registered in a file
+ * named tagPlugins.xml under WEB-INF.
*/
public interface TagPlugin {
/**
- * Invoked to generate codes a custom tag.
+ * Generate codes for a custom tag.
+ * @param ctxt a TagPluginContext for accessing Jasper functions
*/
-void doTag(TagPluginContext c);
+void doTag(TagPluginContext ctxt);
}
1.3 +9 -9
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/tagplugin/TagPluginContext.java
Index: TagPluginContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/tagplugin/TagPluginContext.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TagPluginContext.java 4 Dec 2002 00:48:43 - 1.2
+++ TagPluginContext.java 4 Dec 2002 01:41:19 - 1.3
@@ -64,9 +64,9 @@
import org.apache.jasper.compiler.ServletWriter;
/**
- * This interface allows the plugin author to query about the properties
- * of the current tag, and to use Jasper resources to generate more
- * efficient implementation for the tag handler under some conditions.
+ * This interface allows the plugin author to make inqueries about the
+ * properties of the current tag, and to use Jasper resources to generate
+ * direct Java codes in place of tag handler invokations.
*/
public interface TagPluginContext {
@@ -104,10 +104,10 @@
void generateBody();
/**
- * Abandon optimization for this tag handler, and instruct the
+ * Abandon optimization for this tag handler, and instruct
* Jaser to generate the tag handler calls, as usual.
- * Should be invoked if errors are detected, or that the tag body is
- * too compilicated for optimization.
+ * Should be invoked if errors are detected, or when the tag body
+ * is judged to be too compilicated for optimization.
*/
void dontUseTagPlugin();
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[ANNOUNCEMENT] Apache Tomcat 4.1.16 Beta released
The Tomcat Team announces the immediate availability of Apache Tomcat 4.1.16 Beta. Tomcat 4.1.16 includes many bugfixes and performance tweaks over Tomcat 4.1.12. Please see the release notes for a complete list of the changes. Downloads (source and binaries): http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.16-beta/ Release notes: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.16-beta/RELEASE-NOTES Important note: When upgrading from another Tomcat 4.x release, the Tomcat work directory must be cleared. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
SSI invoking CGI fix PATCH
Hello Tom Cats,
Currently under Tomcat 4.1.12 SSI normal configuration which invokes a
CGI script does not work. The reason for this is pretty obvious: The SSI
servelet uses the pathInfo (PATH_INFO) value and calls the request
dispatcher for any resources needed. The request dispatcher eats the
pathInfo value and the CGI servlet can't find the CGI program, because it
relies on pathInfo to tell it where the script is. Or something like that,
whatever, you cats probably know better.
Anyway, I made minor changes to three files in the current 4.1.12 distro
to solve this problem. The strategy is thus: SSI-invoked resources flag
the request with an attibute. When CGI servlet finally gets the request
dispached, he checks whether SSI servlet invoked the resource via said
attribute. If this is the case, he ignores the request.getPathInfo()
method in favor of an already-present attribute on the request which
already has the PATH_INFO environment value in it.
Voila, everything works now. Diff attached.
Nick Bauman
Software Engineer
Cortexity Development
3600 N. Dupont
Minneapolis, MN
55412
M: 612-232-7120
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/Globals.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/Globals.java
--- jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/Globals.java
2002-09-23 03:24:20.0 -0600
+++ jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/Globals.java
+ 2002-12-03 20:48:00.0 -0600
@@ -290,5 +290,13 @@
public static final String WORK_DIR_ATTR =
javax.servlet.context.tempdir;
-
+ /**
+* The servlet context attribute under which we store a flag used
+* to mark this request as having been processed by the SSIServlet.
+* We do this because of the pathInfo mangling happening when using
+* the CGIServlet in conjunction with the SSI servlet. (value stored
+* as an object of type String)
+*/
+public static final String SSI_FLAG_ATTR =
+org.apache.catalina.ssi.SSIServlet;
}
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
---
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
2002-09-23 03:24:18.0 -0600
+++
+jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
+ 2002-12-03 20:54:32.0 -0600
@@ -966,8 +966,12 @@
String sCGIName = null;
String[] sCGINames;
-
-sPathInfoOrig = this.pathInfo;
+if(null != req.getAttribute(Globals.SSI_FLAG_ATTR)) {
+ // invoked by SSIServlet, which eats our req.getPathInfo() data
+ sPathInfoOrig = (String) req.getAttribute(Globals.PATH_INFO_ATTR);
+} else {
+sPathInfoOrig = this.pathInfo;
+}
sPathInfoOrig = sPathInfoOrig == null ? : sPathInfoOrig;
sPathTranslatedOrig = req.getPathTranslated();
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
---
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
2002-09-23 03:24:18.0 -0600
+++
+jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
+ 2002-12-03 19:44:06.0 -0600
@@ -64,38 +64,24 @@
package org.apache.catalina.ssi;
+import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
-import java.io.OutputStream;
-import java.io.OutputStreamWriter;
-import java.io.BufferedInputStream;
-import java.io.BufferedReader;
-import java.io.ByteArrayOutputStream;
import java.io.PrintWriter;
-import java.io.Reader;
import java.io.StringWriter;
-import java.io.Writer;
import java.net.URL;
import java.net.URLConnection;
-import java.net.URLDecoder;
-import java.util.ArrayList;
-import java.util.Collection;
import java.util.Date;
-import java.util.Enumeration;
-import java.util.HashMap;
-import java.util.Locale;
-import java.text.SimpleDateFormat;
-import java.util.StringTokenizer;
-import java.util.TimeZone;
-import javax.servlet.RequestDispatcher;
-import javax.servlet.ServletException;
+
import javax.servlet.ServletContext;
-import javax.servlet.ServletOutputStream;
+import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
+import org.apache.catalina.Globals;
+
/**
* Servlet to process SSI requests within a webpage.
* Mapped to a path from within web.xml.
@@ -234,7 +220,7 @@
res.setDateHeader(Expires, (
