DO NOT REPLY [Bug 7654] New: - Exception in preInit - java.lang.ClassCastException
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=7654.
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=7654
Exception in preInit - java.lang.ClassCastException
Summary: Exception in preInit - java.lang.ClassCastException
Product: Tomcat 3
Version: 3.3.1 Final
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Minor
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I switched from Tomcat 3.2.1 to latest 3.3.1 final and got exception;
here is Tomcat's output:
-
2002-04-01 09:35:31 - ServerXmlReader: Config=$TOMCAT_HOME\conf\server.xml
2002-04-01 09:35:31 - PathSetter: home=C:\Program Files\Tomcat
2002-04-01 09:35:31 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-12
7.0.0.1.xml
2002-04-01 09:35:31 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-ad
min.xml
2002-04-01 09:35:31 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-ex
amples.xml
2002-04-01 09:35:31 - AutoWebApp: Loaded from config: DEFAULT:/admin
2002-04-01 09:35:31 - AutoWebApp: Loaded from config: DEFAULT:/examples
2002-04-01 09:35:31 - AutoWebApp: Auto-Adding DEFAULT:/LsGateway
2002-04-01 09:35:31 - AutoWebApp: Auto-Adding DEFAULT:/
2002-04-01 09:35:31 - ContextManager: Tomcat configured and in stable state
2002-04-01 09:35:31 - ContextManager: Adding DEFAULT:/admin
2002-04-01 09:35:31 - ContextManager: Adding DEFAULT:/examples
2002-04-01 09:35:31 - ContextManager: Adding DEFAULT:/LsGateway
2002-04-01 09:35:31 - ContextManager: Adding DEFAULT:/ROOT
2002-04-01 09:35:33 - Ctx(/LsGateway) : Exception in preInit org.apache.crimson.
jaxp.SAXParserFactoryImpl - java.lang.ClassCastException: org.apache.crimson.jax
p.SAXParserFactoryImpl
at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:
135)
at pfs.ls.gateway.LsGateway.init(LsGateway.java:33)
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Unknown Source)
at org.apache.tomcat.facade.ServletHandler.getServlet(ServletHandler.jav
a:346)
at org.apache.tomcat.facade.ServletHandler.preInit(ServletHandler.java:4
39)
at org.apache.tomcat.facade.ServletHandler.init(ServletHandler.java:228)
at org.apache.tomcat.facade.LoadOnStartupInterceptor.contextInit(LoadOnS
tartupInterceptor.java:136)
at org.apache.tomcat.core.Context.init(Context.java:542)
at org.apache.tomcat.core.ContextManager.init(ContextManager.java:597)
at org.apache.tomcat.startup.EmbededTomcat.initContextManager(EmbededTom
cat.java:564)
at org.apache.tomcat.startup.EmbededTomcat.execute1(EmbededTomcat.java:7
03)
at org.apache.tomcat.startup.EmbededTomcat$1.run(EmbededTomcat.java:687)
at org.apache.tomcat.util.compat.Jdk12Support$PrivilegedProxy.run(Jdk12S
upport.java:190)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.tomcat.util.compat.Jdk12Support.doPrivileged(Jdk12Support.
java:100)
at org.apache.tomcat.startup.EmbededTomcat.execute(EmbededTomcat.java:68
5)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.tomcat.util.IntrospectionUtils.execute(IntrospectionUtils.
java:87)
at org.apache.tomcat.startup.Main.execute(Main.java:313)
at org.apache.tomcat.startup.Main.main(Main.java:140)
EmbededTomcat: Init time 6409
2002-04-01 09:35:34 - Http10Interceptor: Starting on 8080
2002-04-01 09:35:34 - Ajp12Interceptor: Starting on 8007
2002-04-01 09:35:34 - Ajp13Interceptor: Starting on 8009
EmbededTomcat: Startup time 561
--
Code that causes exception is:
public class LsGateway extends HttpServlet
{
...
private javax.xml.parsers.SAXParserFactory spf =
javax.xml.parsers.SAXParserFactory.newInstance(); //Exception at this line
...
public void init(ServletConfig config) throws ServletException
{
super.init(config);
...
}
...
}
Howewer, when I changed my code as follows everything works fine:
public class LsGateway extends HttpServlet
{
...
private javax.xml.parsers.SAXParserFactory spf;
...
public void init(ServletConfig config) throws ServletException
{
super.init(config);
spf = javax.xml.parsers.SAXParserFactory.newInstance();
}
...
}
I'm using default, unchanged configuration, that means using XML parser
provided by Tomcat.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7656] New: - Webapplications deployed using PUT don't survive a tomcat restart
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=7656. 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=7656 Webapplications deployed using PUT don't survive a tomcat restart Summary: Webapplications deployed using PUT don't survive a tomcat restart Product: Tomcat 4 Version: Nightly Build Platform: All OS/Version: Other Status: NEW Severity: Blocker Priority: Other Component: Connector:Webapp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Because the webapplications are placed in the temporary directory for tomcat and not opened in the main webapp directory, the server doesn't know to load them again when the server restarts. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6702] - jk_nt_service.exe -i cannot work
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=6702. 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=6702 jk_nt_service.exe -i cannot work --- Additional Comments From [EMAIL PROTECTED] 2002-04-01 14:44 --- The updated conf\wrapper.properties file in Tomcat 3.3.1 has a problem in that wrapper.jvm.options should be non-blank or the $(wrapper.jvm.options) should be removed from wrapper.cmd_line. See if that fixes your problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7662] New: - javax.servlet.ServletContext;
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=7662. 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=7662 javax.servlet.ServletContext; Summary: javax.servlet.ServletContext; Product: Tomcat 4 Version: 4.0.3 Final Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Platforms and OS affected: NT 4/Intel Pentium III Solaris 8/Sparc Ultra80 Using tomcat 4.0.1 I could get servlet context of another application running on the same tomcat server, regardless jdk1.3 or 1.4 . For example, Current servlet context is /myservlet. ServletContext srvctx = request.getSession().getServletContext(); ServletContext rootctx = srvctx.getContext(/); ServletContext cachectx = srvctx.getContext(/cache); rootctx and cachectx contexts would result in non-null resolvable values. However when I ran myservlet to tomcat 4.0.3,regardless jdk1.3 or 1.4, /myservlet produced null values for rootctx and cachectx . -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: EJB + Tomcat?
I don't know of anyone who has expressed interest in doing this directly within Tomcat. I do know that Tomcat is (or can be) integrated with other EJB servers -- such as the J2EE Reference Implementation and JBoss -- to provide access to EJBs from Tomcat-based servlets. Writing an EJB container is definitely not a trivial undertaking, so anyone who wants to work on this would need to plan on spending a *lot* of time at it. Craig On Sun, 31 Mar 2002, Lev Assinovsky wrote: Date: Sun, 31 Mar 2002 15:38:24 +0400 From: Lev Assinovsky [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: EJB + Tomcat? Hello all! I searched tomcat-users and tomcat-dev archives and didn't find an answer to the question are there any plans to provide direct and full support of EJB in Tomcat?. Sorry if this post is out of topic. Sincerely, -- Lev AssinovskyPeterlink Web Programmer St. Petersburg, Russia Tel/Fax: +7 812 3275343 197022 ul.Chapigina 7Á E-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Question: does Tomcat4 manage jsp/servlet threads?
On Mon, 1 Apr 2002, Hugh J. L. wrote: Date: Mon, 1 Apr 2002 00:15:36 -0800 (PST) From: Hugh J. L. [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Question: does Tomcat4 manage jsp/servlet threads? Hi, everyone, I need some help on Tomcat 4 architecture. Does Tomcat 4 manage jsp/servlet threads? For example, can it report condition of those threads, stop dead thread and release resource, etc? And, does it use thread pool? In the 4.0.x releases, there is an org.apache.catalina.connector.http.HttpProcessor instance for each request processing thread. Requests are handed off by the HttpConnector instance which does the socket accept calls. The number of request processing threads is managed by the minProcessors and maxProcessors configuration properties. The processor threads are recycled, so that's sort of a thread pool (although the threads themselves are not stored in a separate thread pool). Thanks. I have to know this before I have time to read its source code. :-( That's too bad, because that is where all the answers are. Check the classes in the org.apache.catalina.connector.http package. Regards, Hugh Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
I would be -1 on this - the JDK documentation clearly defines the intended behavior of the ext directory, and this would create confusion and unpredictible behavior. I expect a file in ext/ to be included _before_ tomcat classes - the way java documents it. ( I don't use ext/, but classloader changes do _allways_ create problems ) Costin On 1 Apr 2002 [EMAIL PROTECTED] wrote: patrickl02/03/31 16:13:23 Modified:catalina/src/bin catalina.bat catalina.sh setclasspath.bat setclasspath.sh tool-wrapper.bat tool-wrapper.sh catalina/src/share/org/apache/catalina/startup Bootstrap.java Tool.java jasper/src/bin jasper.bat jasper.sh Log: Put jar files installed in the JDK's jre/lib/ext directory after the jar files and classes bundled with Tomcat. This is done by setting the java.ext.dirs property to a zero length string and by put the JDK's jre/lib/ext directory in Tomcat's class loader. This also fixes the problem that used to happen when you had the JSSE jars installed as a system extension and you had JSSE_HOME set. Revision ChangesPath 1.28 +9 -9 jakarta-tomcat-4.0/catalina/src/bin/catalina.bat Index: catalina.bat === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/catalina.bat,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- catalina.bat19 Mar 2002 18:10:56 - 1.27 +++ catalina.bat1 Apr 2002 00:13:23 - 1.28 @@ -28,12 +28,12 @@ rem system class path used to start Tomcat. rem rem JPDA_TRANSPORT (Optional) JPDA transport used when the jpda start -rem command is executed. The default is dt_shmem. +rem command is executed. The default is dt_socket. rem rem JPDA_ADDRESS(Optional) Java runtime options used when the jpda start -rem command is executed. The default is jdbconn. +rem command is executed. The default is 8000. rem -rem $Id: catalina.bat,v 1.27 2002/03/19 18:10:56 patrickl Exp $ +rem $Id: catalina.bat,v 1.28 2002/04/01 00:13:23 patrickl Exp $ rem --- rem Guess CATALINA_HOME if not defined @@ -91,10 +91,10 @@ if not %1 == jpda goto noJpda set JPDA=jpda if not %JPDA_TRANSPORT% == goto gotJpdaTransport -set JPDA_TRANSPORT=dt_shmem +set JPDA_TRANSPORT=dt_socket :gotJpdaTransport if not %JPDA_ADDRESS% == goto gotJpdaAddress -set JPDA_ADDRESS=jdbconn +set JPDA_ADDRESS=8000 :gotJpdaAddress shift :noJpda @@ -173,17 +173,17 @@ rem Execute Java with the applicable properties if not %JPDA% == goto doJpda if not %SECURITY_POLICY_FILE% == goto doSecurity -%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -classpath %CLASSPATH% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% +%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -Djava.ext.dirs=%JAVA_EXT_DIRS% -classpath %CLASSPATH% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% goto end :doSecurity -%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -classpath %CLASSPATH% -Djava.security.manager -Djava.security.policy==%SECURITY_POLICY_FILE% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% +%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -Djava.ext.dirs=%JAVA_EXT_DIRS% -classpath %CLASSPATH% -Djava.security.manager -Djava.security.policy==%SECURITY_POLICY_FILE% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% goto end :doJpda if not %SECURITY_POLICY_FILE% == goto doSecurityJpda -%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xdebug -Xrunjdwp:transport=%JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -classpath %CLASSPATH% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% +%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xdebug -Xrunjdwp:transport=%JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -Djava.ext.dirs=%JAVA_EXT_DIRS% -classpath %CLASSPATH% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME%
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
Costin, The problem with the default JVM behavior can cause your application to crash or behave in unexpected ways if there are incompatible jars installed in the jre/lib/ext directory. The method that we are using is still compliant with the JDK documentation in that we are using the documented way over overriding the extensions via setting the java.ext.dirs property at startup. This also the same type of override mechanism for the endorsed directories in JDK 1.4. The only feature we are adding is the ability to add your extensions back at the end of the classloader's search list. I am definitely not in favor of just letting the jre/lib/ext directory sit at the front of the classloader's search list as that makes Tomcat very sensitive (read breakable) due to the user's JVM configuration. Hence, I believe that the java.ext.dirs= property setting should remain. As to whether we should try to add back the extensions at the end of the classloader's search list, I am not too picky about. My first concern is that Tomcat always can at least run no matter what extensions that user has installed. Whether or not those extensions are accessible to Tomcat is, IMHO, a feature that we may or may not want to include. Thanks, Patrick [EMAIL PROTECTED] wrote: I would be -1 on this - the JDK documentation clearly defines the intended behavior of the ext directory, and this would create confusion and unpredictible behavior. I expect a file in ext/ to be included _before_ tomcat classes - the way java documents it. ( I don't use ext/, but classloader changes do _allways_ create problems ) Costin On 1 Apr 2002 [EMAIL PROTECTED] wrote: patrickl02/03/31 16:13:23 Modified:catalina/src/bin catalina.bat catalina.sh setclasspath.bat setclasspath.sh tool-wrapper.bat tool-wrapper.sh catalina/src/share/org/apache/catalina/startup Bootstrap.java Tool.java jasper/src/bin jasper.bat jasper.sh Log: Put jar files installed in the JDK's jre/lib/ext directory after the jar files and classes bundled with Tomcat. This is done by setting the java.ext.dirs property to a zero length string and by put the JDK's jre/lib/ext directory in Tomcat's class loader. This also fixes the problem that used to happen when you had the JSSE jars installed as a system extension and you had JSSE_HOME set. Revision ChangesPath 1.28 +9 -9 jakarta-tomcat-4.0/catalina/src/bin/catalina.bat Index: catalina.bat === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/catalina.bat,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- catalina.bat19 Mar 2002 18:10:56 - 1.27 +++ catalina.bat1 Apr 2002 00:13:23 - 1.28 @@ -28,12 +28,12 @@ rem system class path used to start Tomcat. rem rem JPDA_TRANSPORT (Optional) JPDA transport used when the jpda start -rem command is executed. The default is dt_shmem. +rem command is executed. The default is dt_socket. rem rem JPDA_ADDRESS(Optional) Java runtime options used when the jpda start -rem command is executed. The default is jdbconn. +rem command is executed. The default is 8000. rem -rem $Id: catalina.bat,v 1.27 2002/03/19 18:10:56 patrickl Exp $ +rem $Id: catalina.bat,v 1.28 2002/04/01 00:13:23 patrickl Exp $ rem --- rem Guess CATALINA_HOME if not defined @@ -91,10 +91,10 @@ if not %1 == jpda goto noJpda set JPDA=jpda if not %JPDA_TRANSPORT% == goto gotJpdaTransport -set JPDA_TRANSPORT=dt_shmem +set JPDA_TRANSPORT=dt_socket :gotJpdaTransport if not %JPDA_ADDRESS% == goto gotJpdaAddress -set JPDA_ADDRESS=jdbconn +set JPDA_ADDRESS=8000 :gotJpdaAddress shift :noJpda @@ -173,17 +173,17 @@ rem Execute Java with the applicable properties if not %JPDA% == goto doJpda if not %SECURITY_POLICY_FILE% == goto doSecurity -%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -classpath %CLASSPATH% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% +%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -Djava.ext.dirs=%JAVA_EXT_DIRS% -classpath %CLASSPATH% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% goto end :doSecurity -%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -classpath %CLASSPATH% -Djava.security.manager -Djava.security.policy==%SECURITY_POLICY_FILE%
Re: Mod_jk v/s mod_webapp
David Graff [EMAIL PROTECTED] wrote: Thanks for the pointer on that documentation. I was wondering where the Javadoc style comments were being used at. You welcome... I still don't think the question was really answered though as to the motivation of mod_webapp versus mod_jk/mod_jk2 development? Are there any goals that have been made available to the public so that we understand what the spawned these two different integration modules? Motivation? I don't like mod_jk, I wanted to use APR as a portable runtime for an Apache 1.3 module, I believe that the WARP protocol with built-in support for auto-deployment and web-application configuration is the way to go (rather than using mod_rewrite rules all the way around), and because I don't like Costin :) :) :) :) Umm, I posted a bug about this, what about the now infamous 404 (Apache started after Tomcat issue) and the fact that the manager app doesn't work when you try to create a new application due to apache indexing the apps when it starts. The only solution/workaround/kludge being to restart Apache? The other thing being; because mod_webapp ignores the rewrited filename preferring to still look at the raw uri means things like mod_rewrite don't apply (which for many people is an absolute necessity). Check the user lists to witness the frustration. (BTW, all those goals passed over on this mailing list in the past 2/3 years, check the archives...) Pier -- 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]
Bug 3534: Binary File Bug in Tomcat 4 Warp.jar
Hello, When will the binary bug in the Warp connector be put in the Tomcat repository ? I do not have the expertise to make a new build from the CVS repository. Does anyone have a warp.jar with the binary fix in for use in Tomcat 4.0.2? Best Regards, John Banister -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Is Tyrex included in Tomcat 4.0.3
Hi, I am trying to use the JDBC pool feature of Tomcat 4.0.3. I am using the tomcat4-4.0.3 rpm packages on a RH 7.2 box. Firstly I can not find the tyrex-0.9.7.jar in the tomcat release. Secondly, when I copied a tyrex-0.9.7.jar in $CATALINA_HOME/common/lib, the JDBC pool I specified in DefaultContext still is not there. Would you please tell me what should I do to make the Jdbc pooling work? Thanks, Yanfeng -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6621] - mod_webapp hangs when transmitting binary (eg. image) 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=6621. 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=6621 mod_webapp hangs when transmitting binary (eg. image) files [EMAIL PROTECTED] changed: What|Removed |Added Severity|Blocker |Critical -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Depth bug in WebdavServlet.doPropfind
Hello all,
Can some tomcat developer include this bug-fix in the WebdavServlet code.
The doPropfind goes one level too deep with list(...) requests. This
results in a list operations of each sub-context, while I'm only asking
for a list of the context itself.
I've taken tomcat 4.0.2 as source.
row 594:
replace
// if (object instanceof DirContext) {
by
if ((object instanceof DirContext) (depth 0)) {
Thanks
Ewout Prangsma
--
Ewout Prangsma, Directeur
Daisy Software
Telefoon/fax: +31-77-3270305/3270306
Email: [EMAIL PROTECTED]
Website: www.daisysoftware.com
KvK Venlo nr. 12046144
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 InternalOutputBuffer.java
remm02/04/01 09:50:46
Modified:http11/src/java/org/apache/coyote/http11
InternalOutputBuffer.java
Log:
- Fix problems handling null strings.
- isNull wasn't a good way to test the type of the MB (use getType instead).
Revision ChangesPath
1.12 +6 -4
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java
Index: InternalOutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- InternalOutputBuffer.java 28 Mar 2002 02:34:11 - 1.11
+++ InternalOutputBuffer.java 1 Apr 2002 17:50:46 - 1.12
@@ -545,12 +545,11 @@
protected void write(MessageBytes mb) {
mb.toBytes();
-ByteChunk bc = mb.getByteChunk();
-if (!bc.isNull()) {
-// Writing the byte chunk to the output buffer
+
+if (mb.getType() == MessageBytes.T_BYTES) {
+ByteChunk bc = mb.getByteChunk();
write(bc);
} else {
-// Using toString
write(mb.toString());
}
@@ -582,6 +581,9 @@
* @param s data to be written
*/
protected void write(String s) {
+
+if (s == null)
+return;
// From the Tomcat 3.3 HTTP/1.0 connector
int len = s.length();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
Remy Maucherat wrote: Adding another CL layer is dangerous and makes CL slower; unless other people think this is useful I don't think we should add the feature) Another option is to use the manifest version tags to identify which versions of the servletapi (and other sensitive classes) are being used, and print out an error message if they don't match what Tomcat requires. Patrick Luby wrote: My first concern is that Tomcat always can at least run no matter what extensions that user has installed. Whether or not those extensions are accessible to Tomcat is, IMHO, a feature that we may or may not want to include. Quitely dropping extensions that the user has installed is unintuitve, and in some ways worse than the current situation. Perhaps a combination? Normal behavior is to check api versions, exit if they don't match. Fallback if it's impossible to remove the extensions is to use the java.ext.dirs= hack? That lets a user get Tomcat running no matter what, but with full awareness of the tradeoff. Either way, the current situation is a problem for many people, as can be seen by a quick scan of the tomcat-users list. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets WebdavServlet.java
remm02/04/01 10:12:39
Modified:catalina/src/share/org/apache/catalina/servlets
WebdavServlet.java
Log:
- Avoid doing unecessary lists operations.
- Patch submitted by Ewout Prangsma e.prangsma at daisysoftware.com.
Revision ChangesPath
1.28 +25 -24
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java
Index: WebdavServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- WebdavServlet.java9 Mar 2002 23:22:38 - 1.27
+++ WebdavServlet.java1 Apr 2002 18:12:38 - 1.28
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
1.27 2002/03/09 23:22:38 remm Exp $
- * $Revision: 1.27 $
- * $Date: 2002/03/09 23:22:38 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
1.28 2002/04/01 18:12:38 remm Exp $
+ * $Revision: 1.28 $
+ * $Date: 2002/04/01 18:12:38 $
*
*
*
@@ -126,7 +126,7 @@
* are handled by the DefaultServlet.
*
* @author Remy Maucherat
- * @version $Revision: 1.27 $ $Date: 2002/03/09 23:22:38 $
+ * @version $Revision: 1.28 $ $Date: 2002/04/01 18:12:38 $
*/
public class WebdavServlet
@@ -591,7 +591,9 @@
} catch (NamingException e) {
continue;
}
-if (object instanceof DirContext) {
+
+if ((object instanceof DirContext) (depth 0)) {
+
try {
NamingEnumeration enum = resources.list(currentPath);
while (enum.hasMoreElements()) {
@@ -610,27 +612,26 @@
return;
}
-if (depth 0) {
-// Displaying the lock-null resources present in that
-// collection
-String lockPath = currentPath;
-if (lockPath.endsWith(/))
-lockPath =
-lockPath.substring(0, lockPath.length() - 1);
-Vector currentLockNullResources =
-(Vector) lockNullResources.get(lockPath);
-if (currentLockNullResources != null) {
-Enumeration lockNullResourcesList =
-currentLockNullResources.elements();
-while (lockNullResourcesList.hasMoreElements()) {
-String lockNullPath = (String)
-lockNullResourcesList.nextElement();
-parseLockNullProperties
-(req, generatedXML, lockNullPath, type,
- properties);
-}
+// Displaying the lock-null resources present in that
+// collection
+String lockPath = currentPath;
+if (lockPath.endsWith(/))
+lockPath =
+lockPath.substring(0, lockPath.length() - 1);
+Vector currentLockNullResources =
+(Vector) lockNullResources.get(lockPath);
+if (currentLockNullResources != null) {
+Enumeration lockNullResourcesList =
+currentLockNullResources.elements();
+while (lockNullResourcesList.hasMoreElements()) {
+String lockNullPath = (String)
+lockNullResourcesList.nextElement();
+parseLockNullProperties
+(req, generatedXML, lockNullPath, type,
+ properties);
}
}
+
}
if (stack.isEmpty()) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets WebdavServlet.java
remm02/04/01 10:17:43
Modified:catalina/src/share/org/apache/catalina/servlets Tag:
tomcat_40_branch WebdavServlet.java
Log:
- Avoid doing unecessary lists operations.
- Patch submitted by Ewout Prangsma e.prangsma at daisysoftware.com.
Revision ChangesPath
No revision
No revision
1.25.2.2 +25 -24
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java
Index: WebdavServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
retrieving revision 1.25.2.1
retrieving revision 1.25.2.2
diff -u -r1.25.2.1 -r1.25.2.2
--- WebdavServlet.java3 Jan 2002 10:44:32 - 1.25.2.1
+++ WebdavServlet.java1 Apr 2002 18:17:43 - 1.25.2.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
1.25.2.1 2002/01/03 10:44:32 remm Exp $
- * $Revision: 1.25.2.1 $
- * $Date: 2002/01/03 10:44:32 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/WebdavServlet.java,v
1.25.2.2 2002/04/01 18:17:43 remm Exp $
+ * $Revision: 1.25.2.2 $
+ * $Date: 2002/04/01 18:17:43 $
*
*
*
@@ -126,7 +126,7 @@
* are handled by the DefaultServlet.
*
* @author Remy Maucherat
- * @version $Revision: 1.25.2.1 $ $Date: 2002/01/03 10:44:32 $
+ * @version $Revision: 1.25.2.2 $ $Date: 2002/04/01 18:17:43 $
*/
public class WebdavServlet
@@ -591,7 +591,9 @@
} catch (NamingException e) {
continue;
}
-if (object instanceof DirContext) {
+
+if ((object instanceof DirContext) (depth 0)) {
+
try {
NamingEnumeration enum = resources.list(currentPath);
while (enum.hasMoreElements()) {
@@ -610,27 +612,26 @@
return;
}
-if (depth 0) {
-// Displaying the lock-null resources present in that
-// collection
-String lockPath = currentPath;
-if (lockPath.endsWith(/))
-lockPath =
-lockPath.substring(0, lockPath.length() - 1);
-Vector currentLockNullResources =
-(Vector) lockNullResources.get(lockPath);
-if (currentLockNullResources != null) {
-Enumeration lockNullResourcesList =
-currentLockNullResources.elements();
-while (lockNullResourcesList.hasMoreElements()) {
-String lockNullPath = (String)
-lockNullResourcesList.nextElement();
-parseLockNullProperties
-(req, generatedXML, lockNullPath, type,
- properties);
-}
+// Displaying the lock-null resources present in that
+// collection
+String lockPath = currentPath;
+if (lockPath.endsWith(/))
+lockPath =
+lockPath.substring(0, lockPath.length() - 1);
+Vector currentLockNullResources =
+(Vector) lockNullResources.get(lockPath);
+if (currentLockNullResources != null) {
+Enumeration lockNullResourcesList =
+currentLockNullResources.elements();
+while (lockNullResourcesList.hasMoreElements()) {
+String lockNullPath = (String)
+lockNullResourcesList.nextElement();
+parseLockNullProperties
+(req, generatedXML, lockNullPath, type,
+ properties);
}
}
+
}
if (stack.isEmpty()) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
Remy Maucherat wrote: My first concern is that Tomcat always can at least run no matter what extensions that user has installed. Whether or not those extensions are accessible to Tomcat is, IMHO, a feature that we may or may not want to include. Quitely dropping extensions that the user has installed is unintuitve, and in some ways worse than the current situation. Perhaps a combination? Normal behavior is to check api versions, exit if they don't match. Fallback if it's impossible to remove the extensions is to use the java.ext.dirs= hack? That lets a user get Tomcat running no matter what, but with full awareness of the tradeoff. Either way, the current situation is a problem for many people, as can be seen by a quick scan of the tomcat-users list. Making life easier for first time users is a commendable goal, but it is likely that the servlet API as a system extension will cause trouble anyway at some point later on, so why bother ? Also, since Costin vetoed the patch, he's the one who should be convinced (I'm merely -0 here; -1 if the problems with JDK 1.4 can't be fixed). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0.4.txt
remm02/04/01 10:19:56 Modified:.Tag: tomcat_40_branch RELEASE-NOTES-4.0.4.txt Log: - Update release notes. Revision ChangesPath No revision No revision 1.1.2.3 +7 -1 jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.4.txt Index: RELEASE-NOTES-4.0.4.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.4.txt,v retrieving revision 1.1.2.2 retrieving revision 1.1.2.3 diff -u -r1.1.2.2 -r1.1.2.3 --- RELEASE-NOTES-4.0.4.txt 28 Mar 2002 14:58:18 - 1.1.2.2 +++ RELEASE-NOTES-4.0.4.txt 1 Apr 2002 18:19:56 - 1.1.2.3 @@ -3,7 +3,7 @@ Release Notes = -$Id: RELEASE-NOTES-4.0.4.txt,v 1.1.2.2 2002/03/28 14:58:18 larryi Exp $ +$Id: RELEASE-NOTES-4.0.4.txt,v 1.1.2.3 2002/04/01 18:19:56 remm Exp $ @@ -126,6 +126,12 @@ [B2] HttpResponseBase: Revert fix for 6600, which breaks sessionid URL encoding in 4.0.4 Beta 1. + +[B3] Request: + Add support for language variants. + +[B3] WebdavServlet: + Avoid unnecessary operations when doing a PROPFIND. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7664] New: - Coyote Connector Losing POST content
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=7664. 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=7664 Coyote Connector Losing POST content Summary: Coyote Connector Losing POST content Product: Tomcat 4 Version: 4.0.4 Beta 2 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm using Microsoft's XML HTTP posting control to send XML back to Tomcat from IE. This works fine with the old HTTP 1.1 connector. With Coyote reading from request.getReader() and request.getInputStream() return nothing. I used the request dumper to dump the request. Looks like the POST data is there. I just can't read it. 2002-04-01 13:38:44 CoyoteProcessor[80][3] Requested cookie session id is D9C97A03F3F01CA24134C1DAFD6DDA08 2002-04-01 13:38:44 RequestDumperValve[Standalone]: REQUEST URI =/hyp/Configurator.jsp 2002-04-01 13:38:44 RequestDumperValve[Standalone]: authType=null 2002-04-01 13:38:44 RequestDumperValve[Standalone]: characterEncoding=null 2002-04-01 13:38:44 RequestDumperValve[Standalone]: contentLength=3951 2002-04-01 13:38:44 RequestDumperValve[Standalone]:contentType=text/xml 2002-04-01 13:38:44 RequestDumperValve[Standalone]:contextPath= 2002-04-01 13:38:44 RequestDumperValve[Standalone]: cookie=JSESSIONID=D9C97A03F3F01CA24134C1DAFD6DDA08 2002-04-01 13:38:44 RequestDumperValve[Standalone]: header=accept=*/* 2002-04-01 13:38:44 RequestDumperValve[Standalone]: header=accept- language=en-us 2002-04-01 13:38:44 RequestDumperValve[Standalone]: header=referer=http://ntcpcdmh6/hyp/Configure.jsp 2002-04-01 13:38:44 RequestDumperValve[Standalone]: header=content- type=text/xml 2002-04-01 13:38:44 RequestDumperValve[Standalone]: header=accept- encoding=gzip, deflate 2002-04-01 13:38:44 RequestDumperValve[Standalone]: header=user- agent=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461) 2002-04-01 13:38:44 RequestDumperValve[Standalone]: header=host=ntcpcdmh6 2002-04-01 13:38:44 RequestDumperValve[Standalone]: header=content- length=3951 2002-04-01 13:38:44 RequestDumperValve[Standalone]: header=connection=Keep-Alive 2002-04-01 13:38:44 RequestDumperValve[Standalone]: header=cache- control=no-cache 2002-04-01 13:38:44 RequestDumperValve[Standalone]: header=cookie=JSESSIONID=D9C97A03F3F01CA24134C1DAFD6DDA08 2002-04-01 13:38:44 RequestDumperValve[Standalone]: header=authorization=Basic dTAwZG1oNjpzb3RoZXJl 2002-04-01 13:38:44 RequestDumperValve[Standalone]: locale=en_US 2002-04-01 13:38:44 RequestDumperValve[Standalone]: method=POST 2002-04-01 13:38:44 RequestDumperValve[Standalone]: parameter=amp; KEYLESS ENTRY name=0595024/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20922 description=ESC PROG CRUISE CONTROL IND LIGHT name=0595026/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20923 description=ESC PROG DIAGNOSTICS name=0595027/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20924 description=ESC PROG WINDSHIELD WIPER name=0595029/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20926 description=ESC PROG IGNITION KEY OR KEYLESS name=0595031/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20944 description=ESC PROG ELECT PRAM DEFLT SETTINGS name=0595049/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20947 description=ESC PROG SINGLE FUEL TANK name=0595052/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20953 description=ESC PROG VOLTMETER name=0595061/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20955 description=ESC PROG SEAT BELT IND LIGHT name=0595063/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20958 description=T/R DATA ENGINE OIL PRESS GAUGE name=0595066/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20959 description=T/R DATA ENGINE COOLANT TEMP GA name=0595067/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20960 description=ESC PROG BATT FEED FUES DET name=0595068/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20961 description=T/R DATA VEHICLE SPEED GAUGE name=0595069/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20962 description=T/R DATA ENGINE SPEED GAUGE name=0595070/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20971 description=T/R DATA WARNING LIGHTS name=0595079/ Feature xmlns:ixb=urn:navistar.com:ixb ixb:oid=20975 description=ESC PROG CRUISE CONTROL SWITCH STATE name=0595083/
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
On Mon, 1 Apr 2002, Patrick Luby wrote: Costin, The problem with the default JVM behavior can cause your application to crash or behave in unexpected ways if there are incompatible jars installed in the jre/lib/ext directory. Then report the bug to the JVM people :-) The method that we are using is still compliant with the JDK documentation in that we are using the documented way over overriding the extensions via setting the java.ext.dirs property at startup. This also the same type of override mechanism for the endorsed directories in JDK 1.4. The only feature we are adding is the ability to add your extensions back at the end of the classloader's search list. I can live with having tomcat explicitely disable ext.dir - most people agree /ext is evil and it causes problems. But adding it back with a different behavior is hardly 'compliant'. The reason I disagree with removing ext - it makes tomcat even more dependent on startup script behavior, and adds another difference with the 'normal' behavior for classloaders ( it already brakes one of the fundamental rules - the delegation ). I am definitely not in favor of just letting the jre/lib/ext directory sit at the front of the classloader's search list as that makes Tomcat very sensitive (read breakable) due to the user's JVM configuration. Hence, I believe that the java.ext.dirs= property setting should remain. As to whether we should try to add back the extensions at the end of the classloader's search list, I am not too picky about. The ext/ was created with a purpose - and is a standard part of java. If we don't like it - we can recommend the users to not use it, but if the user does want to use it, it should operate the way it was intended. My first concern is that Tomcat always can at least run no matter what extensions that user has installed. Whether or not those extensions are accessible to Tomcat is, IMHO, a feature that we may or may not want to include. If the user installs some incompatible extensions - I think tomcat should report an error or not run. I'm ok with adding checks in tomcat to verify that the files in ext/ are compatible. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5762] - CGI servlet misses to include port number in HTTP_HOST environment variable
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=5762. 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=5762 CGI servlet misses to include port number in HTTP_HOST environment variable --- Additional Comments From [EMAIL PROTECTED] 2002-04-01 18:48 --- sounds good to me. :-) Amy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7664] - Coyote Connector Losing POST content
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=7664. 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=7664 Coyote Connector Losing POST content [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-04-01 18:51 --- The POSTed data was always parsed when calling getParameters, regardless of the content type (it should only be parsed when FORM URL encoded, obviously). *** This bug has been marked as a duplicate of 7413 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7413] - java.io.CharConversionException om file upload, 4.0.4 Beta 2
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=7413. 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=7413 java.io.CharConversionException om file upload, 4.0.4 Beta 2 [EMAIL PROTECTED] changed: What|Removed |Added CC||David.Holscher@nav- ||international.com --- Additional Comments From [EMAIL PROTECTED] 2002-04-01 18:51 --- *** Bug 7664 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
Remy, Remy Maucherat wrote: Fine, but your change creates problems (Jasper does not work on JDK 1.4 unless you delete common/endorsed/xerces.jar). I don't know why at this time, but it should be fixed ASAP. (Note: I don't care too much about this functionality ... Adding another CL layer is dangerous and makes CL slower; unless other people think this is useful I don't think we should add the feature) Remy I think I found the problem. In JDK 1.4, the StandardClassLoader's loadClass() method appears to be unconditionally delegating to its parent classloader even when setDelegate is set to false. This appears to be caused by changes to the URLClassLoader class in JDK 1.4. BTW, I can eliminate the use of a separate classloader and put the jre/lib/ext directory in the existing catalinaLoader and sharedLoader instances. However, to do this, I need to change the getClassPath() method in JspEngineContext.java so that it returns a classpath that is consistent with the classloaders' search order. Right now, the getClassPath() method (which is used for all JSP compilation) returns a classpath in the exact opposite order of the order used by the sharedLoader classloader. I originally put the extra classloader in to work around this getClassPath() bug. However, given the JDK 1.4 differences in the classloader delegation behavior, I think it would be better for me to fix the getClassPath() problem and move the jre/lib/ext directory into the existing catalinaLoader and sharedLoader instances like we do for the endorsed directories. Costin, Does this sound reasonable to you? Thanks, Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
On Mon, 1 Apr 2002, Patrick Luby wrote: BTW, I can eliminate the use of a separate classloader and put the jre/lib/ext directory in the existing catalinaLoader and sharedLoader instances. However, to do this, I need to change the getClassPath() method in JspEngineContext.java so that it returns a classpath that is consistent with the classloaders' search order. Right now, the getClassPath() method (which is used for all JSP compilation) returns a classpath in the exact opposite order of the order used by the sharedLoader classloader. I originally put the extra classloader in to work around this getClassPath() bug. However, given the JDK 1.4 differences in the classloader delegation behavior, I think it would be better for me to fix the getClassPath() problem and move the jre/lib/ext directory into the existing catalinaLoader and sharedLoader instances like we do for the endorsed directories. Costin, Does this sound reasonable to you? No. You can edit the doc - and use big font to tell users not to use ext/, or add a small check at startup and verify the servlet version. Changing the behavior of ext/ and class loader is the wrong solution, and shouldn't be done. Are you sure it doesn't have security implications ? JDK/ext can be protected and may have site-specific sensitive libraries. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
Fine, but your change creates problems (Jasper does not work on JDK 1.4 unless you delete common/endorsed/xerces.jar). I don't know why at this time, but it should be fixed ASAP. (Note: I don't care too much about this functionality ... Adding another CL layer is dangerous and makes CL slower; unless other people think this is useful I don't think we should add the feature) Remy I think I found the problem. In JDK 1.4, the StandardClassLoader's loadClass() method appears to be unconditionally delegating to its parent classloader even when setDelegate is set to false. This appears to be caused by changes to the URLClassLoader class in JDK 1.4. I had missed that it was attempting to change the delegation model (apparently, Costin didn't, that's why he was complaining, I suppose ;-)). I'm -1 for the patch then; please revert it. The use case is clearly not worth introducing non-compliant behavior; I fully agree with Costin here: if the ext mechanism is broken, then it's up to the JDK to fix it. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
Remy and Costin, I will reverse the patch since there are enough -1s on this. One question: should we continue to set the -Djava.ext.dirs= in the wrapper scripts? This disables the extensions but without any code change to Tomcat. Or do we want to revert back to the original scripts where the extensions are enabled by default? Patrick Remy Maucherat wrote: Fine, but your change creates problems (Jasper does not work on JDK 1.4 unless you delete common/endorsed/xerces.jar). I don't know why at this time, but it should be fixed ASAP. (Note: I don't care too much about this functionality ... Adding another CL layer is dangerous and makes CL slower; unless other people think this is useful I don't think we should add the feature) Remy I think I found the problem. In JDK 1.4, the StandardClassLoader's loadClass() method appears to be unconditionally delegating to its parent classloader even when setDelegate is set to false. This appears to be caused by changes to the URLClassLoader class in JDK 1.4. I had missed that it was attempting to change the delegation model (apparently, Costin didn't, that's why he was complaining, I suppose ;-)). I'm -1 for the patch then; please revert it. The use case is clearly not worth introducing non-compliant behavior; I fully agree with Costin here: if the ext mechanism is broken, then it's up to the JDK to fix it. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
patrickl02/04/01 11:51:32 Modified:catalina/src/bin catalina.bat catalina.sh setclasspath.bat setclasspath.sh tool-wrapper.bat tool-wrapper.sh catalina/src/share/org/apache/catalina/startup Bootstrap.java Tool.java jasper/src/bin jasper.bat jasper.sh Log: Reverse 03/31/2002 patch that forced the JDK's installed extensions to be loaded at the end of the Catalina classloader's search list. Revision ChangesPath 1.29 +8 -8 jakarta-tomcat-4.0/catalina/src/bin/catalina.bat Index: catalina.bat === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/catalina.bat,v retrieving revision 1.28 retrieving revision 1.29 diff -u -r1.28 -r1.29 --- catalina.bat 1 Apr 2002 00:13:23 - 1.28 +++ catalina.bat 1 Apr 2002 19:51:31 - 1.29 @@ -28,12 +28,12 @@ rem system class path used to start Tomcat. rem rem JPDA_TRANSPORT (Optional) JPDA transport used when the jpda start -rem command is executed. The default is dt_socket. +rem command is executed. The default is dt_shmem. rem rem JPDA_ADDRESS(Optional) Java runtime options used when the jpda start -rem command is executed. The default is 8000. +rem command is executed. The default is jdbconn. rem -rem $Id: catalina.bat,v 1.28 2002/04/01 00:13:23 patrickl Exp $ +rem $Id: catalina.bat,v 1.29 2002/04/01 19:51:31 patrickl Exp $ rem --- rem Guess CATALINA_HOME if not defined @@ -91,10 +91,10 @@ if not %1 == jpda goto noJpda set JPDA=jpda if not %JPDA_TRANSPORT% == goto gotJpdaTransport -set JPDA_TRANSPORT=dt_socket +set JPDA_TRANSPORT=dt_shmem :gotJpdaTransport if not %JPDA_ADDRESS% == goto gotJpdaAddress -set JPDA_ADDRESS=8000 +set JPDA_ADDRESS=jdbconn :gotJpdaAddress shift :noJpda @@ -173,17 +173,17 @@ rem Execute Java with the applicable properties if not %JPDA% == goto doJpda if not %SECURITY_POLICY_FILE% == goto doSecurity -%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -Djava.ext.dirs=%JAVA_EXT_DIRS% -classpath %CLASSPATH% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% +%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -classpath %CLASSPATH% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% goto end :doSecurity -%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -Djava.ext.dirs=%JAVA_EXT_DIRS% -classpath %CLASSPATH% -Djava.security.manager -Djava.security.policy==%SECURITY_POLICY_FILE% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% +%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -classpath %CLASSPATH% -Djava.security.manager -Djava.security.policy==%SECURITY_POLICY_FILE% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% goto end :doJpda if not %SECURITY_POLICY_FILE% == goto doSecurityJpda -%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xdebug -Xrunjdwp:transport=%JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -Djava.ext.dirs=%JAVA_EXT_DIRS% -classpath %CLASSPATH% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% +%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xdebug -Xrunjdwp:transport=%JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -classpath %CLASSPATH% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% goto end :doSecurityJpda -%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xrunjdwp:transport=%JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -Djava.endorsed.dirs=%JAVA_ENDORSED_DIRS% -Djava.ext.dirs=%JAVA_EXT_DIRS% -classpath %CLASSPATH% -Djava.security.manager -Djava.security.policy==%SECURITY_POLICY_FILE% -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Djava.io.tmpdir=%CATALINA_TMPDIR% %MAINCLASS% %CMD_LINE_ARGS% %ACTION% +%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xrunjdwp:transport=%JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS%
Re: Mod_jk v/s mod_webapp
James Williamson [EMAIL PROTECTED] wrote: Umm, I posted a bug about this, what about the now infamous 404 (Apache started after Tomcat issue) and the fact that the manager app doesn't work when you try to create a new application due to apache indexing the apps when it starts. The only solution/workaround/kludge being to restart Apache? The other thing being; because mod_webapp ignores the rewrited filename preferring to still look at the raw uri means things like mod_rewrite don't apply (which for many people is an absolute necessity). Check the user lists to witness the frustration. James, your it, you go ahead and fix it... It _WORKS_FOR_ME_ :) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
On Mon, 1 Apr 2002, Patrick Luby wrote: Remy and Costin, I will reverse the patch since there are enough -1s on this. One question: should we continue to set the -Djava.ext.dirs= in the wrapper scripts? This disables the extensions but without any code change to Tomcat. Or do we want to revert back to the original scripts where the extensions are enabled by default? I don't think we should disable ext/ - we can recommend people to not use it ( unless they know what they're doing ). If someone chooses to use ext/, he expect it to work - because that's what the java doc says. I'm -0, since we do disable CLASSPATH in the script. In general I think it's better to minimize the number of special settings in the command line. The .sh/.bat is just one way to start tomcat, there are implications when you embed it, start it with wrapper or from other apps, etc. If you really want to have fun with the startup, it would be better to remove more 'special' behaviors from .sh/.bat and clearly documenting what remains - i.e. the java options and classpath that are required to start tomcat. Costin Patrick Remy Maucherat wrote: Fine, but your change creates problems (Jasper does not work on JDK 1.4 unless you delete common/endorsed/xerces.jar). I don't know why at this time, but it should be fixed ASAP. (Note: I don't care too much about this functionality ... Adding another CL layer is dangerous and makes CL slower; unless other people think this is useful I don't think we should add the feature) Remy I think I found the problem. In JDK 1.4, the StandardClassLoader's loadClass() method appears to be unconditionally delegating to its parent classloader even when setDelegate is set to false. This appears to be caused by changes to the URLClassLoader class in JDK 1.4. I had missed that it was attempting to change the delegation model (apparently, Costin didn't, that's why he was complaining, I suppose ;-)). I'm -1 for the patch then; please revert it. The use case is clearly not worth introducing non-compliant behavior; I fully agree with Costin here: if the ext mechanism is broken, then it's up to the JDK to fix it. 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]
Another proposal for java.ext.dirs
All, I admit my previous method for protecting Tomcat from conflicting system extensions proved to be a bit flawed. However, I still would like to add some protection against these conflicts since this tends to be a difficult to diagnose problem for a lot of new Tomcat users. On the other hand, I don't think we want to prevent knowledgable users from using their installed extensions to support their installation. So, here is what I propose. Note that I am in favor of checking the installed extensions so this proposal should be complimentary to any checking that might be implemented in the Tomcat code: 1. Add the following to each Java execution line in the wrapper scripts: Unix: -Djava.ext.dirs=$JAVA_EXT_DIRS Windows: -Djava.ext.dirs=%JAVA_EXT_DIRS% 2. Add the following lines in setclasspath.bat and setclasspath.sh: Unix: if [ -z $JAVA_EXT_DIRS ]; then echo Disabling installed Java extensions. Set the echo JAVA_EXT_DIRS environment variable to the following value echo to enable installed Java extensions: echo $JAVA_HOME/jre/lib/ext fi Windows: if not %JAVA_EXT_DIRS% == goto gotJavaExtDirs echo Disabling installed Java extensions. Set the echo JAVA_EXT_DIRS environment variable to the following value echo to enable installed Java extensions: echo %JAVA_HOME%\jre\lib\ext :gotJavaExtDirs 3. If the user does not defined JAVA_EXT_DIRS (the default case), the java.ext.dirs property is set to and the above status message is printed. Then, if the user defines JAVA_EXT_DIRS, the existing behavior is enabled. Since new Tomcat users primarily use the installed scripts, this is a good way to protect Tomcat without preventing other custom scripts or launchers from enforcing a different standard. Does this sound like a reasonable approach? It would be nice to have this property setting in the Bootstrap.java class, but unfortunately, you must set the java.endorsed.dirs property when the JVM is started as it is immediately put in the JVM's bootstrap classpath. Thanks, Patrick Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Another proposal for java.ext.dirs
Patrick, Are you sure we need all this ? The .sh/.bat is already too complex. A simple check ( in java ) for the things that we care about should be more than enough, adding another config option and env variable is too much. The intent of the ext/ is to simplify the user's life - so they don't have to set CLASSPATH. It doesn't work out in most cases. If we want to disable it - fine, but I don't like making the user's life even harder by forcing him to remember and set yet another env variable. I expect the 'regular' user will use ext/, most advanced users are well aware of the problems and they already know how to deal with that. I remain -0 - if you really think this is a problem that must be solved, I won't veto it. Costin On Mon, 1 Apr 2002, Patrick Luby wrote: All, I admit my previous method for protecting Tomcat from conflicting system extensions proved to be a bit flawed. However, I still would like to add some protection against these conflicts since this tends to be a difficult to diagnose problem for a lot of new Tomcat users. On the other hand, I don't think we want to prevent knowledgable users from using their installed extensions to support their installation. So, here is what I propose. Note that I am in favor of checking the installed extensions so this proposal should be complimentary to any checking that might be implemented in the Tomcat code: 1. Add the following to each Java execution line in the wrapper scripts: Unix: -Djava.ext.dirs=$JAVA_EXT_DIRS Windows: -Djava.ext.dirs=%JAVA_EXT_DIRS% 2. Add the following lines in setclasspath.bat and setclasspath.sh: Unix: if [ -z $JAVA_EXT_DIRS ]; then echo Disabling installed Java extensions. Set the echo JAVA_EXT_DIRS environment variable to the following value echo to enable installed Java extensions: echo $JAVA_HOME/jre/lib/ext fi Windows: if not %JAVA_EXT_DIRS% == goto gotJavaExtDirs echo Disabling installed Java extensions. Set the echo JAVA_EXT_DIRS environment variable to the following value echo to enable installed Java extensions: echo %JAVA_HOME%\jre\lib\ext :gotJavaExtDirs 3. If the user does not defined JAVA_EXT_DIRS (the default case), the java.ext.dirs property is set to and the above status message is printed. Then, if the user defines JAVA_EXT_DIRS, the existing behavior is enabled. Since new Tomcat users primarily use the installed scripts, this is a good way to protect Tomcat without preventing other custom scripts or launchers from enforcing a different standard. Does this sound like a reasonable approach? It would be nice to have this property setting in the Bootstrap.java class, but unfortunately, you must set the java.endorsed.dirs property when the JVM is started as it is immediately put in the JVM's bootstrap classpath. Thanks, Patrick Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- 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: EJB + Tomcat?
On Tue, 2002-04-02 at 02:49, Craig R. McClanahan wrote: I don't know of anyone who has expressed interest in doing this directly within Tomcat. I do know that Tomcat is (or can be) integrated with other EJB servers -- such as the J2EE Reference Implementation and JBoss -- to provide access to EJBs from Tomcat-based servlets. Actually, one can download JBoss bundled with Tomcat from http://www.jboss.org/. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Classloader issue with Embedded tomcat and WAR deployment
I'm making a tomcat 4.0.3 module for netbeans, and I'm running into an odd problem with the org.apache.catalina.loader.WebappClassLoader. I'm utilizing the Embedded class to build my server, and I'm using the HostConfig mechanism for rolling in WAR files. I have no trouble loading individual servlets, but when I start the server with a WAR file in place, I get a NoClassDefFoundError: javax/servlet/http/HttpServlet. The error is masked by a catch( Throwable t) clause in HostConfig::deployApps, but when I explicitly print the stack trace, it looks like: java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:493) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1631) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:926) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1360) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1243) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:865) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:808) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3266) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3395) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:785) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:454) at org.apache.catalina.core.StandardHost.install(StandardHost.java:723) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:331) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:398) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:232) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:156) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131) at org.apache.catalina.core.StandardHost.start(StandardHost.java:614) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343) at org.apache.catalina.startup.Embedded.start(Embedded.java:957) at org.netbeans.modules.httpserver.TomcatServer.start(Unknown Source) at org.netbeans.modules.httpserver.HttpServerModule$1.run(Unknown Source) Delving into StandardWrapper line 865, I see the classloader attempting to load the servlet residing in the WAR file. This servlet extends HttpServlet, and that's where my error is coming from. However, if I stick in a line: classLoader.loadClass(javax.servlet.http.HttpServlet) before line 865, everything works fine. I'm guessing this is because HttpServlet gets loaded in an earlier run of StandardWrapper::loadServlet() (like when the DefaultServlet gets loaded). Must I explicitly set the parent classloader for the org.apache.catalina.loader.WebappLoader? How? Rich -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
costin 02/04/01 16:42:11
Modified:jk/native/apache-2.0 mod_jk.c
Log:
If jk config is broken, report the error - but don't exit.
Revision ChangesPath
1.41 +4 -4 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- mod_jk.c 28 Feb 2002 22:45:50 - 1.40
+++ mod_jk.c 2 Apr 2002 00:42:11 - 1.41
@@ -60,7 +60,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision: 1.40 $ *
+ * Version: $Revision: 1.41 $ *
***/
/*
@@ -1507,9 +1507,9 @@
/* if(map_alloc(init_map)) { */
if( ! map_read_properties(init_map, conf-worker_file)) {
if( map_size( init_map ) == 0 ) {
-jk_error_exit(APLOG_MARK, APLOG_EMERG, s,
- pconf, No worker file and no worker options in
httpd.conf \n
- use JkWorkerFile or JkWorker to set workers);
+ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, APLOG_EMERG,
+ NULL, No worker file and no worker options in httpd.conf
\n
+ use JkWorkerFile to set workers\n);
return;
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7676] New: - Allow name property to use match experssions in host tag, or alias tag
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=7676. 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=7676 Allow name property to use match experssions in host tag, or alias tag Summary: Allow name property to use match experssions in host tag, or alias tag Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] It would be very usefull to allow the host block to be selectable by a name proerty using regular experssions. That way an entire class of host names can be mapped to a virtual server. For instance in my example below, this Host section is selected if we have all of these: m1.mydomain.com site1.m1.mydomain.com site2.m1.mydomain.com m2.mydomain.com site1.m2.mydomain.com site2.m2.mydomain.com See below for config. === Host name=*.m1.mydomain.com debug=2 appBase=d:/http/my_content unpackWARs=true aliasm1.mydomain.com/alias alias*.m2.mydomain.com/alias aliasm2.mydomain.com/alias !-- Context -- Context path= docBase=d:/http/my_contentden reloadable=true crossContext=true debug=2/ /Host We host as many as 500 virtual sites on a server and need this so we can map all sites to the same content area, and add them without changing the server.properties file. The application looks at the host request header value to make the final determination on how to treat the content. Gene Engelgau -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Another proposal for java.ext.dirs
Costin, [EMAIL PROTECTED] wrote: Are you sure we need all this ? The .sh/.bat is already too complex. A simple check ( in java ) for the things that we care about should be more than enough, adding another config option and env variable is too much. I have to admit that using the scripts is a messy way to handle this problem. I am still trying to find a way to get the java.endorsed.dirs property out of the scripts. The intent of the ext/ is to simplify the user's life - so they don't have to set CLASSPATH. It doesn't work out in most cases. I agree. It is one of those tradeoffs: you can customize your JDK, but it may not work with your applications. If we want to disable it - fine, but I don't like making the user's life even harder by forcing him to remember and set yet another env variable. I expect the 'regular' user will use ext/, most advanced users are well aware of the problems and they already know how to deal with that. I remain -0 - if you really think this is a problem that must be solved, I won't veto it. I don't think I will commit this proposed change. After thinking about it, I don't think a hacky script change is a real solution. Since this a problem that affects nearly all Java applications (ant complained when I forgot to delete the jaxp.jar that I put in my jre/lib/ext directory), I am starting to think that this may be a problem where the cure is more painful than the problem. Patrick Costin On Mon, 1 Apr 2002, Patrick Luby wrote: All, I admit my previous method for protecting Tomcat from conflicting system extensions proved to be a bit flawed. However, I still would like to add some protection against these conflicts since this tends to be a difficult to diagnose problem for a lot of new Tomcat users. On the other hand, I don't think we want to prevent knowledgable users from using their installed extensions to support their installation. So, here is what I propose. Note that I am in favor of checking the installed extensions so this proposal should be complimentary to any checking that might be implemented in the Tomcat code: 1. Add the following to each Java execution line in the wrapper scripts: Unix: -Djava.ext.dirs=$JAVA_EXT_DIRS Windows: -Djava.ext.dirs=%JAVA_EXT_DIRS% 2. Add the following lines in setclasspath.bat and setclasspath.sh: Unix: if [ -z $JAVA_EXT_DIRS ]; then echo Disabling installed Java extensions. Set the echo JAVA_EXT_DIRS environment variable to the following value echo to enable installed Java extensions: echo $JAVA_HOME/jre/lib/ext fi Windows: if not %JAVA_EXT_DIRS% == goto gotJavaExtDirs echo Disabling installed Java extensions. Set the echo JAVA_EXT_DIRS environment variable to the following value echo to enable installed Java extensions: echo %JAVA_HOME%\jre\lib\ext :gotJavaExtDirs 3. If the user does not defined JAVA_EXT_DIRS (the default case), the java.ext.dirs property is set to and the above status message is printed. Then, if the user defines JAVA_EXT_DIRS, the existing behavior is enabled. Since new Tomcat users primarily use the installed scripts, this is a good way to protect Tomcat without preventing other custom scripts or launchers from enforcing a different standard. Does this sound like a reasonable approach? It would be nice to have this property setting in the Bootstrap.java class, but unfortunately, you must set the java.endorsed.dirs property when the JVM is started as it is immediately put in the JVM's bootstrap classpath. Thanks, Patrick Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- 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] -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7605] - Class loaders doesn't seem to load .zip 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=7605. 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=7605 Class loaders doesn't seem to load .zip libraries --- Additional Comments From [EMAIL PROTECTED] 2002-04-02 07:40 --- OK. That is not a bug. But what about writing more explicitely in the Class Loader HOWTO that .zip files will not be loaded? It may be a common mistake as I'm probably not the only one who uses the Oracle driver. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7681] New: - Tomcat does not work properly in multithread environment
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=7681. 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=7681 Tomcat does not work properly in multithread environment Summary: Tomcat does not work properly in multithread environment Product: Tomcat 4 Version: 4.0.4 Beta 2 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This bug exists also in version 4.01, so it is much possible it exists in all 4.x versions. I found that Tomcat has a quite serious bug, that causes it not working correctly when more than one thread is processing requests. The bug appears when the welcome file is a FRAMESET definition file, which does not access session object nor use beans - the first access of session is by session-scope bean definition in pages, that are loaded in frames from this frameset. Now, since browser makes requests for frames concurrently, each frame is usually processed by different Tomcat thread. And there is a problem: if two frames uses the same bean (of session scope), it often gets initialized twice !!! (it usually happens when the bean communicates with database during init, or makes other time-consumpting operation). The workaround is to make welcome file access the session (e.g. by setting some attribute or by reading session ID) - then the bean gets instantiated only once. The reason for this bug is in servlet generated from JSP: there are parts that are synchronized on session object - it does not make any sense, since session is an instance of StandardSessionFacade, which is a page-level object - it is created as new object on every page, and every time the page is accessed (just print it on System.out - every time, different address is printed); it would make sense if the synchronization was on HttpSession object encapsulated by StandardSessionFacade. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
