Re: Double Version
Laxmikanth M.S. wrote: Hi , A question for tomcat-user list please. I have installed two versions of Tomcat and apache running together on the same Machine Apache1.3.27 - Tomcat3.3.1 Apache1.3.27 - Tomcat4.1.12 Make Apaches and Tomcats listens on differents ports: Apache1.3.27 (80) - Tomcat3.3.1 (8080, 8007, 8009) Apache1.3.27 (8092) - Tomcat4.1.12 (8180, 8109) is it possible to run the servers in the same macine. I am not able to start apache servers. Is there any way to resolve this. thanks Regards Laxmikanth M S Off* : 91-80-6610330 extn 1256 Res* : 91-80-5267150 http://www.sonata-software.com Coming together is the beginning, staying together is progress and working together is Success What lies behind us and what lies before us are tiny matters compared to what lies within us - Emerson * Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. * -- 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-catalina/catalina/src/share/org/apache/catalina/startup Bootstrap.java ClassLoaderFactory.java
remm2002/12/02 02:38:11
Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java ClassLoaderFactory.java
Log:
- Add the possibility to specify remote codebases.
Revision ChangesPath
1.8 +15 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Bootstrap.java26 Oct 2002 12:29:56 - 1.7
+++ Bootstrap.java2 Dec 2002 10:38:11 - 1.8
@@ -97,6 +97,7 @@
protected static final String CATALINA_TOKEN = ${catalina.home};
+protected static final String HTTP_TOKEN = http://;;
// --- Static Variables
@@ -153,10 +154,17 @@
ArrayList unpackedList = new ArrayList();
ArrayList packedList = new ArrayList();
+ArrayList urlList = new ArrayList();
StringTokenizer tokenizer = new StringTokenizer(value, ,);
while (tokenizer.hasMoreElements()) {
String repository = tokenizer.nextToken();
+// Check for a remote repository
+if (repository.startsWith(HTTP_TOKEN)) {
+urlList.add(new URL(repository));
+continue;
+}
+// Local repository
boolean packed = false;
if (repository.startsWith(CATALINA_TOKEN)) {
repository = getCatalinaHome()
@@ -176,8 +184,10 @@
File[] unpacked = (File[]) unpackedList.toArray(new File[0]);
File[] packed = (File[]) packedList.toArray(new File[0]);
+URL[] urls = (URL[]) urlList.toArray(new URL[0]);
-return ClassLoaderFactory.createClassLoader(unpacked, packed, parent);
+return ClassLoaderFactory.createClassLoader
+(unpacked, packed, urls, parent);
}
1.3 +39 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java
Index: ClassLoaderFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ClassLoaderFactory.java 24 Oct 2002 13:53:22 - 1.2
+++ ClassLoaderFactory.java 2 Dec 2002 10:38:11 - 1.3
@@ -152,6 +152,34 @@
File packed[],
ClassLoader parent)
throws Exception {
+return createClassLoader(unpacked, packed, null, parent);
+}
+
+
+/**
+ * Create and return a new class loader, based on the configuration
+ * defaults and the specified directory paths:
+ *
+ * @param unpacked Array of pathnames to unpacked directories that should
+ * be added to the repositories of the class loader, or codenull/code
+ * for no unpacked directories to be considered
+ * @param packed Array of pathnames to directories containing JAR files
+ * that should be added to the repositories of the class loader,
+ * or codenull/code for no directories of JAR files to be considered
+ * @param urls Array of URLs to remote repositories, designing either JAR
+ * resources or uncompressed directories that should be added to
+ * the repositories of the class loader, or codenull/code for no
+ * directories of JAR files to be considered
+ * @param parent Parent class loader for the new class loader, or
+ * codenull/code for the system class loader.
+ *
+ * @exception Exception if an error occurs constructing the class loader
+ */
+public static ClassLoader createClassLoader(File unpacked[],
+File packed[],
+URL urls[],
+ClassLoader parent)
+throws Exception {
if (debug = 1)
log(Creating new class loader);
@@ -193,6 +221,13 @@
file.getCanonicalPath());
list.add(url.toString());
}
+}
+}
+
+// Add remote URLs
+if (urls != null) {
+for (int i = 0; i urls.length; i++) {
+list.add(urls[i].toString());
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands,
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-02 10:40 --- You should give us information on mod_jk you're using, jk 1.1, 1.2.0, 1.2.1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jasper DOM API
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]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties messages_es.properties messages_fr.properties messages_ja.properties
jfclere 2002/12/02 03:21:01
Modified:jasper2/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
messages_fr.properties messages_ja.properties
Log:
The -o option is not supported -dd seems to be the one to use.
Revision ChangesPath
1.62 +2 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -r1.61 -r1.62
--- messages.properties 23 Nov 2002 00:04:58 - 1.61
+++ messages.properties 2 Dec 2002 11:21:00 - 1.62
@@ -156,7 +156,7 @@
jsp.error.bad_attribute=Attribute {0} invalid for tag {1} according to TLD
jsp.error.tld_not_found=Could not locate TLD {0}
jsp.error.webxml_not_found=Could not locate web.xml
-jsp.cmd_line.usage=Usage: jsptoservlet [-o path/to/outputDirectory]
[-keepgenerated] \
+jsp.cmd_line.usage=Usage: jsptoservlet [-dd path/to/outputDirectory]
[-keepgenerated] \
.jsp files
jsp.message.cp_is=Classpath {0} is: {1}
jsp.error.unable.to_load_taghandler_class=Unable to load tag handler class {0}
because of {1}
1.24 +2 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties
Index: messages_es.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- messages_es.properties8 Nov 2002 19:42:56 - 1.23
+++ messages_es.properties2 Dec 2002 11:21:00 - 1.24
@@ -128,7 +128,7 @@
jsp.error.bad_attribute=atributo {0} no es valido de acuerdo con el TLD especificado
jsp.error.tld_not_found=No puedo localizar el TLD {0}
jsp.error.webxml_not_found=No puedo localizar web.xml
-jsp.cmd_line.usage=Uso: jsptoservlet [-o ruta/a/DirectorioSalida]
[-keepgenerated] Archivos .jsp
+jsp.cmd_line.usage=Uso: jsptoservlet [-dd ruta/a/DirectorioSalida]
[-keepgenerated] Archivos .jsp
jsp.message.cp_is=classpath {0} es: {1}
jsp.error.unable.to_load_taghandler_class=No se puede cargar clase manejadora {0}
del tag acausa de {1}
jsp.error.unable.to_find_method=No se puede encontrar el metodo de escritura para
el atributo: {0}
1.6 +2 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_fr.properties
Index: messages_fr.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_fr.properties,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- messages_fr.properties23 Nov 2002 00:04:58 - 1.5
+++ messages_fr.properties2 Dec 2002 11:21:00 - 1.6
@@ -153,7 +153,7 @@
jsp.error.bad_attribute=L''attribut {0} est incorrect pour le tag {1} d''après la
TLD indiquée
sjsp.error.tld_not_found=Impossible de localiser la TLD {0}
jsp.error.webxml_not_found=Impossible de localiser le fichier web.xml
-jsp.cmd_line.usage=Usage: jsptoservlet [-o path/to/outputDirectory]
[-keepgenerated] \
+jsp.cmd_line.usage=Usage: jsptoservlet [-dd path/to/outputDirectory]
[-keepgenerated] \
.jsp files
jsp.message.cp_is=Le Classpath {0} est: {1}
jsp.error.unable.to_load_taghandler_class=Impossible de charger la classe
gestionnaire de tag {0} car {1}
1.24 +2 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_ja.properties
Index: messages_ja.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_ja.properties,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- messages_ja.properties8 Nov 2002 19:42:56 - 1.23
+++ messages_ja.properties2 Dec 2002 11:21:00 - 1.24
@@ -139,7 +139,7 @@
jsp.error.bad_attribute=\u6307\u5b9a\u3055\u308c\u305fTLD\u306b\u3088\u308b\u3068\u3001\u5c5e\u6027
{0} \u306f\u7121\u52b9\u3067\u3059
jsp.error.tld_not_found=TLD {0} \u304c\u898b\u3064\u304b\u308a\u307e\u305b\u3093
jsp.error.webxml_not_found=web.xml\u304c\u898b\u3064\u304b\u308a\u307e\u305b\u3093
-jsp.cmd_line.usage=\u4f7f\u7528\u6cd5: jsptoservlet [-o
\u51fa\u529b\u30c7\u30a3\u30ec\u30af\u30c8\u30ea\u306e\u30d1\u30b9] [-keepgenerated]
.jsp\u30d5\u30a1\u30a4\u30eb\u7fa4
+jsp.cmd_line.usage=\u4f7f\u7528\u6cd5: jsptoservlet [-dd
RE: Roadmap for Tomcat 5
Hi, Can someone please provide dates for the release of Tomcat 5? I realise there is nothing definite, but a ball-park date is what i am looking for. Is there an official roadmap someone can point me to? There can't be a final release until the servlet specification v2.4 is finalized. Keep track at http://jcp.org/aboutJava/communityprocess/first/jsr154/ I'd expect an alpha tomcat implementation of the above a couple of weeks after final publication of the standard ;) Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14993] New: - Possible obselete synchronized declaration
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=14993.
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=14993
Possible obselete synchronized declaration
Summary: Possible obselete synchronized declaration
Product: Tomcat 4
Version: 4.1.9
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I was looking at the class org.apache.catalina.session.ManagerBase where i noticed the
method
public synchronized Random getRandom() {
if (this.random == null) {
synchronized (this) {
if (this.random == null) { .
Isn't the synchronozed in the
method definition obselete and harmful for performance?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jasper DOM API
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]
DO NOT REPLY [Bug 14994] New: - https coyote connector leaving sockets in CLOSE_WAIT
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=14994. 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=14994 https coyote connector leaving sockets in CLOSE_WAIT Summary: https coyote connector leaving sockets in CLOSE_WAIT Product: Tomcat 4 Version: 4.1.12 Platform: Other OS/Version: HP-UX Status: NEW Severity: Critical Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Sockets are being left in the CLOSE_WAIT state. Over the period of a couple of days, 11 (on a very low load machine) will be left hanging, which reaches my acceptCount setting and no more connections will be accepted. I also have 11 Broken pipe IOExceptions, as described in bugzilla bug 4663, which I would assume is the root cause. I don't know what else I can do to diagnose this. It is obviously a critical issue, as I can bump up acceptCount, but sooner or later connections will not be accepted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config host.xml
jfclere 2002/12/02 07:09:09 Modified:webapps/tomcat-docs/config host.xml Log: Try to improve the Application Base related explainations. Revision ChangesPath 1.13 +3 -2 jakarta-tomcat-4.0/webapps/tomcat-docs/config/host.xml Index: host.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/host.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- host.xml 20 Mar 2002 12:33:01 - 1.12 +++ host.xml 2 Dec 2002 15:09:09 - 1.13 @@ -247,7 +247,8 @@ started, if the codeautoDeploy/code property is set to codetrue/code (which is the default value:/p ul -liAny XML file in this directory is assumed to contain a +liAny XML file in the directory defined by appBase +(emApplication Base/em directory) is assumed to contain a a href=context.htmlContext/a element (and its associated subelements) for a single web application. The codedocBase/code attribute of this codelt;Contextgt;/code element will typically @@ -260,7 +261,7 @@ is set to codefalse/code. If you redeploy an updated WAR file, be sure to delete the expanded directory when restarting Tomcat, so that the updated WAR file will be re-expanded./li -liAny subdirectory within the emapplication base directory/em +liAny subdirectory within the emApplication Base/em directory that appears to be an unpacked web application (that is, it contains a code/WEB-INF/web.xml/code file) will receive an automatically generated a href=context.htmlContext/a element, even if this -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat appache request parameters getting lost
M wrote: Hi, I'm using apache 1.3.26 with the mod_jk connector to tomcat 4.1.12 The below jsp includes a servet which is unable to access the parameters on the request url e.g. http://host.net/testInclude.jsp?test=test Removing a line from the test comment or changing the flush=true to flush=false can both make it work, but I don't understand why. It does seem to be very buffer related and very dependant on size of text before the include. This problem only occurs when using tomcat through apache and is not reproducible with tomcat alone. Should I have raised this as a bug? I'm not sure quite where to file it. I guess the ajp connector? Any comments gratefully received -- 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: Tomcat App. Dev. Guide
On Mon, 2 Dec 2002 [EMAIL PROTECTED] wrote: Date: Mon, 2 Dec 2002 15:22:47 +1100 From: [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Tomcat App. Dev. Guide I've been meaning to ask ... is there a single pdf or single html (.tar?) version of this document? At the moment there is not ... but it wouldn't be all that hard to create an XSLT stylesheet that combined the existing pages. Longer term, a more formal document publishing system (stylebook or docbook or ...) would be appropriate for this document, as well as the other Tomcat documentation. I'd like to download it and print it out. Regards, Matt Craig -- 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-02 17:27 --- I am using the mod_jk.dll (27-Mar-2002 05:46) available at the Tomcat download Page, but I can't find any version number. I put this together with Apache 1.3.26 and Tomcat 3.3 as well as 3.2. Since the directive in question is used within the Apache configuration file httpd.conf I was convinced this was a HTTP Server problem, not a tomcat problem. Apearently Apache forwards every request to Tomcat when the directive JkMount /*/servlet/* ajp12 (for instance) is set, ending up in unexpected 404's. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14943] - // style scriptlet comment with % on same line comments out the next out.write(...)
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=14943. 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=14943 // style scriptlet comment with % on same line comments out the next out.write(...) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-12-02 18:34 --- *** This bug has been marked as a duplicate of 13576 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13576] - // comments in % % java scriptlet don't compile correctly
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=13576. 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=13576 // comments in % % java scriptlet don't compile correctly [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-12-02 18:34 --- *** Bug 14943 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Error? org/apache/ajp/tomcat4/Ajp13Connector createProcessor()
Greetings,
We were noticing some 'No processor available' exceptions
associated with the Ajp13Connectors under heavy load.
I downloaded the Tomcat 4.0.6 connectors source and had
a look at the code responsible for creating a new processor to
handle an incoming Ajp13 socket connection from Apache.
In org.apache.ajp.tomcat4.Ajp13Connector.java, in the
createProcessor() method, I noticed that there was no logic
to handle the case if maxProcessors was configured to -1
for infinite processors. In the HttpConnector source, if
maxProcessors was -1, then it returned a newProcessor().
I modified this createProcessor() method to function in the
same manner and the Ajp13 No processor available
exceptions disappeared.
private Ajp13Processor createProcessor() {
synchronized (processors) {
if (processors.size() 0)
return ((Ajp13Processor) processors.pop());
if ((maxProcessors 0) (curProcessors maxProcessors))
return (newProcessor());
else {
if ((maxProcessors 0))// my new code returns a new
processor
return (newProcessor());// if maxProcessors is -1,
aka infinite.
else return (null);
// original else return result
}
}
}
My question then, is this a bug in the Ajp13Connector functionality?
Or is there some design reason to not allow the user to configure
the Ajp13Connector for infinite processors via the -1 option.
I couldn't locate any documentation that says Ajp13 connectors
cannot and should not be configured for infinite processors.
Thanks,
Eric Scroger
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] [Proposal] Adding an authorization interface
Jeanfrancois Arcand wrote: I would very much preffer a consistent mechanism for all the hooks in tomcat. In 3.3 there is one interface ( BaseInterceptor ) where all the possible hooks are defined ( with a number of problems we already know regarding ordering, but that's a different issue ). In 4.x Valves are used as the main extension mechanism, but also Listeners, Realms, Connectors and few other interfaces - and I would very much prefer a solution that is more consistent and simpler. Just downloaded 3.3 code base. I will take a look at the way it work. I not familiar with 3.3 code base. The important codebase to take a look at is Apache2 :-) You can also check axis, they have a very nice hook mechanism ( very similar with apache2 and everything else, but the java implementation is quite good ). Tomcat3.3 is a bit closer to apache1.3 modules ( one interface, one method per hook chain ), and it has the same limitations. The idea is quite simple: have a consistent API for all supported hooks. Chain + Handler or whatever name is used is fine. Both iterative and recursive ( Valve ) are fine ( and can be used in the same chain !). I agree. If It possible, I will come up with an ActionCode. If not, then we should use the Authorizer idea. I'm very sure it is possible ( with some extensions to Action maybe, but it's the same thing ). The pattern is used in a lot of projects and most servers I know. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Error? org/apache/ajp/tomcat4/Ajp13Connector createProcessor()
seems like a bug.
either way, I believe the org.apache.ajp package is deprecated.
-Original Message-
From: eric scroger [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 02, 2002 12:40 PM
To: Tomcat Developers List
Subject: Error? org/apache/ajp/tomcat4/Ajp13Connector
createProcessor()
Greetings,
We were noticing some 'No processor available' exceptions
associated with the Ajp13Connectors under heavy load.
I downloaded the Tomcat 4.0.6 connectors source and had
a look at the code responsible for creating a new processor to
handle an incoming Ajp13 socket connection from Apache.
In org.apache.ajp.tomcat4.Ajp13Connector.java, in the
createProcessor() method, I noticed that there was no logic
to handle the case if maxProcessors was configured to -1
for infinite processors. In the HttpConnector source, if
maxProcessors was -1, then it returned a newProcessor().
I modified this createProcessor() method to function in the
same manner and the Ajp13 No processor available
exceptions disappeared.
private Ajp13Processor createProcessor() {
synchronized (processors) {
if (processors.size() 0)
return ((Ajp13Processor) processors.pop());
if ((maxProcessors 0) (curProcessors maxProcessors))
return (newProcessor());
else {
if ((maxProcessors 0))// my new code
returns a new
processor
return (newProcessor());// if maxProcessors
is -1,
aka infinite.
else return (null);
// original else return result
}
}
}
My question then, is this a bug in the Ajp13Connector functionality?
Or is there some design reason to not allow the user to configure
the Ajp13Connector for infinite processors via the -1 option.
I couldn't locate any documentation that says Ajp13 connectors
cannot and should not be configured for infinite processors.
Thanks,
Eric Scroger
--
To unsubscribe, e-mail:
mailto:tomcat-dev- [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 Remy Beta or Stable. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15002] New: - 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 Summary: Tag files in different directories not belonging to different tag libraries Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Tag files located in different directories must belong to different implicit tag libraries. However, Jasper currently stores the corresponding tag handlers in the same directory (web-app-name/tagfiles/org/apache/jsp/tagfile/) and assigns them to the same package. For example, the tag handlers corresponding to /WEB-INF/tags/foo/test.tag and /WEB-INF/tags/bar/test.tag in a web application named webtest are both stored in scratch_dir/webtest/tagfiles/org/apache/jsp/tagfile/test.java -- 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|NEW |RESOLVED Resolution||FIXED Summary|Tag files in different |Tag files in different |directories not belonging to|directories not belonging to |different tag libraries |different tag libraries --- Additional Comments From [EMAIL PROTECTED] 2002-12-02 19:29 --- The path of a tag file is now reflected in the directory in which the corresponding tag handler is stored, and in the name of the package to which the tag handler is assigned. This change also avoids conflicts between tag files with the same name and path under /META-INF/tags/ and /WEB-INF/tags/, by adding meta or web, respectively, to the directory and package names of the respective tag handlers. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15003] New: - Tag pool size not configurable
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=15003. 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=15003 Tag pool size not configurable Summary: Tag pool size not configurable Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15003] - Tag pool size not configurable
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=15003. 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=15003 Tag pool size not configurable [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-12-02 19:42 --- Added init parameter named tagPoolSize. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14994] - https coyote connector leaving sockets in CLOSE_WAIT
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=14994. 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=14994 https coyote connector leaving sockets in CLOSE_WAIT [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-02 19:42 --- CLOSE_WAIT means that it's waiting for an ACK of the close. In most systems, you can configure the maximum amount of time that a socket remains in CLOSE_WAIT before it's forced close. However, I don't use HP-UX, so I don't know the command it uses. In any case, it's not something that Tomcat has any control over. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12787] - request.getRequestURI() returns garbage when included in some tags
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=12787. 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=12787 request.getRequestURI() returns garbage when included in some tags [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-12-02 19:44 --- Fixed in 4.1.14+ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14741] - TagFiles with same name in different tag directories overwrite the generated java files
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=14741. 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=14741 TagFiles with same name in different tag directories overwrite the generated java files [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-12-02 19:52 --- *** This bug has been marked as a duplicate of 15002 *** -- 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 CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-12-02 19:52 --- *** Bug 14741 has been marked as a duplicate of this bug. *** -- 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-02 20:08 --- This fix breaks ALL tag files with the latest checkout from cvs you get this if you run the Hello World tag file example : org.apache.jasper.JasperException: Unable to compile class for JSP at org.apache.jasper.JspCompilationContext.compile (JspCompilationContext.java:564) at org.apache.jasper.servlet.JspServletWrapper.loadTagFile (JspServletWrapper.java:207) at org.apache.jasper.compiler.TagFileProcessor.loadTagFile (TagFileProcessor.java:388) at org.apache.jasper.compiler.TagFileProcessor.access$000 (TagFileProcessor.java:83) at org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit (TagFileProcessor.java:430) at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1038) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:1554) at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:1596) at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:1602) at org.apache.jasper.compiler.Node$Root.accept(Node.java:345) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:1554) at org.apache.jasper.compiler.TagFileProcessor.loadTagFiles (TagFileProcessor.java:448) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:285) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:413) at org.apache.jasper.JspCompilationContext.compile (JspCompilationContext.java:558) at org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:289) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:194) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:277) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:490) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:996) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:191) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:151) at org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:496) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:490) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:996) at org.apache.catalina.core.StandardContext.invoke (StandardContext.java:2523) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:180) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:151) at org.apache.catalina.valves.ErrorDispatcherValve.invoke (ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:149) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:172) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:490) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:996) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:174) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:490) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:996) at org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:223) at
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
luehe 2002/12/02 12:08:55
Modified:jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
Added error codes/messages for 15002
Revision ChangesPath
1.63 +3 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.62
retrieving revision 1.63
diff -u -r1.62 -r1.63
--- messages.properties 2 Dec 2002 11:21:00 - 1.62
+++ messages.properties 2 Dec 2002 20:08:55 - 1.63
@@ -336,3 +336,5 @@
jsp.error.xml.invalidHighSurrogate = High surrogate bits in UTF-8 sequence must not
exceed 0x10 but found 0x{0}.
jsp.error.multiple.jspoutput = Cannot have multiple occurrences of
lt;jsp:outputgt;
jsp.error.attributes.not.allowed = {0} must not have any attributes
+jsp.error.tagfile.badSuffix=Missing \.tag\ suffix in tag file path {0}
+jsp.error.tagfile.illegalPath=Missing \/WEB-INF/tags\ or \/META-INF/tags\ in
tag file path {0}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.16] [VOTE] Stability rating
ballot [ ] Alpha [ ] Beta [X ] Stable (aka GA) /ballot -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4.1.10:NPE in catalina.core.StandardWrapper.allocate
Hi EveryBody I got an NPE exception in Tomcat 4.1.10/jdk 1.4.1_01 while reloading a servlet: Any idea how to bypass or fix this problem??? 2002-12-02 21:25:53 StandardContext[/primer]: Processing start(), current available=false 2002-12-02 21:25:53 StandardContext[/primer]: Configuring default Resources 2002-12-02 21:25:53 StandardContext[/primer]: Configuring non-privileged default Loader 2002-12-02 21:25:53 StandardContext[/primer]: Processing standard container startup 2002-12-02 21:25:53 WebappLoader[/primer]: Deploying class repositories to work directory C:\Program Files\Apache Group\Tomcat 4.1\work\Standalone\localhost\primer 2002-12-02 21:25:53 WebappLoader[/primer]: Deploy class files /WEB-INF/classes to D:\MyApp\Primer\WEB-INF\classes 2002-12-02 21:25:53 WebappLoader[/primer]: Reloading checks are enabled for this Context 2002-12-02 21:25:53 ContextConfig[/primer]: ContextConfig: Processing START 2002-12-02 21:25:53 StandardContext[/primer]: Setting deployment descriptor public ID to '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN' 2002-12-02 21:25:53 StandardContext[/primer]: Setting deployment descriptor public ID to '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN' 2002-12-02 21:25:53 ContextConfig[/primer]: Accumulating TLD resource paths 2002-12-02 21:25:53 ContextConfig[/primer]: Scanning taglib elements in web.xml 2002-12-02 21:25:53 ContextConfig[/primer]: Scanning TLDs in /WEB-INF subdirectory 2002-12-02 21:25:53 ContextConfig[/primer]: Scanning JARs in /WEB-INF/lib subdirectory 2002-12-02 21:25:53 ContextConfig[/primer]: Pipline Configuration: 2002-12-02 21:25:53 ContextConfig[/primer]: org.apache.catalina.core.StandardContextValve/1.0 2002-12-02 21:25:53 ContextConfig[/primer]: == 2002-12-02 21:25:53 NamingContextListener[/Standalone/localhost/primer]: Creating JNDI naming context 2002-12-02 21:25:53 NamingContextListener[/Standalone/localhost/primer]: Resource parameters for UserTransaction = null 2002-12-02 21:25:53 StandardManager[/primer]: Seeding random number generator class java.security.SecureRandom 2002-12-02 21:25:53 StandardManager[/primer]: Seeding of random number generator has been completed 2002-12-02 21:25:53 StandardContext[/primer]: Posting standard context attributes 2002-12-02 21:25:53 StandardContext[/primer]: Configuring application event listeners 2002-12-02 21:25:53 StandardContext[/primer]: Sending application start events 2002-12-02 21:25:53 StandardContext[/primer]: Starting filters 2002-12-02 21:25:53 StandardWrapper[/primer:default]: Loading container servlet default 2002-12-02 21:25:53 StandardWrapper[/primer:invoker]: Loading container servlet invoker 2002-12-02 21:25:53 StandardContext[/primer]: Starting completed 2002-12-02 21:25:57 StandardContext[/primer]: Mapping contextPath='/primer' with requestURI='/primer/myapp' and relativeURI='/myapp' 2002-12-02 21:25:57 StandardContext[/primer]: Trying exact match 2002-12-02 21:25:57 StandardContext[/primer]: Mapped to servlet 'MyApp Executive' with servlet path '/myapp' and path info 'null' and update=true 2002-12-02 21:26:00 StandardContext[/primer]: Mapping contextPath='/primer' with requestURI='/primer/myapp' and relativeURI='/myapp' 2002-12-02 21:26:00 StandardContext[/primer]: Trying exact match 2002-12-02 21:26:00 StandardContext[/primer]: Mapped to servlet 'MyApp Executive' with servlet path '/myapp' and path info 'null' and update=true 2002-12-02 21:26:00 StandardContext[/primer]: Mapping contextPath='/primer' with requestURI='/primer/myprog' and relativeURI='/myprog' 2002-12-02 21:26:00 StandardContext[/primer]: Trying exact match 2002-12-02 21:26:00 StandardContext[/primer]: Mapped to servlet 'myprog Kixlet' with servlet path '/myprog' and path info 'null' and update=true 2002-12-02 21:27:08 StandardContext[/primer]: Reloading this Context has started 2002-12-02 21:27:08 StandardContext[/primer]: Sending application stop events 2002-12-02 21:27:08 StandardContext[/primer]: Stopping filters 2002-12-02 21:27:08 WebappLoader[/primer]: Deploying class repositories to work directory C:\Program Files\Apache Group\Tomcat 4.1\work\Standalone\localhost\primer 2002-12-02 21:27:08 WebappLoader[/primer]: Deploy class files /WEB-INF/classes to D:\MyApp\Primer\WEB-INF\classes 2002-12-02 21:27:08 WebappLoader[/primer]: Reloading checks are enabled for this Context 2002-12-02 21:27:08 NamingContextListener[/Standalone/localhost/primer]: Creating JNDI naming context 2002-12-02 21:27:08 NamingContextListener[/Standalone/localhost/primer]: Resource parameters for UserTransaction = null 2002-12-02 21:27:08 StandardContext[/primer]: Configuring application event listeners 2002-12-02 21:27:08 StandardContext[/primer]: Sending application start events 2002-12-02 21:27:08 StandardContext[/primer]: Starting filters 2002-12-02 21:27:08 StandardWrapper[/primer:default]: Loading container servlet default 2002-12-02 21:27:08 StandardWrapper[/primer:invoker]: Loading
RE: [4.1.16] [VOTE] Stability rating
Haven't had time load/test 4.1.16 yet, but have the hierarchical class loader issues been resolved? As of 4.1.15, I get ClassNotFound errors when starting tomcat. Getting an error message when I start Tomcat 4.1.12 on Solaris 8 SPARC: 15750 [main] ERROR server.JkMain - Can't create apr java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory at org.apache.jk.apr.AprImpl.clinit(AprImpl.java:340) rest of stack trace deleted Paul : -Original Message- : From: Jeanfrancois Arcand [mailto:[EMAIL PROTECTED]] : Sent: Monday, December 02, 2002 3:24 PM : To: Tomcat Developers List : Subject: Re: [4.1.16] [VOTE] Stability rating : : : : : ballot : [ ] Alpha : [ ] Beta : [X ] Stable (aka GA) : /ballot : : : -- Jeanfrancois : : : : : -- : To unsubscribe, e-mail: : mailto:tomcat-dev-: [EMAIL PROTECTED] : For : additional commands, : e-mail: mailto:[EMAIL PROTECTED] : Paul J. Brzezinski ([EMAIL PROTECTED]).vcf Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Error? org/apache/ajp/tomcat4/Ajp13Connector createProcessor()
Thanks.
I figured it was a bug. Unless anyone has any other information to the
contrary,
I'm going to file a bug report today.
Seeing the Ajp package is deprecated, are the Warp connectors fairly stable?
The documentation for the Warp connectors is weak (FIXME's) and incomplete
when compared to the Ajp documentation.
Eric
Kevin Seguin wrote:
seems like a bug.
either way, I believe the org.apache.ajp package is deprecated.
-Original Message-
From: eric scroger [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 02, 2002 12:40 PM
To: Tomcat Developers List
Subject: Error? org/apache/ajp/tomcat4/Ajp13Connector
createProcessor()
Greetings,
We were noticing some 'No processor available' exceptions
associated with the Ajp13Connectors under heavy load.
I downloaded the Tomcat 4.0.6 connectors source and had
a look at the code responsible for creating a new processor to
handle an incoming Ajp13 socket connection from Apache.
In org.apache.ajp.tomcat4.Ajp13Connector.java, in the
createProcessor() method, I noticed that there was no logic
to handle the case if maxProcessors was configured to -1
for infinite processors. In the HttpConnector source, if
maxProcessors was -1, then it returned a newProcessor().
I modified this createProcessor() method to function in the
same manner and the Ajp13 No processor available
exceptions disappeared.
private Ajp13Processor createProcessor() {
synchronized (processors) {
if (processors.size() 0)
return ((Ajp13Processor) processors.pop());
if ((maxProcessors 0) (curProcessors maxProcessors))
return (newProcessor());
else {
if ((maxProcessors 0))// my new code
returns a new
processor
return (newProcessor());// if maxProcessors
is -1,
aka infinite.
else return (null);
// original else return result
}
}
}
My question then, is this a bug in the Ajp13Connector functionality?
Or is there some design reason to not allow the user to configure
the Ajp13Connector for infinite processors via the -1 option.
I couldn't locate any documentation that says Ajp13 connectors
cannot and should not be configured for infinite processors.
Thanks,
Eric Scroger
--
To unsubscribe, e-mail:
mailto:tomcat-dev- [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]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Bootstrap.java
costin 2002/12/02 13:33:12
Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java
Log:
Few changes to make Bootstrap useable as an MBean ( via modeler )
This allows tomcat to be embeded using its own class loader hierarchy
( i.e. the embedding app will not need to have tomcat classes in the
main loader ).
Given that most of the admin operations will be exposed via MBeans
there is little need for the app to see tomcat internals. However
some interfaces or classes may be needed. This can be tuned by adding
classes and libs to the parent loader.
In general all tomcat .jars should work in either parent loader or in
the server loader.
Revision ChangesPath
1.9 +26 -9
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- Bootstrap.java2 Dec 2002 10:38:11 - 1.8
+++ Bootstrap.java2 Dec 2002 21:33:12 - 1.9
@@ -1,8 +1,4 @@
/*
- * $Header$
- * $Revision$
- * $Date$
- *
*
*
* The Apache Software License, Version 1.1
@@ -195,8 +191,9 @@
/**
* Initialize daemon.
*/
-private void init()
-throws Exception {
+public void init()
+throws Exception
+{
// Set Catalina path
setCatalinaHome();
@@ -290,6 +287,7 @@
*/
public void start()
throws Exception {
+if( catalinaDaemon==null ) init();
Method method = catalinaDaemon.getClass().getMethod(start, null);
method.invoke(catalinaDaemon, null);
@@ -338,6 +336,17 @@
}
+public boolean getAwait()
+throws Exception
+{
+Class paramTypes[] = new Class[0];
+Object paramValues[] = new Object[0];
+Method method =
+catalinaDaemon.getClass().getMethod(getAwait, paramTypes);
+Boolean b=(Boolean)method.invoke(catalinaDaemon, paramValues);
+return b.booleanValue();
+}
+
/**
* Destroy the Catalina Daemon.
@@ -388,6 +397,14 @@
}
+public void setCatalinaHome(String s) {
+System.setProperty( catalina.home, s );
+}
+
+public void setCatalinaBase(String s) {
+System.setProperty( catalina.base, s );
+}
+
/**
* Set the codecatalina.base/code System property to the current
@@ -424,7 +441,7 @@
/**
* Get the value of the catalina.home environment variable.
*/
-protected static String getCatalinaHome() {
+public static String getCatalinaHome() {
return System.getProperty(catalina.home,
System.getProperty(user.dir));
}
@@ -433,7 +450,7 @@
/**
* Get the value of the catalina.base environment variable.
*/
-protected static String getCatalinaBase() {
+public static String getCatalinaBase() {
return System.getProperty(catalina.base, getCatalinaHome());
}
--
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 TldLocationsCache.java
kinman 2002/12/02 14:26:23
Modified:jasper2/src/share/org/apache/jasper/compiler
TldLocationsCache.java
Log:
- Patch by [EMAIL PROTECTED] (Petr Jiricka)
Fix 14854: Allow redeploying tag libraries from the same jar,
do not lock the jar files on Windows
Revision ChangesPath
1.9 +50 -24
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TldLocationsCache.java
Index: TldLocationsCache.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TldLocationsCache.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- TldLocationsCache.java9 Oct 2002 18:25:39 - 1.8
+++ TldLocationsCache.java2 Dec 2002 22:26:23 - 1.9
@@ -134,15 +134,30 @@
private boolean initialized;
private ServletContext ctxt;
+private boolean redeployMode;
//*
// Constructor and Initilizations
public TldLocationsCache(ServletContext ctxt) {
+this(ctxt, false);
+}
+
+/** Constructs a new instance of TldLocationsCache.
+ * @param ctxt the servlet context of the web application in which Jasper
+ * is running
+ * @param redeployMode if true, then the compiler will allow redeploying
+ * a tag library from the same jar, at the expense of slowing down the server
+ * a bit. Note that this may only work on JDK 1.3.1_01a and later, because
+ * of JDK bug 4211817 fixed in this release.
+ * If redeployMode is false, a faster but less capable mode will be used.
+ */
+public TldLocationsCache(ServletContext ctxt, boolean redeployMode) {
this.ctxt = ctxt;
- mappings = new Hashtable();
- tlds = new Hashtable();
- initialized = false;
+this.redeployMode = redeployMode;
+mappings = new Hashtable();
+tlds = new Hashtable();
+initialized = false;
}
private void init() {
@@ -247,6 +262,9 @@
url = new URL(jar: + url.toString() + !/);
JarURLConnection conn =
(JarURLConnection) url.openConnection();
+if (redeployMode) {
+conn.setUseCaches(false);
+}
jarFile = conn.getJarFile();
Enumeration entries = jarFile.entries();
while (entries.hasMoreElements()) {
@@ -255,32 +273,40 @@
if (!name.startsWith(META-INF/)) continue;
if (!name.endsWith(.tld)) continue;
stream = jarFile.getInputStream(entry);
-String uri = parseTldForUri(resourcePath, stream);
-if (uri != null) {
-mappings.put(uri, new String[]{ resourcePath, name });
+try {
+String uri = parseTldForUri(resourcePath, stream);
+if (uri != null) {
+mappings.put(uri, new String[]{ resourcePath, name });
+}
+}
+finally {
+if (stream != null) {
+try {
+stream.close();
+} catch (Throwable t) {}
+}
}
}
-// FIXME @@@
-// -- it seems that the JarURLConnection class caches JarFile
-// objects for particular URLs, and there is no way to get
-// it to release the cached entry, so
-// there's no way to redeploy from the same JAR file. Wierd.
} catch (Exception ex) {
-if (stream != null) {
-try {
-stream.close();
-} catch (Throwable t) {
- // ignore
- }
-}
-if (jarFile != null) {
-try {
-jarFile.close();
-} catch (Throwable t) {
- // ignore
- }
+if (!redeployMode) {
+// if not in redeploy mode, close the jar in case of an error
+if (jarFile != null) {
+try {
+jarFile.close();
+} catch (Throwable t) { /* ignore */ }
+}
}
throw new JasperException(ex);
+}
+finally {
+if (redeployMode) {
+// if in redeploy mode, always close the jar
+if (jarFile != null) {
+try {
+jarFile.close();
+} catch (Throwable t) { /* ignore */ }
+
DO NOT REPLY [Bug 14854] - Allow redeploying tag libraries from the same jar, do not lock the jar files on Windows
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=14854. 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=14854 Allow redeploying tag libraries from the same jar, do not lock the jar files on Windows --- Additional Comments From [EMAIL PROTECTED] 2002-12-02 22:31 --- Patch applied. I notice that redeployMode is not on by default; should we? Also, does this patch fixes the problems in the bug report? If so, please update bugzilla. If not, what are the problems that was not addressed? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AW: euro character problem with tomcat compression Filter
Which version of Tomcat 4 are you using? I believe character encoding was fixed since 4.1.6. Amy Sergio wrote: The problem I comment, did not occurs before setting on the compressionFilter. I've changed also the request.setCharacterEncoding to iso-8859-15 and still works bad. The response object dont have a method to set the character encoding, but I can add a header: wrappedResponse.addHeader(charset,iso-8859-15) but this also dont works. How to change the character enconding that gzip uses ? Other idea ? Thx, Sergio. - Original Message - From: Torsten Fohrer [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 11:26 AM Subject: AW: AW: euro character problem with tomcat compression Filter ok... but if you set response content-type to text/html; charset: iso-8859-15, pages shows correctly with euro symbols in konqueror, netscape 4, ie and so on...if you have a font that contains it. -Ursprüngliche Nachricht- Von: Martin Algesten [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 28. November 2002 10:17 An: Tomcat Developers List Betreff: Re: AW: euro character problem with tomcat compression Filter And failing that perhaps cp1252 if you are a windowz kind of guy. I find this page helpful: http://czyborra.com/charsets/iso8859.html Martin On Thu, 2002-11-28 at 07:46, Torsten Fohrer wrote: sorry, iso-8859-15 -Ursprüngliche Nachricht- Von: Torsten Fohrer [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 28. November 2002 08:28 An: 'Tomcat Developers List' Betreff: AW: euro character problem with tomcat compression Filter try, to set the response encoding to 8559-15 cu Torsten -Ursprüngliche Nachricht- Von: Sergio [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 27. November 2002 21:18 An: 'Tomcat Developers List' Betreff: euro character problem with tomcat compression Filter Hí techies! I'm having problems adding the tomcat compression Filter version 4.0.3 to my webapp. Some characters (like euro symbol ) that are printed in my jsp page with a method which return a field of a MSSQLServer table, are printed with the '?' symbol. I've modified the CompressionFilter.java servlet and modified the code. Before the call of doFilter method I set the request to my encoding: request.setCharacterEncoding(iso-8859-1); chain.doFilter(request, response); But this also does not work. Any solution or idea ? Sorry for my English. Thanks, Sergio -- 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] -- 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]
DO NOT REPLY [Bug 15009] New: - Classloading behavior does not follow specification/documentation
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=15009.
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=15009
Classloading behavior does not follow specification/documentation
Summary: Classloading behavior does not follow
specification/documentation
Product: Tomcat 4
Version: 4.1.12
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The changes in the class loading behavior introduced in WebappClassLoader from
version 1.34 to 1.35 break with the servlet specification and the current Tomcat
documentation. Primarily, since WebappClassLoader version 1.35 Tomcat tries to
load any class with the system class loader first, ignoring the delegate-Flag
and the possible existence of the class in the web application's context. The
important code fragments in WebappClassLoader.java look like this:
Version 1.34
// If a system class, use system class loader
if( name.startsWith(java.) ) {
ClassLoader loader = system;
clazz = loader.loadClass(name);
if (clazz != null) {
if (resolve)
...
Since version 1.35
--
// (0.2) Try loading the class with the system class loader, to prevent
// the webapp from overriding J2SE classes
try {
clazz = system.loadClass(name);
if (clazz != null) {
if (resolve)
resolveClass(clazz);
...
According to the specification it ...is recommended that the application
classloader be implemented in such a way that classes packaged within the WAR
are able to override classes residing in container-wide library JARs..
In addition, the change made in 1.35 will load any non-system class present in
system classpath _before_ checking the delegation flag, which clearly conflicts
with the current Tomcat documentation.
The changed class loading behavior is especially crucial in connection with the
aspects of isolation and self-containedness of web application. That is, each
web application should be able to provide its own implementations of classes (as
long as these classes don't belong to a system package). Independent of the
target web container's environment it should be guaranteed that the
application's classes are loaded and used prior to any other implementation.
--
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 PageContextImpl.java
luehe 2002/12/02 17:58:36
Modified:jasper2/src/share/org/apache/jasper/runtime
PageContextImpl.java
Log:
Fixed Bugtraq 4787293: JspContext.popBody and Jsp/PageContext.pushBody don't
update out attribute
Revision ChangesPath
1.37 +12 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java
Index: PageContextImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- PageContextImpl.java 27 Nov 2002 02:31:29 - 1.36
+++ PageContextImpl.java 3 Dec 2002 01:58:36 - 1.37
@@ -530,6 +530,10 @@
outs[depth].setWriter(writer);
out = outs[depth];
+ // Update the value of the out attribute in the page scope
+ // attribute namespace of this PageContext
+ setAttribute(OUT, out);
+
return outs[depth];
}
@@ -540,6 +544,11 @@
} else {
out = baseOut;
}
+
+ // Update the value of the out attribute in the page scope
+ // attribute namespace of this PageContext
+ setAttribute(OUT, out);
+
return out;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServlet.java
kinman 2002/12/02 18:08:31
Modified:jasper2/src/share/org/apache/jasper/servlet JspServlet.java
Log:
- Comment on why jsp_precompile=false behaves like jsp_precompile=true. :)
Revision ChangesPath
1.14 +8 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java
Index: JspServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- JspServlet.java 22 Oct 2002 10:13:19 - 1.13
+++ JspServlet.java 3 Dec 2002 02:08:31 - 1.14
@@ -182,6 +182,11 @@
if (value.equals(true)) {
return (true); // ?jsp_precompile=true
} else if (value.equals(false)) {
+ // Spec says if jsp_precompile=false, the request should not
+ // be delivered to the JSP page; the easiest way to implement
+ // this is to set the flag to true, and precompile the page anyway.
+ // This still conforms to the spec, since it says the
+ // precompilation request can be ignored.
return (true); // ?jsp_precompile=false
} else {
throw new ServletException(Cannot have request parameter +
--
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 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/Response.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/Constants.java Index: Constants.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/Constants.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- Constants.java10 Oct 2002 09:45:30 - 1.3 +++ Constants.java3 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/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.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 02:29:14 - 1.12 @@ -261,7 +261,18 @@ */ protected boolean included = false; + +/** + * The characterEncoding flag + */ +private boolean isCharacterEncodingSet = false; + +/** + * The contextType flag + */ +private boolean isContentTypeSet = false; + /** * The error flag. */ @@ -313,6 +324,8 @@ appCommitted = false; included = false;
Re: CreateContext Error using Tomcat Admin
PLEASE do not cross-post messages to both TOMCAT-DEV and TOMCAT-USER. Your series of questions have been user related, and are appropriate on TOMCAT-USER. They are not appropriate on TOMCAT-DEV, which is about the development of Tomcat itself. Craig On Mon, 2 Dec 2002, Laxmikanth M.S. wrote: Date: Mon, 2 Dec 2002 12:27:21 +0530 From: Laxmikanth M.S. [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: CreateContext Error using Tomcat Admin Hi, I have added a new host and trying to add context but I get the below mentioned error. The following below attributes are used docbase - webapps/site/mysite path - /sinsite - Error - HTTP Status 500 - Error invoking operation createStandardContext type Status report message Error invoking operation createStandardContext description The server encountered an internal error (Error invoking operation createStandardContext) that prevented it from fulfilling this request. Apache Tomcat/4.1.12 * Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. * -- 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: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 Constants.java CoyoteResponse.java
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 02:29:14 - 1.12 @@ -261,7 +261,18 @@ */ protected boolean included = false; + +/** + *
DO NOT REPLY [Bug 15009] - Classloading behavior does not follow specification/documentation
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=15009. 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=15009 Classloading behavior does not follow specification/documentation [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 06:47 --- The behavior described in the spec is only a recommendation. That recommendation does not happen to be implementable. -- 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
Pae Choi wrote: 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. 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) Ok, fine. And why wasn't the webapp deployed ? Remy -- 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
I have not looked the source code yet. And I won't have time for it for a while. Wasn't the exception in the previous message enough to trace the cause? I will provide you a full log if you think that will help. Pae Pae Choi wrote: 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. 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) Ok, fine. And why wasn't the webapp deployed ? 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]
DO NOT REPLY [Bug 15009] - Classloading behavior does not follow specification/documentation
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=15009. 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=15009 Classloading behavior does not follow specification/documentation --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 07:37 --- Nevertheless, there are some good reasons for this recommondetion (i.e. isolation and self-containedness for web applications) and it seems to make more sense than the current implementation, which delutes the concept of encapsulated application contexts. Since, there was a sound implementation in previous versions of Tomcat (and several other application servers implement the class loading likewise), there must have been good resons to change the behavior so fundamentally. Without starting a big discussion, what are these reasons? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15009] - Classloading behavior does not follow specification/documentation
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=15009. 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=15009 Classloading behavior does not follow specification/documentation --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 07:47 --- Yes, it is definitely one of those good ideas which never really works in the real world. The previous implementation was sound, except that it used to break in a lot of cases. The system class loader only contains the bare minimum (actually, it only contains the J2SE classes, as well as the system extensions). The spec also states that overriding the J2SE classes is never allowed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
