DO NOT REPLY [Bug 29779] New: - Package Path wrong at admin class SetCharacterEncodingFilter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29779. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29779 Package Path wrong at admin class SetCharacterEncodingFilter Summary: Package Path wrong at admin class SetCharacterEncodingFilter Product: Tomcat 5 Version: 5.0.25 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] HEy, At Admin the Class SetCharcterEncodingFilter has wrong package path. regards Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29779] - Package Path wrong at admin class SetCharacterEncodingFilter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29779. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29779 Package Path wrong at admin class SetCharacterEncodingFilter --- Additional Comments From [EMAIL PROTECTED] 2004-06-24 06:01 --- Created an attachment (id=11938) correct package path - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29780] New: - Why we need a jkMain static attibute?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29780.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29780
Why we need a jkMain static attibute?
Summary: Why we need a jkMain static attibute?
Product: Tomcat 5
Version: 5.0.25
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Connector:Coyote
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hey,
I see following code at JkMain
public JkMain()
{
JkMain.jkMain=this;
modules.put(channelSocket, org.apache.jk.common.ChannelSocket);
...
}
..
public static JkMain getJkMain() {
return jkMain;
}
...
But nobody use this code and I think we not need this dependency!
Every Service. AJP connector can have its own jkMain env and nothing must be shared.
regards
peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 changes
The problem could be in the shm. On some platforms the shm remains hunging until reboot. The apr-1.0 has introduced a new function apr_shm_remove(), for removing a named shared memory segment. MT. -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 7:52 PM To: Tomcat Developers List Subject: Re: jk2 changes jean-frederic clere wrote: It works on my machine (Apache/2.1.0-dev (Unix) DAV/2 mod_jk2/2.0.5-dev) May be that is a problem with IPV6: Use 127.0.0.1 instead of localhost. Problem fixed. That was odd. Rebooted the machine and it started working. I'm investigating further but it seems unlikely that it was a jk2 issue. Thanks for the input. -- Andy Armstrong - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
DO NOT REPLY [Bug 29780] - Why we need a jkMain static attibute?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29780. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29780 Why we need a jkMain static attibute? [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Minor --- Additional Comments From [EMAIL PROTECTED] 2004-06-24 06:44 --- Among all of the little cleanups that can be done for the JK Connector, this has to be one of the smallest ;-). The design of the JK Connector is that you only ever need one. And since you can't specify the 'jk2.properties' file for the Connector, you are limited to only the simplest setups if you define more than one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29780] - Why we need a jkMain static attibute?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29780.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29780
Why we need a jkMain static attibute?
--- Additional Comments From [EMAIL PROTECTED] 2004-06-24 07:23 ---
Hey William,
I can setup more then one jk2.properties and used different jk2 Configurations.
Service name=Customerfirst
Connector port=8009 jkHome=${catalina.base}/conf/first protocol=AJP/1.3/
...
/Service
Service name=Customersecond
Connector port=8109 jkHome=${catalina.base}/conf/second protocol=AJP/1.3/
/Service
Directory layout
$[catalina.base}/conf/first/conf/jk2.properties
$[catalina.base}/conf/second/conf/jk2.properties
It works for my hosting project.
I can't see a dependency between the different connectors.
I find it strange that the implementation search the
jk2.properties at a subdirectory conf and etc!
What is the UseCase for the JkMain.main method?
==
Yep, this thing is one of the simples problems and I have
start a deep code review at the current code base. Now I am will start some
smaller refactorings. But I hope a have time to change more.
regards
peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29778] - Embedded does not function as documented (works in v4 fine)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29778 Embedded does not function as documented (works in v4 fine) [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Normal --- Additional Comments From [EMAIL PROTECTED] 2004-06-24 07:35 --- Please submit a patch or at least a detailed test case. All the maintainers of that class are now using JMX for embedding or (apparently) workarounds, so we're not going to address small glitches. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29778] - Embedded does not function as documented (works in v4 fine)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29778.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29778
Embedded does not function as documented (works in v4 fine)
--- Additional Comments From [EMAIL PROTECTED] 2004-06-24 07:44 ---
For the last part of your report: the code for Embedded.setCatalinaBase is (of
course):
public void setCatalinaBase( String s ) {
System.setProperty( catalina.base, s);
}
So, sorry, it's not implemented in some magic-fancy way, but that's not going to
change.
About the first part, are you using JDK 1.4 ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29778] - Embedded does not function as documented (works in v4 fine)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29778 Embedded does not function as documented (works in v4 fine) --- Additional Comments From [EMAIL PROTECTED] 2004-06-24 07:48 --- Yes, testing with 1.4.1_05 and 1.4.2_04 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 changes
Mladen Turk wrote: The problem could be in the shm. On some platforms the shm remains hunging until reboot. The apr-1.0 has introduced a new function apr_shm_remove(), for removing a named shared memory segment. Ahah! Yes, that would make sense I think although I didn't notice any diagnostics about it. Unfortunately the phorensics have been destroyed now so it'll have to remain 'just one of those things' :) -- Andy Armstrong - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29778] - Embedded does not function as documented (works in v4 fine)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29778 Embedded does not function as documented (works in v4 fine) --- Additional Comments From [EMAIL PROTECTED] 2004-06-24 08:01 --- Please at least prepare a test case. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29763] - The encoding of jsp document
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29763. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29763 The encoding of jsp document [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |Medium - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29763] - The encoding of jsp document
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29763. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29763 The encoding of jsp document --- Additional Comments From [EMAIL PROTECTED] 2004-06-24 11:48 --- This issue blocks a issue for jsp editor in the Netbeans IDE. http://www.netbeans.org/issues/show_bug.cgi?id=43269 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please describe the new Logger System at cvs head.
Hello Remy, I have problems to configure the new logger system. Can you send a log4J example to demonstrate the new commons-log Logger concept. How I can configure a log4J system? I have no success with add log4j.jar and log4j.xml to system class path via setclasspath.bat set CLASSPATH=%JAVA_HOME%\lib\tools.jar;%BASEDIR%\bin\log4j.jar;%BASEDIR%\bin I see only the commons logging default messages. Only my webapp find the log4j.jar and log4j.xml at my common/lib and common/classes But I want see the server messages The Logger names are: Tomcat.enginename Tomcat.enginename.hostname Tomcat.enginename.hostname.contextname correct? Regards peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please describe the new Logger System at cvs head.
Peter Rossbach wrote: Hello Remy, I have problems to configure the new logger system. Can you send a log4J example to demonstrate the new commons-log Logger concept. How I can configure a log4J system? I have no success with add log4j.jar and log4j.xml to system class path via setclasspath.bat set CLASSPATH=%JAVA_HOME%\lib\tools.jar;%BASEDIR%\bin\log4j.jar;%BASEDIR%\bin I see only the commons logging default messages. Only my webapp find the log4j.jar and log4j.xml at my common/lib and common/classes But I want see the server messages The Logger names are: Tomcat.enginename Tomcat.enginename.hostname Tomcat.enginename.hostname.contextname correct? There's no difference with using log4j with the current Tomcat 5.0.x (which I've never done, sorry), except that there are a few more categories. The c-l-api JAR which is in bin doesn't include the log4j wrapper, this could be the cause of the problems. It's funny to always see you looking for trouble with odd builds ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Race condition in SystemLogHandler.java
I posted this in tomcat-user but it's probably more appropriate here.
-- Forwarded message --
Date: Tue, 22 Jun 2004 16:16:36 -0400 (EDT)
From: Ron Gomes [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Race condition in SystemLogHandler.java
The org.apache.tomcat.util.log.SystemLogHandler class (source code in
jakarta-tomcat-connectors-4.1.30) handles, among other things,
capturing of System.out and System.err so that they can be redirected
to an application's log file. It makes use of another class
(CaptureLog) to hold the captured data, and maintains a stack of unused
CaptureLog instances to avoid creating new ones where possible.
This reuse stack is global to the class and it looks like the use of
it is not thread-safe. The startCapture() method acquires a
CaptureLog() this way:
if (!reuse.isEmpty()) {
log = (CaptureLog)reuse.pop();
} else {
log = new CaptureLog();
}
There's a race between the call to isEmpty() and the call to pop().
We've been able to reliably elicit a java.util.EmptyStackException at
this point with an application under heavy load.
Replacing the above code with
synchronized (reuse) {
log = reuse.isEmpty() ? new CaptureLog() : (CaptureLog)reuse.pop();
}
eliminates the problem (with no effect on performance that we could
observe).
An alternative approach might be to catch the (rare)
EmptyStackException and treat it as equivalent to the isEmpty==true
case, but this seems cleaner.
There would seem to be no need to synchronize the code that pushes
old CaptureLog instances onto the reuse stack since java.util.Stack
is already synchronized.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please describe the new Logger System at cvs head.
Hello Remy, which logging system you used? I thing every host and application can have there own logging devices. My problem is: How can I configure dymamic logging device at runtime? For every new host or application With the old server.xml Logger element this was easy, but now you must known there concrete server technic log4j, JDK 1.4 or what ever The c-l-api JAR which is in bin doesn't include the log4j wrapper, this could be the cause of the problems. You mean, that I must add the commons-logging.jar to system-class path? Ohh, then I must changed the META-INF from bootstrap.jar, right? regards Peter PS: Some people (book writer) must be the early birds :-) Remy Maucherat schrieb: Peter Rossbach wrote: Hello Remy, I have problems to configure the new logger system. Can you send a log4J example to demonstrate the new commons-log Logger concept. How I can configure a log4J system? I have no success with add log4j.jar and log4j.xml to system class path via setclasspath.bat set CLASSPATH=%JAVA_HOME%\lib\tools.jar;%BASEDIR%\bin\log4j.jar;%BASEDIR%\bin I see only the commons logging default messages. Only my webapp find the log4j.jar and log4j.xml at my common/lib and common/classes But I want see the server messages The Logger names are: Tomcat.enginename Tomcat.enginename.hostname Tomcat.enginename.hostname.contextname correct? There's no difference with using log4j with the current Tomcat 5.0.x (which I've never done, sorry), except that there are a few more categories. The c-l-api JAR which is in bin doesn't include the log4j wrapper, this could be the cause of the problems. It's funny to always see you looking for trouble with odd builds ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://www.webapp.de/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please describe the new Logger System at cvs head.
Hello Remy,
I have made a deeper look at the current cvs logger code stage:
1) ContainerBase.getLogger()
With first getLogger call the Log was build with a strange name!
public Log getLogger() {
if (logger != null)
return (logger);
String loggerName = null;
Container current = this;
while (current != null) {
loggerName = [ + current.getName() + ]
+ ((loggerName != null) ? (. + loggerName) : );
current = current.getParent();
}
logger = LogFactory.getLog(Tomcat. + loggerName);
return (logger);
}
I think this can be done at init().
head
Context loggerTomcat.[context].[host].[engine]
Host.logger Tomcat.[host].[engine]
Engine.Logger Tomcat.[engine]
Strange syntax...
other convention?:
Context loggerTomcat.Logger.engine.host.context
Tomcat.Logger.engine.host.ROOT
Host.logger Tomcat.Logger.engine.host
Engine.Logger Tomcat.Logger.engine
Current getLogger method not handle ROOT Context!
2) StandardContext.start()
L4051..
String logName = tomcat. + getParent().getName() + . +
(.equals(getName()) ? ROOT : getName()) + .Context;
log = org.apache.commons.logging.LogFactory.getLog(logName);
Hmm.
Why the complete init() phase goes to Log with name
StandardContext.class and
after start all logging goes to tomcat.contextname.Context ?
other name convention Tomcat.Context.contextname
I thing we must do that, before any code from StandardContext generate
log message.
The CatalinaBase use Tomcat and StandarContext used tomcat with
lowercase...
I hope this analyse help to refactor more :-(
regards
peter
Peter Rossbach schrieb:
Hello Remy,
which logging system you used?
I thing every host and application can have there own logging devices.
My problem is:
How can I configure dymamic logging device at runtime?
For every new host or application
With the old server.xml Logger element this was easy, but now you must
known
there concrete server technic log4j, JDK 1.4 or what ever
The c-l-api JAR which is in bin doesn't include the log4j wrapper,
this could be the cause of the problems.
You mean, that I must add the commons-logging.jar to system-class path?
Ohh, then I must changed the META-INF from bootstrap.jar, right?
regards
Peter
PS: Some people (book writer) must be the early birds :-)
Remy Maucherat schrieb:
Peter Rossbach wrote:
Hello Remy,
I have problems to configure the new logger system.
Can you send a log4J example to demonstrate the new commons-log
Logger concept.
How I can configure a log4J system?
I have no success with add log4j.jar and log4j.xml to system class
path via setclasspath.bat
set
CLASSPATH=%JAVA_HOME%\lib\tools.jar;%BASEDIR%\bin\log4j.jar;%BASEDIR%\bin
I see only the commons logging default messages.
Only my webapp find the log4j.jar and log4j.xml at my common/lib and
common/classes
But I want see the server messages
The Logger names are:
Tomcat.enginename
Tomcat.enginename.hostname
Tomcat.enginename.hostname.contextname
correct?
There's no difference with using log4j with the current Tomcat 5.0.x
(which I've never done, sorry), except that there are a few more
categories.
The c-l-api JAR which is in bin doesn't include the log4j wrapper,
this could be the cause of the problems.
It's funny to always see you looking for trouble with odd builds ;)
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
J2EE Systemarchitekt und Tomcat Experte
http://objektpark.de/
http://www.webapp.de/
Am Josephsschacht 72, 44879 Bochum, Deutschland
Telefon: (49) 234 9413228
Mobil:(49) 175 1660884
E-Mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please describe the new Logger System at cvs head.
Peter Rossbach wrote:
Hello Remy,
I have made a deeper look at the current cvs logger code stage:
1) ContainerBase.getLogger()
With first getLogger call the Log was build with a strange name!
public Log getLogger() {
if (logger != null)
return (logger);
String loggerName = null;
Container current = this;
while (current != null) {
loggerName = [ + current.getName() + ]
+ ((loggerName != null) ? (. + loggerName) : );
current = current.getParent();
}
logger = LogFactory.getLog(Tomcat. + loggerName);
return (logger);
}
I think this can be done at init().
head
Context loggerTomcat.[context].[host].[engine]
Host.logger Tomcat.[host].[engine]
Engine.Logger Tomcat.[engine]
Strange syntax...
other convention?:
Context loggerTomcat.Logger.engine.host.context
Tomcat.Logger.engine.host.ROOT
Host.logger Tomcat.Logger.engine.host
Engine.Logger Tomcat.Logger.engine
Current getLogger method not handle ROOT Context!
Well, it's going to be a blank String, so []. It's unique, so it's fine.
I think the prerfix should be o.a.ca.core.ContainerBase. (= the
classname). Logger seems redundant (we know it's a Logger).
2) StandardContext.start()
L4051..
String logName = tomcat. + getParent().getName() + . +
(.equals(getName()) ? ROOT : getName()) + .Context;
log = org.apache.commons.logging.LogFactory.getLog(logName);
Hmm.
Why the complete init() phase goes to Log with name
StandardContext.class and
after start all logging goes to tomcat.contextname.Context ?
This needs to go.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Response.java Request.java
remm2004/06/24 08:28:28
Modified:catalina/src/share/org/apache/catalina/core
ContainerBase.java StandardContext.java
catalina/src/share/org/apache/catalina/authenticator
FormAuthenticator.java DigestAuthenticator.java
BasicAuthenticator.java SSLAuthenticator.java
AuthenticatorBase.java
catalina/src/share/org/apache/catalina/connector
Response.java Request.java
Log:
- More casting removals.
- Remove logger conflicts between ContainerBase and StandardContext.
- Redo ContainerBase.logName(), with new category names.
Revision ChangesPath
1.36 +21 -15
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java
Index: ContainerBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- ContainerBase.java23 Jun 2004 16:59:40 - 1.35
+++ ContainerBase.java24 Jun 2004 15:28:27 - 1.36
@@ -187,6 +187,12 @@
/**
+ * Associated logger name.
+ */
+protected String logName = null;
+
+
+/**
* The Manager implementation with which this Container is associated.
*/
protected Manager manager = null;
@@ -197,7 +203,7 @@
*/
protected Cluster cluster = null;
-
+
/**
* The human-readable name of this Container.
*/
@@ -371,14 +377,7 @@
if (logger != null)
return (logger);
-String loggerName = null;
-Container current = this;
-while (current != null) {
-loggerName = [ + current.getName() + ]
-+ ((loggerName != null) ? (. + loggerName) : );
-current = current.getParent();
-}
-logger = LogFactory.getLog(Tomcat. + loggerName);
+logger = LogFactory.getLog(logName());
return (logger);
}
@@ -1284,12 +1283,19 @@
*/
protected String logName() {
-String className = this.getClass().getName();
-int period = className.lastIndexOf(.);
-if (period = 0)
-className = className.substring(period + 1);
-return (className + [ + getName() + ]);
-
+if (logName != null) {
+return logName;
+}
+String loggerName = null;
+Container current = this;
+while (current != null) {
+loggerName = [ + current.getName() + ]
++ ((loggerName != null) ? (. + loggerName) : );
+current = current.getParent();
+}
+logName = ContainerBase.class.getName() + . + loggerName;
+return logName;
+
}
1.132 +3 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.131
retrieving revision 1.132
diff -u -r1.131 -r1.132
--- StandardContext.java 23 Jun 2004 13:51:35 - 1.131
+++ StandardContext.java 24 Jun 2004 15:28:27 - 1.132
@@ -117,7 +117,7 @@
extends ContainerBase
implements Context, Serializable
{
-private transient Log log = LogFactory.getLog(StandardContext.class);
+private static transient Log log = LogFactory.getLog(StandardContext.class);
// --- Constructors
@@ -4043,12 +4043,8 @@
throw new LifecycleException(Error initializaing , ex);
}
}
-
-String logName = tomcat. + getParent().getName() + . +
-(.equals(getName()) ? ROOT : getName()) + .Context;
-log = org.apache.commons.logging.LogFactory.getLog(logName);
-log.debug(Starting + logName);
+log.debug(Starting + (.equals(getName()) ? ROOT : getName()));
// Set JMX object name for proper pipeline registration
preRegisterJMX();
1.12 +11 -14
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java
Index: FormAuthenticator.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
---
DO NOT REPLY [Bug 29038] - HostConfig.deployWars() might not create context xml for auto-deployed .war files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29038. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29038 HostConfig.deployWars() might not create context xml for auto-deployed .war files --- Additional Comments From [EMAIL PROTECTED] 2004-06-24 15:45 --- Hey, this fix not work corret. with xml.mkdirs you generate a dircetory at conf/enginename/hostname/myapps.xml/ this is wrong and currently we can't autodeploy a new war with META-INf/context.xml -- At my server the conf/enginename/hostname directory generated at startup time. I think for new host this is not made. I have find a fix. Before extract the META-INF/context.xml we must check the configBase. regards peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29038] - HostConfig.deployWars() might not create context xml for auto-deployed .war files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29038. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29038 HostConfig.deployWars() might not create context xml for auto-deployed .war files --- Additional Comments From [EMAIL PROTECTED] 2004-06-24 15:46 --- Created an attachment (id=11942) Patch for lost configBase before autodeploy META-INF/context.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introduction
Hi, take a look at the current open bugs and submits patches. Someday one of us will propose you as committer, after looking at your patches :-) Thanks -- Jeanfrancois Felipe Leme wrote: Hi, My name is Felipe and I just joined the devs list recently, as I would like to more involved with Tomcat's development. Until now I just collaborated doing a few bug reports/patches (using the address nagoya AT felipeal DOT net) but now that I'm part of JSR-245 I'd like to help more (I'm also a committer for the Jakarta Taglibs project - my login at ASF is felipeal). Anyway, I'm just sending this email to offer my help if you need something specific (like fixing a bug or doing some tests, including the TCKs). Right now I'm just reading 'How Tomcat Works' and preparing myself to JavaOne - but once I get back from the conference, I could do more. Regards, Felipe PS: hopefully I can meet some of you guys/gals at JavaOne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Request.java CoyoteAdapter.java
remm2004/06/24 09:20:21
Modified:catalina/src/share/org/apache/catalina/valves
RequestFilterValve.java ErrorReportValve.java
PersistentValve.java AccessLogValve.java
catalina/src/share/org/apache/catalina/authenticator
Constants.java
catalina/src/share/org/apache/catalina/connector
Request.java CoyoteAdapter.java
Log:
- Last (?) round of casts removal.
Revision ChangesPath
1.7 +4 -14
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/RequestFilterValve.java
Index: RequestFilterValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/RequestFilterValve.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- RequestFilterValve.java 23 Jun 2004 08:24:56 - 1.6
+++ RequestFilterValve.java 24 Jun 2004 16:20:20 - 1.7
@@ -22,7 +22,6 @@
import java.util.ArrayList;
import javax.servlet.ServletException;
-import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletResponse;
import org.apache.catalina.connector.Request;
@@ -269,12 +268,8 @@
// Check the deny patterns, if any
for (int i = 0; i denies.length; i++) {
if (denies[i].match(property)) {
-ServletResponse sres = response.getResponse();
-if (sres instanceof HttpServletResponse) {
-HttpServletResponse hres = (HttpServletResponse) sres;
-hres.sendError(HttpServletResponse.SC_FORBIDDEN);
-return;
-}
+response.sendError(HttpServletResponse.SC_FORBIDDEN);
+return;
}
}
@@ -293,12 +288,7 @@
}
// Deny this request
-ServletResponse sres = response.getResponse();
-if (sres instanceof HttpServletResponse) {
-HttpServletResponse hres = (HttpServletResponse) sres;
-hres.sendError(HttpServletResponse.SC_FORBIDDEN);
-return;
-}
+response.sendError(HttpServletResponse.SC_FORBIDDEN);
}
1.20 +3 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java
Index: ErrorReportValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- ErrorReportValve.java 23 Jun 2004 13:51:34 - 1.19
+++ ErrorReportValve.java 24 Jun 2004 16:20:20 - 1.20
@@ -127,10 +127,8 @@
;
}
-ServletResponse sresponse = (ServletResponse) response;
-if (sresponse instanceof HttpServletResponse)
-((HttpServletResponse) sresponse).sendError
-(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
+response.sendError
+(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
}
1.8 +4 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/PersistentValve.java
Index: PersistentValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/PersistentValve.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- PersistentValve.java 23 Jun 2004 13:51:34 - 1.7
+++ PersistentValve.java 24 Jun 2004 16:20:20 - 1.8
@@ -21,7 +21,6 @@
import java.io.IOException;
import javax.servlet.ServletException;
-import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
@@ -102,7 +101,7 @@
StandardHost host = (StandardHost) getContainer();
Context context = request.getContext();
if (context == null) {
-((HttpServletResponse) response.getResponse()).sendError
+response.sendError
(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
sm.getString(standardHost.noContext));
return;
@@ -113,8 +112,7 @@
(context.getLoader().getClassLoader());
// Update the session last access time for our session (if any)
-HttpServletRequest hreq = (HttpServletRequest) request.getRequest();
-String sessionId = hreq.getRequestedSessionId();
+String sessionId = request.getRequestedSessionId();
AUTO {ICICICARE#008-116-469}Introduction
Thank you for writing to us. We assure you that we are working on your request and shall revert with an appropriate response soon.Meanwhile, should you want to speak with us, please feel free to call on our 24 hour Customer Care numbers. To help us serve you better, kindly mention your complete account number and any reference number you may have with respect to your query in all future correspondence. Kindly visit our website www.icicibank.com for comprehensive information on our products and services. With regards, Customer Care ICICI Bank Limited This communication being sent by ICICI Bank Ltd. is privileged and confidential, and is directed to and for the use of the addressee only. If this message reaches anyone other than the intended recipient, we request the reader not to reproduce, copy, disseminate or in any manner distribute it. We further request such recipient to notify us immediately by return email and delete the original message. ICICI Bank Ltd. does not guarantee the security of any information transmitted electronically and is not liable for the proper, timely and complete transmission thereof. Before opening any attachments please check them for viruses and defects.
Re: Please describe the new Logger System at cvs head.
Hello Remy,
with your Logger naming convention log4j not working
log4j:ERROR Parsing error on line 57 and column 99
log4j:ERROR Attribute value
org.apache.catalina.core.CatalinaBase.[].[localhost
].[Catalina] of type ID must be a name.
With this logger naming convention it works fine:
org.apache.catalina.core.ContainerBase.Catalina.localhost.ROOT
Patch
Index: catalina/src/share/org/apache/catalina/core/ContainerBase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java,v
retrieving revision 1.36
diff -u -r1.36 ContainerBase.java
--- catalina/src/share/org/apache/catalina/core/ContainerBase.java24
Jun 2004 15:28:27 -1.36
+++ catalina/src/share/org/apache/catalina/core/ContainerBase.java24
Jun 2004 16:49:23 -
@@ -36,18 +36,7 @@
import javax.naming.directory.DirContext;
import javax.servlet.ServletException;
-import org.apache.catalina.Cluster;
-import org.apache.catalina.Container;
-import org.apache.catalina.ContainerEvent;
-import org.apache.catalina.ContainerListener;
-import org.apache.catalina.Lifecycle;
-import org.apache.catalina.LifecycleException;
-import org.apache.catalina.LifecycleListener;
-import org.apache.catalina.Loader;
-import org.apache.catalina.Manager;
-import org.apache.catalina.Pipeline;
-import org.apache.catalina.Realm;
-import org.apache.catalina.Valve;
+import org.apache.catalina.*;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.util.LifecycleSupport;
@@ -1288,17 +1277,23 @@
}
String loggerName = null;
Container current = this;
+
while (current != null) {
-loggerName = [ + current.getName() + ]
+String theName;
+if(current instanceof StandardContext )
+ theName = .equals(current.getName()) ? ROOT :
current.getName();
+else
+ theName= current.getName();
+loggerName = theName
+ ((loggerName != null) ? (. + loggerName) : );
current = current.getParent();
}
logName = ContainerBase.class.getName() + . + loggerName;
return logName;
-
+
}
-
+
// JMX and Registration
protected String type;
protected String domain;
@@ -1310,7 +1305,7 @@
public ObjectName getJmxName() {
return oname;
}
-
+
public String getObjectName() {
if (oname != null) {
return oname.toString();
@@ -1326,7 +1321,7 @@
}
if( parent instanceof StandardEngine ) {
domain=((StandardEngine)parent).getDomain();
-}
+}
}
return domain;
}
@@ -1334,7 +1329,7 @@
public void setDomain(String domain) {
this.domain=domain;
}
-
+
public String getType() {
return type;
}
@@ -1405,9 +1400,9 @@
Container context=null;
Container host=null;
Container servlet=null;
-
+
StringBuffer suffix=new StringBuffer();
-
+
if( container instanceof StandardHost ) {
host=container;
} else if( container instanceof StandardContext ) {
@@ -1421,7 +1416,7 @@
if( context!=null ) {
String path=((StandardContext)context).getPath();
suffix.append(,path=).append((path.equals()) ? / : path);
-}
+}
if( host!=null ) suffix.append(,host=).append( host.getName() );
if( servlet != null ) {
String name=container.getName();
I have fix this and it works
logger
name=org.apache.catalina.core.ContainerBase.Catalina.localhost.ROOT
additivity=false
level value=DEBUG/
appender-ref ref=catalina/
/logger
OK, I muss changed the bootstrap.jar META-INF dependcies to
common-logging.jar instead commons-logging-api-jar
Copy common-logging.jar, log4j.jar and log4.xml to bin
delete commons-logging-api.jar
Change bootstrap.jar Manifest
Manifest-Version: 1.0
Main-Class: org.apache.catalina.startup.Bootstrap
Class-Path: jmx.jar commons-daemon.jar commons-logging.jar
Specification-Title: Catalina
Specification-Version: 1.0
Also change setclasspath.bat
set
CLASSPATH=%JAVA_HOME%\lib\tools.jar;%BASEDIR%\bin\log4j.jar;%BASEDIR%\bin
..
Only thing that not nice with this patch is new StandardContext dependency!
regards
Peter
Remy Maucherat schrieb:
Peter Rossbach wrote:
Hello Remy,
I have made a deeper look at the current cvs logger code stage:
1) ContainerBase.getLogger()
With first getLogger call the Log was build with a strange name!
public Log getLogger() {
if (logger != null)
return (logger);
String loggerName = null;
Container current = this;
while (current != null) {
loggerName = [ + current.getName() + ]
+ ((loggerName != null) ? (. +
Re: Please describe the new Logger System at cvs head.
Peter Rossbach wrote: Hello Remy, with your Logger naming convention log4j not working log4j:ERROR Parsing error on line 57 and column 99 log4j:ERROR Attribute value org.apache.catalina.core.CatalinaBase.[].[localhost ].[Catalina] of type ID must be a name. With this logger naming convention it works fine: Sorry, I see nothing in the log4j docs that says that org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[] (BTW, I know who you are now: you really must be Yoda; Hmmm, a bug I think there is) is an invalid logger name. The replacement name you're proposing is bad, so I won't use it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please describe the new Logger System at cvs head.
Hey Remy, please look at the log4j.dtd jakarta-log4j-1.2.8\src\java\org\apache\log4j\xml\log4j.dtd All names from name attributes are from type ID http://www.w3.org/TR/REC-xml/ XML Attribute from type ID can not have this characters [] Please, accept my change or made a log4j.dtd/ XML conform implementation. Thanx, Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hello Remy, with your Logger naming convention log4j not working log4j:ERROR Parsing error on line 57 and column 99 log4j:ERROR Attribute value org.apache.catalina.core.CatalinaBase.[].[localhost ].[Catalina] of type ID must be a name. With this logger naming convention it works fine: Sorry, I see nothing in the log4j docs that says that org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[] (BTW, I know who you are now: you really must be Yoda; Hmmm, a bug I think there is) is an invalid logger name. The replacement name you're proposing is bad, so I won't use it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://www.webapp.de/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introduction
Hi Jean Francois, On Thu, 24 Jun 2004 09:03:43 -0700, Jean-Francois Arcand wrote: take a look at the current open bugs and submits patches. Someday one Yes, I know that's the way. But Tomcat has many bugs (as it's a popular software), so I was wondering if there were any bugs in particular that should be addressed first - if there isn't any, then I will do a traditional bugzilla browsing (looking for votes, severity, etc.). us will propose you as committer, after looking at your patches :-) Sure, following the traditional ASF meritocracy way (I know the drill, been there already :-) Regards, Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Valide o seu email
A Panda Software Portual está a proteger-se contra as mensagens de email indesejadas o chamado Spam. Pedimos desculpa pelo incómodo mas o seu email não está ainda validado. Para que os seus emails sejam considerados como válidos, por favor, valide-se nesta página: http://www.startcontrol.com/GoodMail/Validate.asp?I=EOSWKFHXVDLQYJV Só necessita de se validar uma única vez. Todos os emails subsequentes serão considerados válidos. Obrigado. Panda Software Portugal
Re: Valide o seu email
A Panda Software Portual está a proteger-se contra as mensagens de email indesejadas o chamado Spam. Pedimos desculpa pelo incómodo mas o seu email não está ainda validado. Para que os seus emails sejam considerados como válidos, por favor, valide-se nesta página: http://www.startcontrol.com/GoodMail/Validate.asp?I=EOTCREVLNRWDYJO Só necessita de se validar uma única vez. Todos os emails subsequentes serão considerados válidos. Obrigado. Panda Software Portugal
Re: Valide o seu email
A Panda Software Portual está a proteger-se contra as mensagens de email indesejadas o chamado Spam. Pedimos desculpa pelo incómodo mas o seu email não está ainda validado. Para que os seus emails sejam considerados como válidos, por favor, valide-se nesta página: http://www.startcontrol.com/GoodMail/Validate.asp?I=EOTINEXQLCEQCIF Só necessita de se validar uma única vez. Todos os emails subsequentes serão considerados válidos. Obrigado. Panda Software Portugal
DO NOT REPLY [Bug 29763] - The encoding of jsp document
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29763. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29763 The encoding of jsp document [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-06-24 19:04 --- Fixed so that an error is reported if the page encoding specified in the page directive is different from that specified in, or autodetected from, the XML prolog of a JSP document. From your message: there are three places where the encoding for a jsp document can be set Notice that the page encoding of a JSP document is *always* derived from the XML prolog, as mandated by the XML specification. It may also be *described* in the page directive or page-encoding config element, as long as the values specified there match the value derived from the XML prolog. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Validator.java
luehe 2004/06/24 12:04:41
Modified:jasper2/src/share/org/apache/jasper/compiler Validator.java
Log:
Fixed Bugzilla 29763 (The encoding of jsp document)
Revision ChangesPath
1.118 +47 -35
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
Index: Validator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
retrieving revision 1.117
retrieving revision 1.118
diff -u -r1.117 -r1.118
--- Validator.java12 May 2004 01:14:59 - 1.117
+++ Validator.java24 Jun 2004 19:04:41 - 1.118
@@ -188,10 +188,6 @@
err.jspError(n, jsp.error.page.multi.pageencoding);
// 'pageEncoding' can occur at most once per file
pageEncodingSeen = true;
- /*
- * Report any encoding conflict, treating UTF-16,
- * UTF-16BE, and UTF-16LE as identical.
- */
comparePageEncodings(value, n);
}
}
@@ -256,37 +252,53 @@
// from the tag file in which the directive appeared
}
- /*
- * Compares the page encoding specified in the 'pageEncoding'
- * attribute of the page directive with the encoding explicitly
- * specified in the XML prolog (only for XML syntax) and the encoding
- * specified in the JSP config element whose URL pattern matches the
- * page, and throws an error in case of a mismatch.
- */
- private void comparePageEncodings(String pageDirEnc,
- Node.PageDirective n)
- throws JasperException {
-
- String configEnc = n.getRoot().getJspConfigPageEncoding();
-
- if (configEnc != null !pageDirEnc.equals(configEnc)
- (!pageDirEnc.startsWith(UTF-16)
- || !configEnc.startsWith(UTF-16))) {
- err.jspError(n, jsp.error.config_pagedir_encoding_mismatch,
- configEnc, pageDirEnc);
- }
-
- if (n.getRoot().isXmlSyntax()
- n.getRoot().isEncodingSpecifiedInProlog()) {
- String pageEnc = n.getRoot().getPageEncoding();
- if (!pageDirEnc.equals(pageEnc)
- (!pageDirEnc.startsWith(UTF-16)
- || !pageEnc.startsWith(UTF-16))) {
- err.jspError(n, jsp.error.prolog_pagedir_encoding_mismatch,
- pageEnc, pageDirEnc);
- }
- }
- }
+/*
+ * Compares page encodings specified in various places, and throws
+ * exception in case of page encoding mismatch.
+ *
+ * @param pageDirEnc The value of the pageEncoding attribute of the
+ * page directive
+ * @param pageDir The page directive node
+ *
+ * @throws JasperException in case of page encoding mismatch
+ */
+private void comparePageEncodings(String pageDirEnc,
+ Node.PageDirective pageDir)
+throws JasperException {
+
+Node.Root root = pageDir.getRoot();
+String configEnc = root.getJspConfigPageEncoding();
+
+/*
+ * Compare the 'pageEncoding' attribute of the page directive with
+ * the encoding specified in the JSP config element whose URL
+ * pattern matches this page.
+ * Treat UTF-16, UTF-16BE, and UTF-16LE as identical.
+ */
+if (configEnc != null !pageDirEnc.equals(configEnc)
+ (!pageDirEnc.startsWith(UTF-16)
+|| !configEnc.startsWith(UTF-16))) {
+err.jspError(pageDir,
+ jsp.error.config_pagedir_encoding_mismatch,
+ configEnc, pageDirEnc);
+}
+
+/*
+ * Compare the 'pageEncoding' attribute of the page directive with
+ * the encoding specified in the XML prolog (only for XML syntax!).
+ * Treat UTF-16, UTF-16BE, and UTF-16LE as identical.
+ */
+ if (root.isXmlSyntax()) {
+ String pageEnc = root.getPageEncoding();
+if (!pageDirEnc.equals(pageEnc)
+ (!pageDirEnc.startsWith(UTF-16)
+|| !pageEnc.startsWith(UTF-16))) {
+err.jspError(pageDir,
+ jsp.error.prolog_pagedir_encoding_mismatch,
+ pageEnc, pageDirEnc);
+}
+}
+}
}
/**
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
luehe 2004/06/24 12:05:12
Modified:jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
Fixed Bugzilla 29763 (The encoding of jsp document)
Revision ChangesPath
1.147 +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.146
retrieving revision 1.147
diff -u -r1.146 -r1.147
--- messages.properties 25 May 2004 21:28:40 - 1.146
+++ messages.properties 24 Jun 2004 19:05:12 - 1.147
@@ -327,7 +327,7 @@
jsp.error.tagdirective.badbodycontent=Invalid body-content ({0}) in tag directive
jsp.error.simpletag.badbodycontent=The TLD for the class {0} specifies an invalid
body-content (JSP) for a SimpleTag.
jsp.error.config_pagedir_encoding_mismatch=Page-encoding specified in
jsp-property-group ({0}) is different from that specified in page directive ({1})
-jsp.error.prolog_pagedir_encoding_mismatch=Page-encoding specified in XML prolog
({0}) is different from that specified in page directive ({1})
+jsp.error.prolog_pagedir_encoding_mismatch=Page-encoding derived from XML prolog
({0}) is different from that specified in page directive ({1})
jsp.error.prolog_config_encoding_mismatch=Page-encoding specified in XML prolog
({0}) is different from that specified in jsp-property-group ({1})
jsp.error.attribute.custom.non_rt_with_expr=According to TLD or attribute directive
in tag file, attribute {0} does not accept any expressions
jsp.error.attribute.standard.non_rt_with_expr=The {0} attribute of the {1} standard
action does not accept any expressions
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Valide o seu email
A Panda Software Portual está a proteger-se contra as mensagens de email indesejadas o chamado Spam. Pedimos desculpa pelo incómodo mas o seu email não está ainda validado. Para que os seus emails sejam considerados como válidos, por favor, valide-se nesta página: http://www.startcontrol.com/GoodMail/Validate.asp?I=EOVBPEUIAKYITIR Só necessita de se validar uma única vez. Todos os emails subsequentes serão considerados válidos. Obrigado. Panda Software Portugal
Re: Valide o seu email
A Panda Software Portual está a proteger-se contra as mensagens de email indesejadas o chamado Spam. Pedimos desculpa pelo incómodo mas o seu email não está ainda validado. Para que os seus emails sejam considerados como válidos, por favor, valide-se nesta página: http://www.startcontrol.com/GoodMail/Validate.asp?I=EOVFGEPIAKYITIH Só necessita de se validar uma única vez. Todos os emails subsequentes serão considerados válidos. Obrigado. Panda Software Portugal
Re: Please describe the new Logger System at cvs head.
Except that I can't see why you would want to use the 'Tomcat.[].[Catalina].[localhost].[myapp]' name except in a 'category' element. Here, the name is defined to be CDATA so you should be fine (or it is a log4j bug :). - Original Message - From: Peter Rossbach [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, June 24, 2004 11:02 AM Subject: Re: Please describe the new Logger System at cvs head. Hey Remy, please look at the log4j.dtd jakarta-log4j-1.2.8\src\java\org\apache\log4j\xml\log4j.dtd All names from name attributes are from type ID http://www.w3.org/TR/REC-xml/ XML Attribute from type ID can not have this characters [] Please, accept my change or made a log4j.dtd/ XML conform implementation. Thanx, Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hello Remy, with your Logger naming convention log4j not working log4j:ERROR Parsing error on line 57 and column 99 log4j:ERROR Attribute value org.apache.catalina.core.CatalinaBase.[].[localhost ].[Catalina] of type ID must be a name. With this logger naming convention it works fine: Sorry, I see nothing in the log4j docs that says that org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[] (BTW, I know who you are now: you really must be Yoda; Hmmm, a bug I think there is) is an invalid logger name. The replacement name you're proposing is bad, so I won't use it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://www.webapp.de/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please describe the new Logger System at cvs head.
Bill Barker wrote: Except that I can't see why you would want to use the 'Tomcat.[].[Catalina].[localhost].[myapp]' name except in a 'category' element. Here, the name is defined to be CDATA so you should be fine (or it is a log4j bug :). Maybe Peter is stressed up because he's going to production with my stuff tomorrow or something ;) I think it's more consistent to use org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/] Log category names are even easier to change than JMX names, and since a refactoring just started, nothing is set in stone. There will be far more disruptive changes (I guess the changes just before were more disruptive already). I used that nested naming so that a logger category can be defined for a host and all its child contexts, respecting the semantics of the Catalina containers. (this does sound extremely obvious, it's probably a waste of time to write it) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java
remm2004/06/24 15:09:52
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
- Small tweak to the logger name for the root context.
Revision ChangesPath
1.133 +23 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.132
retrieving revision 1.133
diff -u -r1.132 -r1.133
--- StandardContext.java 24 Jun 2004 15:28:27 - 1.132
+++ StandardContext.java 24 Jun 2004 22:09:52 - 1.133
@@ -4715,6 +4715,28 @@
}
+/**
+ * Return the abbreviated name of this container for logging messsages
+ */
+protected String logName() {
+
+if (logName != null) {
+return logName;
+}
+String loggerName = ((getName() == null) || (getName().equals()))
+ ? [/] : ([ + getName() + ]);
+Container current = getParent();
+while (current != null) {
+loggerName = [ + current.getName() + ]
++ ((loggerName != null) ? (. + loggerName) : );
+current = current.getParent();
+}
+logName = ContainerBase.class.getName() + . + loggerName;
+return logName;
+
+}
+
+
// Private Methods
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please describe the new Logger System at cvs head.
hello Remy, hello Peter, I am following your dicussion about the new logging in the tomcat cvs. I have some question about this changes: 1. Old configurations in the server.xml and context.xml is not valid, because the old logger with Logger ... / is defined? 2. How can I automatically configure Log4J to add new categrories if the a host/context added or removed? 3. At wich place the logs will be written if the configuration is not properly set? Our comapny uses the tomcat as a hosting solution for our customers. Every customer has access to his own logs. The logger can be set of the coustomers themselves in their context.xml, of course. Is this behaviour broken after your refactoring is done? Best regards Thorsten -- Thorsten Kamann Email: [EMAIL PROTECTED] ICQ: 40746578 Yahoo: ThorQue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please describe the new Logger System at cvs head.
Sorry, Can you configure a correct log4j.xml or log4j.properties with the current implementation? I have spend a lot of time today, but it not working. logger name=![CDATA[org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[]]] additivity=false level value=DEBUG/ appender-ref ref=catalina/ /logger The current log4j 1.2.8 Logger.name type is ID not CDATA ... log4j:ERROR Parsing error on line 58 and column 15 log4j:ERROR The value of attribute name associated with an element type logge r must not contain the '' character. log4j:ERROR Could not parse input source [EMAIL PROTECTED] org.xml.sax.SAXParseException: The value of attribute name associated with an element type logger must not contain the '' character. at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java :665) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java :616) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java :602) at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionCon verter.java:460) at org.apache.log4j.LogManager.clinit(LogManager.java:113) at org.apache.log4j.Logger.getLogger(Logger.java:85) at org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.jav a:229) at org.apache.commons.logging.impl.Log4JLogger.init(Log4JLogger.java:6 5) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct orAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC onstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactory Impl.java:529) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactory Impl.java:235) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactory Impl.java:209) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351) at org.apache.catalina.startup.Bootstrap.clinit(Bootstrap.java:53) log4j:WARN No appenders could be found for logger (org.apache.catalina.startup.C lassLoaderFactory). log4j:WARN Please initialize the log4j system properly. --- Also log4j.properties not working log4j.rootLogger=INFO, stdout log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n log4j.appender.catalina=org.apache.log4j.RollingFileAppender log4j.appender.catalina.File=../logs/catalina-dev.log log4j.appender.catalina.MaxFileSize=5Mb log4j.appender.catalina.MaxBackupIndex=10 log4j.appender.catalina.layout=org.apache.log4j.PatternLayout log4j.appender.catalina.layout.ConversionPattern=%p %t %c - %m%n log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[]= DEBUG, catalina --- Currently the Logger Logname ist very long org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[] ROOT App org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[myapps] normal web App -- with my patch it works. ;-) .--- Also I thing the the current implementation is not compatible with all Tomcat 5 releases How we want migrate all the current Tomcat projects? How we made Logger configuration at runtime? Hmm. :-( regards Peter Bill Barker schrieb: Except that I can't see why you would want to use the 'Tomcat.[].[Catalina].[localhost].[myapp]' name except in a 'category' element. Here, the name is defined to be CDATA so you should be fine (or it is a log4j bug :). - Original Message - From: Peter Rossbach [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, June 24, 2004 11:02 AM Subject: Re: Please describe the new Logger System at cvs head. Hey Remy, please look at the log4j.dtd jakarta-log4j-1.2.8\src\java\org\apache\log4j\xml\log4j.dtd All names from name attributes are from type ID http://www.w3.org/TR/REC-xml/ XML Attribute from type ID can not have this characters [] Please, accept my change or made a log4j.dtd/ XML conform implementation. Thanx, Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hello Remy, with your Logger naming convention log4j not working log4j:ERROR Parsing error on line 57 and column 99 log4j:ERROR Attribute value org.apache.catalina.core.CatalinaBase.[].[localhost ].[Catalina] of type ID must be a name. With this logger naming convention it works fine: Sorry, I see nothing in the log4j docs that says that org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[] (BTW, I know who you are now: you really must be Yoda; Hmmm, a bug I think there is) is an invalid logger
Re: Please describe the new Logger System at cvs head.
Thorsten Kamann wrote: hello Remy, hello Peter, I am following your dicussion about the new logging in the tomcat cvs. I have some question about this changes: 1. Old configurations in the server.xml and context.xml is not valid, because the old logger with Logger ... / is defined? 2. How can I automatically configure Log4J to add new categrories if the a host/context added or removed? 3. At wich place the logs will be written if the configuration is not properly set? Our comapny uses the tomcat as a hosting solution for our customers. Every customer has access to his own logs. The logger can be set of the coustomers themselves in their context.xml, of course. Is this behaviour broken after your refactoring is done? A lot of stuff will be broken in this branch. There was no way for me to continue improving Tomcat without breaking stuff. OTOH, I expect the relatively bug free 5.0.x branch to live for a long time, so don't plan upgrading (other than the connector refactoring, there won't be any major reason to upgrade existing installations; this branch is designed for new setups). About logging: - it is a mistake (nowadays) to define custom loggers in applications (JBoss doesn't, and yet it's far more complex); of course, an equally big mistake is to provide logging services in the Servlet API ;) - the big problem which I want to solve here is that logs are going to different places, which is wrong; now, all logs should go to commons-logging (or directly to the actual logger that commons-logging is wrapping) - this was halfway done already in 5.0.x Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please describe the new Logger System at cvs head.
Hello Remy, Remy Maucherat schrieb: Thorsten Kamann wrote: hello Remy, hello Peter, I am following your dicussion about the new logging in the tomcat cvs. I have some question about this changes: 1. Old configurations in the server.xml and context.xml is not valid, because the old logger with Logger ... / is defined? 2. How can I automatically configure Log4J to add new categrories if the a host/context added or removed? 3. At wich place the logs will be written if the configuration is not properly set? Our comapny uses the tomcat as a hosting solution for our customers. Every customer has access to his own logs. The logger can be set of the coustomers themselves in their context.xml, of course. Is this behaviour broken after your refactoring is done? A lot of stuff will be broken in this branch. There was no way for me to continue improving Tomcat without breaking stuff. OTOH, I expect the relatively bug free 5.0.x branch to live for a long time, so don't plan upgrading (other than the connector refactoring, there won't be any major reason to upgrade existing installations; this branch is designed for new setups). When this branch is so very different from the current 5.0.x, why ist thne name not 6.x? And why is there no chance to use the old configuration and redirects internal to the new logger implementation? About logging: - it is a mistake (nowadays) to define custom loggers in applications (JBoss doesn't, and yet it's far more complex); of course, an equally big mistake is to provide logging services in the Servlet API ;) This is only a dream. In a hosting enviroment every customer will logging different. We offer own logfiles with the Logger configuartion in the context.xml. This were broken, if your changes are kept. My greatest problem is the administration of the log4j configuration. Where - or better - how can I do this automatically. This question you don't answer? Is there a discussion done about this problem? Your logger solution is maybe is well solution for a development or company-intern-used tomcat installation but the UseCase Webhosting have been ignored. If I must administrate every customer logger manually this is very counterproductively. - the big problem which I want to solve here is that logs are going to different places, which is wrong; now, all logs should go to commons-logging (or directly to the actual logger that commons-logging is wrapping) What do you mean with different places. If you man different places the logs will be saved than can I say this is a normal behaviour. In Germany there is a admin tool called Confixx. This tool saves the logs in the home directory of the user. Than the user can view and load his logs with a normal ftp-client. Best regards Thorsten -- Thorsten Kamann Email: [EMAIL PROTECTED] ICQ: 40746578 Yahoo: ThorQue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please describe the new Logger System at cvs head.
Peter Rossbach wrote: Also I thing the the current implementation is not compatible with all Tomcat 5 releases How we want migrate all the current Tomcat projects? How we made Logger configuration at runtime? Hmm. :-( How about continuing using the Tomcat 5.0.x branch instead ? About the breakage: I have announced many times that there will be core changes in this new branch (although in the end, I think it will still be very similar from a user perspective - logging is sort of a special case, as the way it was done was quite broken :( ), as it is not possible to continue improving Tomcat without that. This branch is not intended for upgrades from 5.0.x given the lack of tangible benefits. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please describe the new Logger System at cvs head.
Thorsten Kamann wrote: When this branch is so very different from the current 5.0.x, why ist thne name not 6.x? Because it doesn't implement a new spec, and there's no release plan anyway at this time. This is only a dream. In a hosting enviroment every customer will logging different. We offer own logfiles with the Logger configuartion in the context.xml. This were broken, if your changes are kept. My greatest problem is the administration of the log4j configuration. Where - or better - how can I do this automatically. This question you don't answer? Is there a discussion done about this problem? Your logger solution is maybe is well solution for a development or company-intern-used tomcat installation but the UseCase Webhosting have been ignored. If I must administrate every customer logger manually this is very counterproductively. - the big problem which I want to solve here is that logs are going to different places, which is wrong; now, all logs should go to commons-logging (or directly to the actual logger that commons-logging is wrapping) What do you mean with different places. If you man different places the logs will be saved than can I say this is a normal behaviour. In Germany there is a admin tool called Confixx. This tool saves the logs in the home directory of the user. Than the user can view and load his logs with a normal ftp-client. Oh ok, so you're telling me that you expect your webapps/frameworks to log using four things then: - ServletContext.log(java.lang.Exception exception, java.lang.String msg) (deprecated one ;) ) - ServletContext.log(java.lang.String msg) - ServletContext.log(java.lang.String message, java.lang.Throwable throwable) (the all powerful one, you can do everything with that) - System.out.println if you did configure swallowOutput (I like that one :D ) I must be an idiot I think this is not the case. This discussion is closed from my side, since what you write doesn't make any sense. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please describe the new Logger System at cvs head.
About logging: - it is a mistake (nowadays) to define custom loggers in applications (JBoss doesn't, and yet it's far more complex); of course, an equally big mistake is to provide logging services in the Servlet API ;) This is only a dream. In a hosting enviroment every customer will logging different. We offer own logfiles with the Logger configuartion in the context.xml. This were broken, if your changes are kept. My greatest problem is the administration of the log4j configuration. Where - or better - how can I do this automatically. This question you don't answer? Is there a discussion done about this problem? Well, the discussion of administering the log4j configuration belongs on [EMAIL PROTECTED] However, I'm sure that the Tomcat 5.5 docs will likely have examples (and, yes, patches are always welcome :). Either that, or Ceki is going to be selling a lot of copies of his book ;-). Your logger solution is maybe is well solution for a development or company-intern-used tomcat installation but the UseCase Webhosting have been ignored. If I must administrate every customer logger manually this is very counterproductively. Actually, with the JMX support in log4j, I would guess that Remy's changes will make life much easier for the Webhosting crowd. If there is interest (meaning patches :), then the admin webapp could even be extended to help with the configuration. - the big problem which I want to solve here is that logs are going to different places, which is wrong; now, all logs should go to commons-logging (or directly to the actual logger that commons-logging is wrapping) What do you mean with different places. If you man different places the logs will be saved than can I say this is a normal behaviour. In Germany there is a admin tool called Confixx. This tool saves the logs in the home directory of the user. Than the user can view and load his logs with a normal ftp-client. Best regards Thorsten -- Thorsten Kamann Email: [EMAIL PROTECTED] ICQ: 40746578 Yahoo: ThorQue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please describe the new Logger System at cvs head.
Hello Remy, Remy Maucherat schrieb: I must be an idiot I think this is not the case. This discussion is closed from my side, since what you write doesn't make any sense. Hmm, is this your kind to hold a discussion? I think that my question are qualified because I must do this things everyday. In addition to this, to end a discussion on the way you do is not the right way to handle request and comments to project-related items. But maybe this is the reason why the tomcat project has so few active commiters and volunteers that submitting patches? Regards Thorsten -- Thorsten Kamann Email: [EMAIL PROTECTED] ICQ: 40746578 Yahoo: ThorQue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] improvements to JNDI documentation
http://issues.apache.org/bugzilla/show_bug.cgi?id=29584 Index: jndi-resources-howto.xml === RCS file: /home/cvspublic/jakarta-tomcat-catalina/webapps/docs/jndi-resources-howto.xml,v retrieving revision 1.5 diff -u -r1.5 jndi-resources-howto.xml --- jndi-resources-howto.xml9 Aug 2003 18:59:22 - 1.5 +++ jndi-resources-howto.xml19 Jun 2004 00:53:36 - @@ -17,10 +17,29 @@ section name=Introduction pTomcat 5 provides a JNDI strongInitialContext/strong implementation -instance to web applications running under it, in a manner that is compatible +instance for each web application running under it, in a manner that is compatible with those provided by a a href=http://java.sun.com/j2ee;Java2 Enterprise -Edition/a application server. Entries in this codeInitialContext/code -are configured in the code$CATALINA_HOME/conf/server.xml/code file, and +Edition/a application server. The J2EE standard provides a standard set of elements in +the code/WEB-INF/web.xml/code file to reference resources; resources referenced +in these elements must be defined in an application-server-specific configuration. +/p +pFor Tomcat 5, these entries in per-web-application codeInitialContext/code +are configured in the +codestronglt;Contextgt;/strong/code or codestronglt;DefaultContextgt;/strong/code +elements of the a href=config/server.htmlcodestronglt;Servergt;/strong/code/a +element. The codestronglt;Contextgt;/strong/code element can be specified in either +code$CATALINA_HOME/conf/server.xml/code or, preferably, +the per-web-application file code$CATALINA_HOME/conf/HOSTNAME/WEBAPP.xml/code. +codestronglt;DefaultContextgt;/strong/code must be specified in +code$CATALINA_HOME/conf/server.xml/code. +/p +pTomcat 5 maintains a separate namespace of global resources for the entire server. +These are configured in the a href=config/globalresources.html +codestronglt;GlobalNameingResourcesgt;/strong/code/a element of +code$CATALINA_HOME/conf/server.xml/code. You may expose these resources to +web applications by using codestronglt;ResourceLinkgt;/strong/code elements. +/p +pThe resource defined in these elements may be referenced by the following elements in the web application deployment descriptor (code/WEB-INF/web.xml/code) of your web application:/p ul @@ -39,7 +58,7 @@ pThe codeInitialContext/code is configured as a web application is initially deployed, and is made available to web application components (for -read-only access). All configured entries and resources will be placed in +read-only access). All configured entries and resources are placed in the codejava:comp/env/code portion of the JNDI namespace, so a typical access to a resource - in this case, to a JDBC codeDataSource/code - would look something like this:/p @@ -75,8 +94,8 @@ section name=Configuring JNDI Resources pEach available JNDI Resource is configured based on inclusion of the -following elements in the code$CATALINA_HOME/conf/server.xml/code -file:/p +following elements in the codestronglt;Contextgt;/strong/code or +codestronglt;DefaultContextgt;/strong/code elements:/p ul lia href=config/context.html#Environment Entrieslt;Environmentgt;/a - Configure names and values for scalar environment entries that will be @@ -94,11 +113,15 @@ used, as well as JavaBeans properties used to configure that resource factory./li lia href=config/context.html#Resource Linkslt;ResourceLinkgt;/a - -Add a link to a resource defined in the global JNDI context./li +Add a link to a resource defined in the global JNDI context. Use resource links +to give a web application access to a resource defined in +thea href=config/globalresources.htmllt;GlobalNamingResourcesgt;/a +child element of the a href=config/server.htmllt;Servergt;/a +element./li /ul pAny number of these elements may be nested inside a -a href=config/context.htmllt;Contextgt;/a element (to be associated +a href=config/context.htmllt;Contextgt;/a element(to be associated only with that particular web application) or inside a a href=config/defaultcontext.htmllt;DefaultContextgt;/a element (used to set the default configuration characteristics for automatically @@ -116,7 +139,8 @@ the resource elements described above to the a href=config/globalresources.htmllt;GlobalNamingResourcesgt;/a child element of the a href=config/server.htmllt;Servergt;/a -element./p +element and using a a href=config/context.html#Resource Linkslt;ResourceLinkgt;/a to +include it in the per-web-application context./p /section Index: globalresources.xml === RCS file: /home/cvspublic/jakarta-tomcat-catalina/webapps/docs/config/globalresources.xml,v retrieving revision 1.2 diff -u -r1.2 globalresources.xml --- globalresources.xml 15 Jan 2003 03:40:44 - 1.2 +++ globalresources.xml 19 Jun 2004 01:16:25 -
DO NOT REPLY [Bug 29763] - The encoding of jsp document
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29763. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29763 The encoding of jsp document [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-06-25 01:52 --- Hi Petr, I think I am going to have to revert my patch, and close this issue as not a bug instead. The reason you didn't see any error is because your JSP document did not contain any XML prolog with an explicit encoding declaration. This is to ensure backwards compatibility with JSP 1.2. Otherwise, JSP documents that used to be valid in JSP 1.2 will no longer work in JSP 2.0, which the expert group decided was unacceptable. This is why the JSP 2.0 spec says: It is a translation-time error to name different encodings in two or more of the following: the XML prolog /text declaration of a JSP document [...]. In your example, there was no explicit encoding declaration in the prolog, and therefore you should not expect to see any error. Let me know what you think. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs/config logger.xml
billbarker2004/06/24 20:30:31 Modified:webapps/docs/config logger.xml Log: Replacing documentation on the extinct Catalina Logger with a start on logging. This doesn't belong here, but I don't feel like finding a place for it right now. This is mostly so that there is something for the early adopters have something to follow, and maybe stop whining on the dev list ;-). Revision ChangesPath 1.4 +83 -116 jakarta-tomcat-catalina/webapps/docs/config/logger.xml Index: logger.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/logger.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- logger.xml15 Jan 2003 03:40:44 - 1.3 +++ logger.xml25 Jun 2004 03:30:31 - 1.4 @@ -16,12 +16,10 @@ section name=Introduction - pA strongLogger/strong element represents a destination for - logging, debugging, and error messages (including stack tracebacks) - for a Catalina container (a href=engine.htmlEngine/a, - a href=host.htmlHost/a, or a href=context.htmlContext/a). - In addition, Loggers associated with an Engine or a Host are automatically - inherited by lower-level containers, unless explicitly overridden./p + pTomcat uses the + a href=http://jakarta.apache.org/commons/logging/;Commons Logging/a + package to implement all logging. This includes the logging defined + by codeServletContext.log/code./p pIf you are interested in producing access logs like a web server does (for example, to run hit count analysis software), you will want to configure @@ -30,9 +28,6 @@ a href=host.html#Access LogsHost/a, or a href=context.html#Access LogsContext/a./p - pFor a more in-depth description of the class loader hierarchy - that is implemented by Catalina, see strongFIXME - Reference/strong./p - blockquoteem pThe description below uses the variable name $CATALINA_HOME to refer to the directory into which you have installed Tomcat 5, @@ -46,121 +41,93 @@ /section -section name=Attributes - - subsection name=Common Attributes - -pAll implementations of strongLogger/strong -support the following attributes:/p - -attributes - - attribute name=className required=true -pJava class name of the implementation to use. This class must -implement the codeorg.apache.catalina.Logger/code interface./p - /attribute - - attribute name=verbosity required=false -pThe verbosity level for this logger. Messages with a higher -verbosity level than the specified value will be silently ignored. -Available levels are 0 (fatal messages only), 1 (errors), 2 -(warnings), 3 (information), and 4 (debug). If not specified, the -default value will be 1 (error)./p - -pstrongNOTE/strong - Only messages logged with an explicit -verbosity level are compared to this value. Messages logged with -no explicit verbosity level are logged unconditionally./p - /attribute - -/attributes - - /subsection - - - subsection name=Standard Implementation - -pUnlike most Catalina components, there are several standard -strongLogger/strong implementations available. As a result, -the codeclassName/code attribute MUST be used to select the -implementation you wish to use./p - -h3File Logger (org.apache.catalina.logger.FileLogger)/h3 - -pThe strongFile Logger/strong records all logged messages to -disk file(s) in a specified directory. The actual filenames of the -log files are created from a configured prefix, the current date in --MM-DD format, and a configured suffix. On the first logged -message after midnight each day, the current log file will be closed -and a new file opened for the new date, without having to shut down -Catalina in order to perform this switch./p - -pThe File Logger supports the following attributes:/p - -attributes - - attribute name=directory required=false -pAbsolute or relative pathname of a directory in which log files -created by this logger will be placed. If a relative path is -specified, it is interpreted as relative to $CATALINA_HOME. If -no directory attribute is specified, the default value is logs -(relative to $CATALINA_HOME)./p - /attribute - - attribute name=prefix required=false -pThe prefix added to the start of each log file's name. If not -specified, the default value is catalina.. To specify no prefix, -use a zero-length string./p - /attribute - - attribute name=suffix required=false -pThe suffix added to
