DO NOT REPLY [Bug 39221] New: - httpd / mod_jk / tomcat ErrorDocument 404 /servlet/xxx does not pass the missing document to tomcat
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=39221. 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=39221 Summary: httpd / mod_jk / tomcat ErrorDocument 404 /servlet/xxx does not pass the missing document to tomcat Product: Tomcat 5 Version: 5.5.16 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I have setup Apache 2.0.55 with mod_jk 1.2.15 talking to a tomcat 5.5.16. Everything works nice except one thing. I have the following httpd config entry: ErrorDocument 404 /servlet/SnoopServlet (i use a home made snoop servlet for easy testing) When i request a document that apache can not find (/somefile) the servlet is called as expected, but /somefile is not passed to tomcat, the only thing i can get from the request object is that /servlet/SnoopServlet was called. With resin i have a bit more luck, since mod_caucho sets the http header REDIRECT_URL: /somefile But i would rather use tomcat. Would it not be correct to set javax.servlet.error.request_uri request attribute to /somefile (or some other javax.servlet.* parameter, don't remember the spec.) and if that is not possible then set some request header like resin does? What i want to do it match /somefile against a 'redirect' database and if a match is found then send a redirect, if not send an error page. I'm not sure where the error is located, but my guess would be mod_jk, i have tried with several combinations of mod_jk and tomcat versions. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: configurable AJP Buffer Size
-Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 12:57 AM To: Tomcat Developers List Subject: Re: configurable AJP Buffer Size Henri Gomez wrote: well client and server should be in phase about the buffer size and the better way to accomplish that will be via AJP13 extensions (ie AJP14), with connect time negociation datas like packet buffer size :) Right. Extensions could contain packet size. The problem is that even with the custom size that size would be limited to 32K, and again someone will complain about that limitation ;) Possible. But, I have no idea why connector should be constraining this. - This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited. All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of Viruses or other Malware. Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39221] - httpd / mod_jk / tomcat ErrorDocument 404 /servlet/xxx does not pass the missing document to tomcat
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=39221. 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=39221 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2006-04-06 12:13 --- mod_jk is a proxy to the backend server. Trying to give some rewrite logic to it will never pass my +1. Since you are using Apache Httpd you have a thing like mod_rewrite and mod_headers. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configurable AJP Buffer Size
Just take a look at the AJP protocol documentation : http://tomcat.apache.org/connectors-doc/common/ajpv13a.html Packets sent from the server to the container begin with 0x1234. Packets sent from the container to the server begin with AB (that's the ASCII code for A followed by the ASCII code for B). After those first two bytes, there is an integer (encoded as above) with the length of the payload. Although this might suggest that the maximum payload could be as large as 2^16, in fact, the code sets the maximum to be 8K. So to support more than 64k bytes, we should have a whole new code on Apache and Tomcat side and break compatibility with all current implementations. And that's bad ;( Take a look at the AJP13 extension proposal : http://tomcat.apache.org/connectors-doc/common/ajpv13ext.html We could plug many usefull informations in LOGIN INIT for example ! 2006/4/6, KARNATI, SRINIVASA R [AG/1000] [EMAIL PROTECTED]: -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 12:57 AM To: Tomcat Developers List Subject: Re: configurable AJP Buffer Size Henri Gomez wrote: well client and server should be in phase about the buffer size and the better way to accomplish that will be via AJP13 extensions (ie AJP14), with connect time negociation datas like packet buffer size :) Right. Extensions could contain packet size. The problem is that even with the custom size that size would be limited to 32K, and again someone will complain about that limitation ;) Possible. But, I have no idea why connector should be constraining this. - This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited. All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto. The recipient of this e-mail is solely responsible for checking for the presence of Viruses or other Malware. Monsanto accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment. - - 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]
Re: configurable AJP Buffer Size
Henri Gomez wrote: Just take a look at the AJP protocol documentation : http://tomcat.apache.org/connectors-doc/common/ajpv13a.html Packets sent from the server to the container begin with 0x1234. Packets sent from the container to the server begin with AB (that's the ASCII code for A followed by the ASCII code for B). After those first two bytes, there is an integer (encoded as above) with the length of the payload. Although this might suggest that the maximum payload could be as large as 2^16, in fact, the code sets the maximum to be 8K. So to support more than 64k bytes, we should have a whole new code on Apache and Tomcat side and break compatibility with all current implementations. And that's bad ;( We recently saw a customer run into this limitation in that all of their headers, etc, would not fit in the first 8K. Waiting for a new AJP version sounds like a non-starter. Can we just have something like a JkOption that allows one to explicitly opt into this arrangement? Address this for mod_jk and Tomcat and one is done for now (though a mod_proxy_ajp shouldn't be far behind). Take a look at the AJP13 extension proposal : http://tomcat.apache.org/connectors-doc/common/ajpv13ext.html We could plug many usefull informations in LOGIN INIT for example ! These proposals all look interesting. The problem is that there are lots of proposals and this would seem to inevitably take quite some time to stabilize all of this in mod_jk, mod_proxy_ajp, and Tomcat (native and Java). I'd love to be proven wrong, though. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39221] - httpd / mod_jk / tomcat ErrorDocument 404 /servlet/xxx does not pass the missing document to tomcat
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=39221. 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=39221 --- Additional Comments From [EMAIL PROTECTED] 2006-04-06 12:51 --- I never proposed any rewrite logic, i only proposed to pass the original request url/uri to tomcat, when invoked as an ErrorDocument. Why should i have to obscufate my apache configuration to do some basic error handling? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configurable AJP Buffer Size
2006/4/6, Jess Holle [EMAIL PROTECTED]: Henri Gomez wrote: Just take a look at the AJP protocol documentation : http://tomcat.apache.org/connectors-doc/common/ajpv13a.html Packets sent from the server to the container begin with 0x1234. Packets sent from the container to the server begin with AB (that's the ASCII code for A followed by the ASCII code for B). After those first two bytes, there is an integer (encoded as above) with the length of the payload. Although this might suggest that the maximum payload could be as large as 2^16, in fact, the code sets the maximum to be 8K. So to support more than 64k bytes, we should have a whole new code on Apache and Tomcat side and break compatibility with all current implementations. And that's bad ;( We recently saw a customer run into this limitation in that all of their headers, etc, would not fit in the first 8K. Waiting for a new AJP version sounds like a non-starter. Can we just have something like a JkOption that allows one to explicitly opt into this arrangement? Address this for mod_jk and Tomcat and one is done for now (though a mod_proxy_ajp shouldn't be far behind). Well it could be done like this. Take a look at the AJP13 extension proposal : http://tomcat.apache.org/connectors-doc/common/ajpv13ext.html We could plug many usefull informations in LOGIN INIT for example ! These proposals all look interesting. The problem is that there are lots of proposals and this would seem to inevitably take quite some time to stabilize all of this in mod_jk, mod_proxy_ajp, and Tomcat (native and Java). I'd love to be proven wrong, though. Not necessary, if you take a look at curent jk/ajp implementations (native and java), there is allready code in it for AJP14 support :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5.16 compile problem on Solaris 10
Hello
If this is the wrong mailing list then I appoligise.
When compiling tomcat 5.5.16 on a solaris 10 (sparc) I get the following
error.
Can anyone please advice as to the problem so that I can continue?
I have simply downloaded the prerequirites into /usr share/jave and ran
ant in the tomcat directory.
Regards
Neville
compile:
[javac] Compiling 33 source files to
/ora/neville/apache-tomcat-5.5.16-src/s
ervletapi/jsr154/build/classes
[javac] Note:
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/src/sh
are/javax/servlet/ServletRequestWrapper.java uses or overrides a
deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note:
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/src/sh
are/javax/servlet/http/HttpUtils.java uses unchecked or unsafe
operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[copy] Copying 7 files to
/ora/neville/apache-tomcat-5.5.16-src/servletapi/
jsr154/build/classes
[copy] Copying 12 files to
/ora/neville/apache-tomcat-5.5.16-src/servletapi
/jsr154/build/classes/javax/servlet/resources
examples:
[copy] Copying 31 files to
/ora/neville/apache-tomcat-5.5.16-src/servletapi
/jsr154/build/examples
[javac] Compiling 11 source files to
/ora/neville/apache-tomcat-5.5.16-src/s
ervletapi/jsr154/build/examples/WEB-INF/classes
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB
-INF/classes/listeners/ContextListener.java:22: cannot find symbol
[javac] symbol : class ServletContextAttributeListener
[javac] location: package javax.servlet
[javac] import javax.servlet.ServletContextAttributeListener;
[javac] ^
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB
-INF/classes/listeners/ContextListener.java:38: cannot find symbol
[javac] symbol: class ServletContextAttributeListener
[javac] implements ServletContextAttributeListener,
ServletContextListen
er {
[javac]^
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB
-INF/classes/listeners/SessionListener.java:23: cannot find symbol
[javac] symbol : class HttpSessionAttributeListener
[javac] location: package javax.servlet.http
[javac] import javax.servlet.http.HttpSessionAttributeListener;
[javac] ^
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB
-INF/classes/listeners/SessionListener.java:41: cannot find symbol
[javac] symbol: class HttpSessionAttributeListener
[javac]HttpSessionAttributeListener, HttpSessionListener
{
[javac]^
[javac] 4 errors
BUILD FAILED
/ora/neville/apache-tomcat-5.5.16-src/build.xml:48: The following error
occurred
while executing this line:
/ora/neville/apache-tomcat-5.5.16-src/build/build.xml:1968: The
following error
occurred while executing this line:
/ora/neville/apache-tomcat-5.5.16-src/build/build.xml:651: The following
error o
ccurred while executing this line:
/ora/neville/apache-tomcat-5.5.16-src/build/build.xml:172: The following
error o
ccurred while executing this line:
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/build.xml:114:
Compile f
ailed; see the compiler error output for details.
Re: configurable AJP Buffer Size
Henri Gomez wrote: These proposals all look interesting. The problem is that there are lots of proposals and this would seem to inevitably take quite some time to stabilize all of this in mod_jk, mod_proxy_ajp, and Tomcat (native and Java). I'd love to be proven wrong, though. Not necessary, if you take a look at curent jk/ajp implementations (native and java), there is allready code in it for AJP14 support :) Including the ability to increase the packet size (or specifically to use a larger packet if necessary to capture all the headers)? How stable is AJP13 functionality in this code? I currently only need this one additional feature :-) -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.16 compile problem on Solaris 10
Hi,
Start from a clean build setup: you have a servlet.jar file from
Servlet Spec v2.3 (or earlier) which doesn't have the Listener(s)
added in Servlet Spec v2.4. To build Tomcat, you don't need to (and
shouldn't) set a CLASSPATH environment variable or otherwise muck with
the classpaths setup by Tomcat's build.xml files.
Yoav
On 4/6/06, Seed, Neville [EMAIL PROTECTED] wrote:
Hello
If this is the wrong mailing list then I appoligise.
When compiling tomcat 5.5.16 on a solaris 10 (sparc) I get the following
error.
Can anyone please advice as to the problem so that I can continue?
I have simply downloaded the prerequirites into /usr share/jave and ran
ant in the tomcat directory.
Regards
Neville
compile:
[javac] Compiling 33 source files to
/ora/neville/apache-tomcat-5.5.16-src/s
ervletapi/jsr154/build/classes
[javac] Note:
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/src/sh
are/javax/servlet/ServletRequestWrapper.java uses or overrides a
deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note:
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/src/sh
are/javax/servlet/http/HttpUtils.java uses unchecked or unsafe
operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[copy] Copying 7 files to
/ora/neville/apache-tomcat-5.5.16-src/servletapi/
jsr154/build/classes
[copy] Copying 12 files to
/ora/neville/apache-tomcat-5.5.16-src/servletapi
/jsr154/build/classes/javax/servlet/resources
examples:
[copy] Copying 31 files to
/ora/neville/apache-tomcat-5.5.16-src/servletapi
/jsr154/build/examples
[javac] Compiling 11 source files to
/ora/neville/apache-tomcat-5.5.16-src/s
ervletapi/jsr154/build/examples/WEB-INF/classes
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB
-INF/classes/listeners/ContextListener.java:22: cannot find symbol
[javac] symbol : class ServletContextAttributeListener
[javac] location: package javax.servlet
[javac] import javax.servlet.ServletContextAttributeListener;
[javac] ^
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB
-INF/classes/listeners/ContextListener.java:38: cannot find symbol
[javac] symbol: class ServletContextAttributeListener
[javac] implements ServletContextAttributeListener,
ServletContextListen
er {
[javac]^
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB
-INF/classes/listeners/SessionListener.java:23: cannot find symbol
[javac] symbol : class HttpSessionAttributeListener
[javac] location: package javax.servlet.http
[javac] import javax.servlet.http.HttpSessionAttributeListener;
[javac] ^
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB
-INF/classes/listeners/SessionListener.java:41: cannot find symbol
[javac] symbol: class HttpSessionAttributeListener
[javac]HttpSessionAttributeListener, HttpSessionListener
{
[javac]^
[javac] 4 errors
BUILD FAILED
/ora/neville/apache-tomcat-5.5.16-src/build.xml:48: The following error
occurred
while executing this line:
/ora/neville/apache-tomcat-5.5.16-src/build/build.xml:1968: The
following error
occurred while executing this line:
/ora/neville/apache-tomcat-5.5.16-src/build/build.xml:651: The following
error o
ccurred while executing this line:
/ora/neville/apache-tomcat-5.5.16-src/build/build.xml:172: The following
error o
ccurred while executing this line:
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/build.xml:114:
Compile f
ailed; see the compiler error output for details.
--
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: configurable AJP Buffer Size
KARNATI, SRINIVASA R [AG/1000] wrote: Possible. But, I have no idea why connector should be constraining this. ??? It is obvious by your comment that you have no clue how AJP protocol works, and why it has a fixed packet size in the spec. Also take a look at what protocol and specification means. According to your proposal one could say: When using http I wish that header name for content-length is now 'CL'; I please all the vendors to support my idea. -- Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5.16 compile problem on Solaris 10
Hello I am using servlet 2.4 and have made no change to CLASSPATH.
Below is the output from the command # ant output
Buildfile: build.xml
check.source:
get.source:
build:
proxyflags:
download:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-beanutils-1.7.0/commons-beanutils.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-collections-3.1/commons-collections-3.1.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for /usr/share/java/commons-el-1.0/commons-el.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-logging-1.0.4/commons-logging.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-modeler-1.1/commons-modeler.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/logging-log4j-1.2.12/dist/lib/log4j-1.2.12.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-digester-1.7/commons-digester-1.7.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-fileupload-1.0/commons-fileupload-1.0.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for /usr/share/java/xerces-2_7_1/xml-apis.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for /usr/share/java/mx4j-3.0.1/lib/mx4j.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for /usr/share/java/junit3.8.1/junit.jar
downloadzip:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-launcher-0.9/bin/commons-launcher.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-httpclient-2.0/commons-httpclient-2.0.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for /usr/share/java/nsis-2.0/makensis.exe
downloadfile:
setproxy:
testexist:
[echo] Testing for /usr/share/java/struts-1.2.7/lib/struts.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-daemon-1.0.1/commons-daemon.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/tomcat-native-1.1.1/tomcat-native.tar.gz
downloadfile:
init:
build-depends:
build-servletapi:
[echo] == Building:
/usr/share/java/servlet-api-2.4/lib/servlet-api.jar
prepare:
static:
compile:
examples:
[javac] Compiling 11 source files to
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/build/examples/W
EB-INF/classes
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB-INF
/classes/listeners/ContextListener.java:22: cannot find symbol
[javac] symbol : class ServletContextAttributeListener
[javac] location: package javax.servlet
[javac] import javax.servlet.ServletContextAttributeListener;
[javac] ^
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB-INF
/classes/listeners/ContextListener.java:38: cannot find symbol
[javac] symbol: class ServletContextAttributeListener
[javac] implements ServletContextAttributeListener,
ServletContextListener {
[javac]^
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB-INF
/classes/listeners/SessionListener.java:23: cannot find symbol
[javac] symbol : class HttpSessionAttributeListener
[javac] location: package javax.servlet.http
[javac] import javax.servlet.http.HttpSessionAttributeListener;
[javac] ^
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB-INF
/classes/listeners/SessionListener.java:41: cannot find symbol
[javac] symbol: class HttpSessionAttributeListener
[javac]HttpSessionAttributeListener, HttpSessionListener
{
[javac]^
[javac] 4 errors
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Yoav Shapira
Sent: 06 April 2006 13:59
To: Tomcat Developers List
Subject: Re: Tomcat 5.5.16 compile problem on Solaris 10
Hi,
Start from a clean build setup: you have a servlet.jar file from Servlet
Spec v2.3 (or earlier) which doesn't have the Listener(s) added in
Servlet Spec v2.4. To build Tomcat, you don't need to (and
shouldn't) set a CLASSPATH environment variable or otherwise muck with
the classpaths setup by Tomcat's build.xml files.
Yoav
On 4/6/06, Seed, Neville [EMAIL PROTECTED] wrote:
Hello
If this is the wrong mailing list then I appoligise.
When compiling tomcat 5.5.16 on a solaris 10 (sparc) I get the
following error.
Can anyone please advice as to the problem so that I can continue?
I have simply downloaded the prerequirites into /usr share/jave and
ran ant in the tomcat directory.
Regards
Neville
compile:
[javac] Compiling 33 source files to
/ora/neville/apache-tomcat-5.5.16-src/s
ervletapi/jsr154/build/classes
[javac] Note:
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/src/sh
Re: Tomcat 5.5.16 compile problem on Solaris 10
Then I have no clue, it works just fine for me.
Yoav
On 4/6/06, Seed, Neville [EMAIL PROTECTED] wrote:
Hello I am using servlet 2.4 and have made no change to CLASSPATH.
Below is the output from the command # ant output
Buildfile: build.xml
check.source:
get.source:
build:
proxyflags:
download:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-beanutils-1.7.0/commons-beanutils.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-collections-3.1/commons-collections-3.1.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for /usr/share/java/commons-el-1.0/commons-el.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-logging-1.0.4/commons-logging.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-modeler-1.1/commons-modeler.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/logging-log4j-1.2.12/dist/lib/log4j-1.2.12.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-digester-1.7/commons-digester-1.7.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-fileupload-1.0/commons-fileupload-1.0.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for /usr/share/java/xerces-2_7_1/xml-apis.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for /usr/share/java/mx4j-3.0.1/lib/mx4j.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for /usr/share/java/junit3.8.1/junit.jar
downloadzip:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-launcher-0.9/bin/commons-launcher.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-httpclient-2.0/commons-httpclient-2.0.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for /usr/share/java/nsis-2.0/makensis.exe
downloadfile:
setproxy:
testexist:
[echo] Testing for /usr/share/java/struts-1.2.7/lib/struts.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/commons-daemon-1.0.1/commons-daemon.jar
downloadgz:
setproxy:
testexist:
[echo] Testing for
/usr/share/java/tomcat-native-1.1.1/tomcat-native.tar.gz
downloadfile:
init:
build-depends:
build-servletapi:
[echo] == Building:
/usr/share/java/servlet-api-2.4/lib/servlet-api.jar
prepare:
static:
compile:
examples:
[javac] Compiling 11 source files to
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/build/examples/W
EB-INF/classes
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB-INF
/classes/listeners/ContextListener.java:22: cannot find symbol
[javac] symbol : class ServletContextAttributeListener
[javac] location: package javax.servlet
[javac] import javax.servlet.ServletContextAttributeListener;
[javac] ^
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB-INF
/classes/listeners/ContextListener.java:38: cannot find symbol
[javac] symbol: class ServletContextAttributeListener
[javac] implements ServletContextAttributeListener,
ServletContextListener {
[javac]^
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB-INF
/classes/listeners/SessionListener.java:23: cannot find symbol
[javac] symbol : class HttpSessionAttributeListener
[javac] location: package javax.servlet.http
[javac] import javax.servlet.http.HttpSessionAttributeListener;
[javac] ^
[javac]
/ora/neville/apache-tomcat-5.5.16-src/servletapi/jsr154/examples/WEB-INF
/classes/listeners/SessionListener.java:41: cannot find symbol
[javac] symbol: class HttpSessionAttributeListener
[javac]HttpSessionAttributeListener, HttpSessionListener
{
[javac]^
[javac] 4 errors
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Yoav Shapira
Sent: 06 April 2006 13:59
To: Tomcat Developers List
Subject: Re: Tomcat 5.5.16 compile problem on Solaris 10
Hi,
Start from a clean build setup: you have a servlet.jar file from Servlet
Spec v2.3 (or earlier) which doesn't have the Listener(s) added in
Servlet Spec v2.4. To build Tomcat, you don't need to (and
shouldn't) set a CLASSPATH environment variable or otherwise muck with
the classpaths setup by Tomcat's build.xml files.
Yoav
On 4/6/06, Seed, Neville [EMAIL PROTECTED] wrote:
Hello
If this is the wrong mailing list then I appoligise.
When compiling tomcat 5.5.16 on a solaris 10 (sparc) I get the
following error.
Can anyone please advice as to the problem so that I can continue?
I have simply downloaded the prerequirites into /usr share/jave and
ran ant in the tomcat directory.
svn commit: r391990 - in /tomcat/tc6.0.x/trunk/java/javax/annotation: ./ security/
Author: remm
Date: Thu Apr 6 07:09:45 2006
New Revision: 391990
URL: http://svn.apache.org/viewcvs?rev=391990view=rev
Log:
- Add common annotations interfaces.
- The latest docs seem to indicate that it's Declare*s*Roles.
Added:
tomcat/tc6.0.x/trunk/java/javax/annotation/
tomcat/tc6.0.x/trunk/java/javax/annotation/Generated.java
tomcat/tc6.0.x/trunk/java/javax/annotation/PostConstruct.java
tomcat/tc6.0.x/trunk/java/javax/annotation/PreDestroy.java
tomcat/tc6.0.x/trunk/java/javax/annotation/Resource.java
tomcat/tc6.0.x/trunk/java/javax/annotation/Resources.java
tomcat/tc6.0.x/trunk/java/javax/annotation/security/
tomcat/tc6.0.x/trunk/java/javax/annotation/security/DeclaresRoles.java
tomcat/tc6.0.x/trunk/java/javax/annotation/security/DenyAll.java
tomcat/tc6.0.x/trunk/java/javax/annotation/security/PermitAll.java
tomcat/tc6.0.x/trunk/java/javax/annotation/security/RolesAllowed.java
tomcat/tc6.0.x/trunk/java/javax/annotation/security/RunAs.java
Added: tomcat/tc6.0.x/trunk/java/javax/annotation/Generated.java
URL:
http://svn.apache.org/viewcvs/tomcat/tc6.0.x/trunk/java/javax/annotation/Generated.java?rev=391990view=auto
==
--- tomcat/tc6.0.x/trunk/java/javax/annotation/Generated.java (added)
+++ tomcat/tc6.0.x/trunk/java/javax/annotation/Generated.java Thu Apr 6
07:09:45 2006
@@ -0,0 +1,40 @@
+/*
+ * Copyright 2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+
+package javax.annotation;
+
+import static java.lang.annotation.ElementType.ANNOTATION_TYPE;
+import static java.lang.annotation.ElementType.CONSTRUCTOR;
+import static java.lang.annotation.ElementType.FIELD;
+import static java.lang.annotation.ElementType.LOCAL_VARIABLE;
+import static java.lang.annotation.ElementType.METHOD;
+import static java.lang.annotation.ElementType.PACKAGE;
+import static java.lang.annotation.ElementType.PARAMETER;
+import static java.lang.annotation.ElementType.TYPE;
+import static java.lang.annotation.RetentionPolicy.SOURCE;
+
+import java.lang.annotation.Retention;
+import java.lang.annotation.Target;
+
[EMAIL PROTECTED]({ANNOTATION_TYPE, CONSTRUCTOR, FIELD, LOCAL_VARIABLE, METHOD,
PACKAGE, PARAMETER, TYPE})
[EMAIL PROTECTED](SOURCE)
+
+public @interface Generated {
+public String[] value();
+public String date() default ;
+public String comment() default ;
+}
Added: tomcat/tc6.0.x/trunk/java/javax/annotation/PostConstruct.java
URL:
http://svn.apache.org/viewcvs/tomcat/tc6.0.x/trunk/java/javax/annotation/PostConstruct.java?rev=391990view=auto
==
--- tomcat/tc6.0.x/trunk/java/javax/annotation/PostConstruct.java (added)
+++ tomcat/tc6.0.x/trunk/java/javax/annotation/PostConstruct.java Thu Apr 6
07:09:45 2006
@@ -0,0 +1,29 @@
+/*
+ * Copyright 2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+
+package javax.annotation;
+
+import static java.lang.annotation.ElementType.METHOD;
+import static java.lang.annotation.RetentionPolicy.RUNTIME;
+
+import java.lang.annotation.Retention;
+import java.lang.annotation.Target;
+
[EMAIL PROTECTED]({METHOD})
[EMAIL PROTECTED](RUNTIME)
+public @interface PostConstruct {
+}
Added: tomcat/tc6.0.x/trunk/java/javax/annotation/PreDestroy.java
URL:
http://svn.apache.org/viewcvs/tomcat/tc6.0.x/trunk/java/javax/annotation/PreDestroy.java?rev=391990view=auto
==
--- tomcat/tc6.0.x/trunk/java/javax/annotation/PreDestroy.java (added)
+++ tomcat/tc6.0.x/trunk/java/javax/annotation/PreDestroy.java Thu Apr 6
07:09:45 2006
@@ -0,0 +1,29 @@
+/*
+ * Copyright 2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in
Challenges for Java hosting
Hi, This thread started (for whatever reason) on the private list as part of an unrelated discussion. The point is to see what could be improved to make Tomcat more suitable for shared hosting, which is a very nice goal, but unfortunately with very serious issues. I don't see many improvements possibilities, as I consider the following solutions and problems (where each user would at least need its own vhost): - Every virtual host gets its own appBase folder. Having its own folder for JARs just won't work (or it means you were able to use the shared folder successfully, which I doubt). If you use the TOMCAT_HOME/TOMCAT_BASE stuff, each user can get its own shared folder. - There are still tons of JVMs to manage and monitor, which may be a problem. - If the connector should be shared, with the servlet containers running in separate processes, I don't see how to cross the process barrier except by going back to square one (httpd in front, with AJP and many JVMs/Tomcats, each with its own vhost). Some general problems for production are: - No self tuning of the JVM. - No actual isolation, throttling capabilities, etc, provided by the JVM. - Impossibility to control memory leaks (impossible to force discarding classloaders and all associated class defs and instances, for example). - Hard to do thread management (by that I mean, monitor and recover for threads stuck in loops or deadlocked). Any ideas ? I suppose native code could be used to improve the situation in some areas (although I don't know how to do it ;) ). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r391991 - in /tomcat/tc6.0.x/trunk/java/org/apache/catalina: deploy/ContextService.java deploy/NamingResources.java startup/WebRuleSet.java
Author: remm
Date: Thu Apr 6 07:13:54 2006
New Revision: 391991
URL: http://svn.apache.org/viewcvs?rev=391991view=rev
Log:
- Add support (note: not in NamingContextListener yet) for service-ref (after
all, there's support
for all other elements, so ...).
- Submitted by Fabien Carrion.
Added:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/deploy/ContextService.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebRuleSet.java
Added: tomcat/tc6.0.x/trunk/java/org/apache/catalina/deploy/ContextService.java
URL:
http://svn.apache.org/viewcvs/tomcat/tc6.0.x/trunk/java/org/apache/catalina/deploy/ContextService.java?rev=391991view=auto
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/deploy/ContextService.java
(added)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/deploy/ContextService.java
Thu Apr 6 07:13:54 2006
@@ -0,0 +1,235 @@
+/*
+ * Copyright 2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+
+package org.apache.catalina.deploy;
+
+import java.io.Serializable;
+
+/**
+ * Representation of a web service reference for a web application, as
+ * represented in a codelt;service-refgt;/code element in the
+ * deployment descriptor.
+ *
+ * @author Fabien Carrion
+ * @version $Revision: 303342 $ $Date: 2005-03-15 23:29:49 -0700 (Web, 15 Mar
2006) $
+ */
+
+public class ContextService extends ResourceBase implements Serializable {
+
+
+// - Properties
+
+
+/**
+ * The WebService reference name.
+ */
+private String displayname = null;
+
+public String getDisplayname() {
+return (this.displayname);
+}
+
+public void setDisplayname(String displayname) {
+this.displayname = displayname;
+}
+
+/**
+ * An icon for this WebService.
+ */
+private String icon = null;
+
+public String getIcon() {
+return (this.icon);
+}
+
+public void setIcon(String icon) {
+this.icon = icon;
+}
+
+/**
+ * An icon for this WebService.
+ */
+private String serviceinterface = null;
+
+public String getServiceinterface() {
+return (this.serviceinterface);
+}
+
+public void setServiceinterface(String serviceinterface) {
+this.serviceinterface = serviceinterface;
+}
+
+/**
+ * Contains the location (relative to the root of
+ * the module) of the web service WSDL description.
+ */
+private String wsdlfile = null;
+
+public String getWsdlfile() {
+return (this.wsdlfile);
+}
+
+public void setWsdlfile(String wsdlfile) {
+this.wsdlfile = wsdlfile;
+}
+
+/**
+ * A file specifying the correlation of the WSDL definition
+ * to the interfaces (Service Endpoint Interface, Service Interface).
+ */
+private String jaxrpcmappingfile = null;
+
+public String getJaxrpcmappingfile() {
+return (this.jaxrpcmappingfile);
+}
+
+public void setJaxrpcmappingfile(String jaxrpcmappingfile) {
+this.jaxrpcmappingfile = jaxrpcmappingfile;
+}
+
+/**
+ * Declares the specific WSDL service element that is being referred to.
+ * It is not specified if no wsdl-file is declared or if WSDL contains only
+ * 1 service element.
+ *
+ * A service-qname is composed by a namespaceURI and a localpart.
+ * It must be defined if more than 1 service is declared in the WSDL.
+ *
+ * serviceqname[0] : namespaceURI
+ * serviceqname[1] : localpart
+ */
+private String[] serviceqname = new String[2];
+
+public String[] getServiceqname() {
+return (this.serviceqname);
+}
+
+public void setServiceqname(String[] serviceqname) {
+this.serviceqname = serviceqname;
+}
+
+public void setServiceqname(String serviceqname, int i) {
+this.serviceqname[i] = serviceqname;
+}
+
+public void setNamespaceURI(String namespaceuri) {
+this.serviceqname[0] = namespaceuri;
+}
+
+public void setLocalpart(String localpart) {
+this.serviceqname[1] = localpart;
+}
+
+/**
+ * Declares a client dependency on the container to resolving a Service
Endpoint Interface
+ * to a WSDL port. It optionally associates the Service
svn commit: r391995 - /tomcat/tc6.0.x/trunk/build.xml
Author: remm
Date: Thu Apr 6 07:29:14 2006
New Revision: 391995
URL: http://svn.apache.org/viewcvs?rev=391995view=rev
Log:
- Add annotations JAR.
Modified:
tomcat/tc6.0.x/trunk/build.xml
Modified: tomcat/tc6.0.x/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/tomcat/tc6.0.x/trunk/build.xml?rev=391995r1=391994r2=391995view=diff
==
--- tomcat/tc6.0.x/trunk/build.xml (original)
+++ tomcat/tc6.0.x/trunk/build.xml Thu Apr 6 07:29:14 2006
@@ -37,6 +37,7 @@
!-- JAR artifacts --
property name=bootstrap.jar value=${tomcat.build}/bin/bootstrap.jar/
+ property name=annotations-api.jar
value=${tomcat.build}/lib/annotations-api.jar/
property name=servlet-api.jar
value=${tomcat.build}/lib/servlet-api.jar/
property name=jsp-api.jar value=${tomcat.build}/lib/jsp-api.jar/
property name=el-api.jar value=${tomcat.build}/lib/el-api.jar/
@@ -100,6 +101,16 @@
target name=build-only depends=build-prepare,compile,package /
target name=package
+
+!-- Common Annotations 1.0 JAR File --
+jar jarfile=${annotations-api.jar}
+ fileset dir=${tomcat.classes}
+include name=javax/annotation/** /
+!-- Javadoc and i18n exclusions --
+exclude name=**/package.html /
+exclude name=**/LocalStrings_* /
+ /fileset
+/jar
!-- Servlet 2.5 Implementation JAR File --
jar jarfile=${servlet-api.jar}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Challenges for Java hosting
Ideas? Yes, and it's very simple - use fork()! Obviously this is not going to work on Windows, but for the case of Java hosting, we largely don't care. Let's put this in perspective. Quite a few hosting providors (mine included) run PHP in CGI mode. Any less expensive solution is competitive. The notion is very simple. Load a single master instance of the JVM. Pre-load lots of common classes (a list customized by the hosting service). Pre-initialize lots of classes (again a customized list). When a user request comes in, fork() a copy of the master instance (including possibly a chroot()). The child then processes the request and exits. The master instance basically does nothing but sit around and wait for fork() requests. Assuming that fork() on your version of Unix has a good implementation of copy-on-write (something I have not been able to verify easily), then the incremental real memory use should be *very* small. You have to consider how (or if) to allow for long-running background threads. Successive requests for the same user will not use the JVM (whether this counts as an advantage or disadvantage is debatable). The JVM isn't going to be optimizing code. But you get excellent isolation, no concern over memory leaks (and other left-over cruft), and you should (vastly) out-perform PHP in CGI mode. On 4/6/06, Remy Maucherat [EMAIL PROTECTED] wrote: Hi, This thread started (for whatever reason) on the private list as part of an unrelated discussion. The point is to see what could be improved to make Tomcat more suitable for shared hosting, which is a very nice goal, but unfortunately with very serious issues. I don't see many improvements possibilities, as I consider the following solutions and problems (where each user would at least need its own vhost): - Every virtual host gets its own appBase folder. Having its own folder for JARs just won't work (or it means you were able to use the shared folder successfully, which I doubt). If you use the TOMCAT_HOME/TOMCAT_BASE stuff, each user can get its own shared folder. - There are still tons of JVMs to manage and monitor, which may be a problem. - If the connector should be shared, with the servlet containers running in separate processes, I don't see how to cross the process barrier except by going back to square one (httpd in front, with AJP and many JVMs/Tomcats, each with its own vhost). Some general problems for production are: - No self tuning of the JVM. - No actual isolation, throttling capabilities, etc, provided by the JVM. - Impossibility to control memory leaks (impossible to force discarding classloaders and all associated class defs and instances, for example). - Hard to do thread management (by that I mean, monitor and recover for threads stuck in loops or deadlocked). Any ideas ? I suppose native code could be used to improve the situation in some areas (although I don't know how to do it ;) ). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37356] - Tomcat does not invalidate sessions after session-timeout period has passed.
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=37356. 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=37356 --- Additional Comments From [EMAIL PROTECTED] 2006-04-06 17:42 --- As an aside it is possible to use atomics from Java 5 in lower versions over Java through the use of this open source library http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)
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=33453. 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=33453 --- Additional Comments From [EMAIL PROTECTED] 2006-04-06 18:07 --- Anyone? Bueller? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Challenges for Java hosting
On Thu, Apr 06, 2006 at 09:15:17AM -0700, Preston L. Bannister wrote: You have to consider how (or if) to allow for long-running background threads. Successive requests for the same user will not use the JVM (whether this counts as an advantage or disadvantage is debatable). The JVM isn't going to be optimizing code. The point of using an application server (instead of e.g. PHP) is that it maintains state on the server. You lose this by using fork(). So it's not going to work at all for real applications since your application returns to it's previous state after every request. Bye, Tino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36204] - Webapp unable to pick the Class by the shared classloader
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=36204. 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=36204 --- Additional Comments From [EMAIL PROTECTED] 2006-04-06 18:17 --- Can someone suggest me some workaround for this. not moving all jars to common/lib. If having a different directory is supported, then it will be fine. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Challenges for Java hosting
Well, that is one definition of real applications. There are other definitions. :) On 4/6/06, Tino Schwarze [EMAIL PROTECTED] wrote: On Thu, Apr 06, 2006 at 09:15:17AM -0700, Preston L. Bannister wrote: You have to consider how (or if) to allow for long-running background threads. Successive requests for the same user will not use the JVM (whether this counts as an advantage or disadvantage is debatable). The JVM isn't going to be optimizing code. The point of using an application server (instead of e.g. PHP) is that it maintains state on the server. You lose this by using fork(). So it's not going to work at all for real applications since your application returns to it's previous state after every request. Bye, Tino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39226] New: - Manager app deletes contents of symbolic links on undeploy
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=39226. 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=39226 Summary: Manager app deletes contents of symbolic links on undeploy Product: Tomcat 5 Version: 5.5.16 Platform: Sun OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: Webapps:Manager AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I have a context that contains symbolic links to other directories outside of Catalina base directory. These directories contain files that are shared across multiple contexts. When using the Manager app to undeploy a context, the contents of those linked directories are deleted. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Challenges for Java hosting
isn't it easier to give each user a pre-configured lightweight but own tomcat? leon On 4/6/06, Preston L. Bannister [EMAIL PROTECTED] wrote: Well, that is one definition of real applications. There are other definitions. :) On 4/6/06, Tino Schwarze [EMAIL PROTECTED] wrote: On Thu, Apr 06, 2006 at 09:15:17AM -0700, Preston L. Bannister wrote: You have to consider how (or if) to allow for long-running background threads. Successive requests for the same user will not use the JVM (whether this counts as an advantage or disadvantage is debatable). The JVM isn't going to be optimizing code. The point of using an application server (instead of e.g. PHP) is that it maintains state on the server. You lose this by using fork(). So it's not going to work at all for real applications since your application returns to it's previous state after every request. Bye, Tino. - 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]
Re: Challenges for Java hosting
I have one suggestion regarding tomcat and security manager, but I don´t know if it fits here. We have a huge problem managing security configuration (i.e. catalina.policy). We have a common base policy and an entry for each virtual host. Sometimes clients put unmanaged libraries that require special permissions. We have to reinitialize the JVM to make these permissions take effect. Thanks Renato --- Remy Maucherat [EMAIL PROTECTED] wrote: Hi, This thread started (for whatever reason) on the private list as part of an unrelated discussion. The point is to see what could be improved to make Tomcat more suitable for shared hosting, which is a very nice goal, but unfortunately with very serious issues. I don't see many improvements possibilities, as I consider the following solutions and problems (where each user would at least need its own vhost): - Every virtual host gets its own appBase folder. Having its own folder for JARs just won't work (or it means you were able to use the shared folder successfully, which I doubt). If you use the TOMCAT_HOME/TOMCAT_BASE stuff, each user can get its own shared folder. - There are still tons of JVMs to manage and monitor, which may be a problem. - If the connector should be shared, with the servlet containers running in separate processes, I don't see how to cross the process barrier except by going back to square one (httpd in front, with AJP and many JVMs/Tomcats, each with its own vhost). Some general problems for production are: - No self tuning of the JVM. - No actual isolation, throttling capabilities, etc, provided by the JVM. - Impossibility to control memory leaks (impossible to force discarding classloaders and all associated class defs and instances, for example). - Hard to do thread management (by that I mean, monitor and recover for threads stuck in loops or deadlocked). Any ideas ? I suppose native code could be used to improve the situation in some areas (although I don't know how to do it ;) ). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Challenges for Java hosting
Define lightweight. :) If we are talking about a small number of users, with high average utilization, this might be a good solution. In fact this is similar in resource usage to the virtual hosting (i.e. Xen) solutions. For more typical usage, the number of users is large, and the average utilization is low. In this case one (very rarely used) JVM per user is somewhat expensive. Note you could reduce the expense with the same approach of using a fork() of a single image, expecting copy-on-write to radically reduce the real memory use (virtual memory use would be larger). Depends on what target you are trying to hit. The hosting world (by numbers of users) is dominated by very low usage sites. Is this a goal for Java/Tomcat hosting? If you can beat PHP in CGI mode *both* in performance and in resource usage, then you have a pretty compelling solution. If you are fatter or slower - this is going to disinterest a lot of hosting providers. Note that this notion is pretty much a non-starter if Linux does not do copy-on-write with fork(). This was a big deal back in the late 1980's (big Lisp apps forking vi). Don't know if this made it's way into Linux. I'm pretty sure copy-on-write in fork() was in SunOS, but I don't know about Solaris. On 4/6/06, Leon Rosenberg [EMAIL PROTECTED] wrote: isn't it easier to give each user a pre-configured lightweight but own tomcat? leon On 4/6/06, Preston L. Bannister [EMAIL PROTECTED] wrote: Well, that is one definition of real applications. There are other definitions. :) On 4/6/06, Tino Schwarze [EMAIL PROTECTED] wrote: On Thu, Apr 06, 2006 at 09:15:17AM -0700, Preston L. Bannister wrote: You have to consider how (or if) to allow for long-running background threads. Successive requests for the same user will not use the JVM (whether this counts as an advantage or disadvantage is debatable). The JVM isn't going to be optimizing code. The point of using an application server (instead of e.g. PHP) is that it maintains state on the server. You lose this by using fork(). So it's not going to work at all for real applications since your application returns to it's previous state after every request. Bye, Tino. - 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]
DO NOT REPLY [Bug 39231] New: - The JAAS contract for LoginModule is broken
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=39231. 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=39231 Summary: The JAAS contract for LoginModule is broken Product: Tomcat 5 Version: 5.5.16 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The issue is that the custom JAAS's LoginModule.logout() method is never called. I guess this has been never implemented correctly (at least since Tomcat 5.5.9). The thing is that according to the JAAS spec, the LoginContext.logout() is supposed to invoke the logout method for each LoginModule configured for this LoginContext. So, somebody should be sure to call LoginContext.logout() method. The caller for this method could be either a server or a client. So, either Tomcat should provide some means to access the LoginContext to the clients, or Tomcat should take the responsibility to call this method by itself. I guess the solution could be for Tomcat to associate the instance of LoginContext with the user's session, and then Tomcat could invoke LoginContext.logout() when the session is being invalidated (both when the session times out or invalidated explicitely). I hope that I am correctly interpreting the JAAS spec. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Challenges for Java hosting
On 4/6/06, Preston L. Bannister [EMAIL PROTECTED] wrote: Define lightweight. :) only the basics you need for a webapp. no admin/manager, no clustering, no gadgets. To explain it: Besides large portals with own server farms and millions of hits, I often have small customers which get a dynamical website with some cms etc. The problem I had and still have, is that typical hosting providers (at least in germany) don't offer any support for java webapps, best you can get is support for jsps only which sucks. This is ugly, since the customer pays money for the webapp and asks me afterwards, why should he rent a complete server to host it. Therefore I started to rent servers myself, and re-rent it to the customer. The customer gets the complete package, mail, backup, ftp/ssh access and the webapp. To ensure this, each server has an apache running with two jsp container instances on it, one for production, one for testing versions. The customer pays less than he would pay for professional hosting, and I can refinance the server with 3-4 customers. However, having all test-webapps in one server, and needing to restart it from time to time isn't really cool. I'd prefer to give each customer two instances, which consumes low resources, maybe even multiple tomcat instances in one jvm (is that possible?), and keep them independent from each other. Therefore lightweight. And therefore pre-configured :-) regards Leon If we are talking about a small number of users, with high average utilization, this might be a good solution. In fact this is similar in resource usage to the virtual hosting (i.e. Xen) solutions. For more typical usage, the number of users is large, and the average utilization is low. In this case one (very rarely used) JVM per user is somewhat expensive. Note you could reduce the expense with the same approach of using a fork() of a single image, expecting copy-on-write to radically reduce the real memory use (virtual memory use would be larger). Depends on what target you are trying to hit. The hosting world (by numbers of users) is dominated by very low usage sites. Is this a goal for Java/Tomcat hosting? If you can beat PHP in CGI mode *both* in performance and in resource usage, then you have a pretty compelling solution. If you are fatter or slower - this is going to disinterest a lot of hosting providers. Note that this notion is pretty much a non-starter if Linux does not do copy-on-write with fork(). This was a big deal back in the late 1980's (big Lisp apps forking vi). Don't know if this made it's way into Linux. I'm pretty sure copy-on-write in fork() was in SunOS, but I don't know about Solaris. On 4/6/06, Leon Rosenberg [EMAIL PROTECTED] wrote: isn't it easier to give each user a pre-configured lightweight but own tomcat? leon On 4/6/06, Preston L. Bannister [EMAIL PROTECTED] wrote: Well, that is one definition of real applications. There are other definitions. :) On 4/6/06, Tino Schwarze [EMAIL PROTECTED] wrote: On Thu, Apr 06, 2006 at 09:15:17AM -0700, Preston L. Bannister wrote: You have to consider how (or if) to allow for long-running background threads. Successive requests for the same user will not use the JVM (whether this counts as an advantage or disadvantage is debatable). The JVM isn't going to be optimizing code. The point of using an application server (instead of e.g. PHP) is that it maintains state on the server. You lose this by using fork(). So it's not going to work at all for real applications since your application returns to it's previous state after every request. Bye, Tino. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r392122 - /tomcat/tc6.0.x/trunk/java/javax/annotation/Resource.java
Author: remm Date: Thu Apr 6 16:44:36 2006 New Revision: 392122 URL: http://svn.apache.org/viewcvs?rev=392122view=rev Log: - I don't know if this field is legitimate or not, but it's used by the rest of the patch. I'll check it. Modified: tomcat/tc6.0.x/trunk/java/javax/annotation/Resource.java Modified: tomcat/tc6.0.x/trunk/java/javax/annotation/Resource.java URL: http://svn.apache.org/viewcvs/tomcat/tc6.0.x/trunk/java/javax/annotation/Resource.java?rev=392122r1=392121r2=392122view=diff == --- tomcat/tc6.0.x/trunk/java/javax/annotation/Resource.java (original) +++ tomcat/tc6.0.x/trunk/java/javax/annotation/Resource.java Thu Apr 6 16:44:36 2006 @@ -37,4 +37,5 @@ public AuthenticationType authenticationType() default AuthenticationType.CONTAINER; public boolean shareable() default true; public String description() default ; +public String mappedName(); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r392122 - /tomcat/tc6.0.x/trunk/java/javax/annotation/Resource.java
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 4:45 PM To: tomcat-dev@jakarta.apache.org Subject: svn commit: r392122 - /tomcat/tc6.0.x/trunk/java/javax/annotation/Resource.java Author: remm Date: Thu Apr 6 16:44:36 2006 New Revision: 392122 URL: http://svn.apache.org/viewcvs?rev=392122view=rev Log: - I don't know if this field is legitimate or not, but it's used by the rest of the patch. I'll check it. Modified: tomcat/tc6.0.x/trunk/java/javax/annotation/Resource.java Modified: tomcat/tc6.0.x/trunk/java/javax/annotation/Resource.java URL: http://svn.apache.org/viewcvs/tomcat/tc6.0.x/trunk/java/javax/ annotation/Resource.java?rev=392122r1=392121r2=392122view=diff == --- tomcat/tc6.0.x/trunk/java/javax/annotation/Resource.java (original) +++ tomcat/tc6.0.x/trunk/java/javax/annotation/Resource.java Thu Apr 6 16:44:36 2006 @@ -37,4 +37,5 @@ public AuthenticationType authenticationType() default AuthenticationType.CONTAINER; public boolean shareable() default true; public String description() default ; +public String mappedName(); } From my copy of JSR-250, it looks like it should be there. However, it should have a default of . - 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]
DO NOT REPLY [Bug 31426] - OutOfMemoryError: unable to create new native thread - and tomcat hangs
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=31426. 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=31426 --- Additional Comments From [EMAIL PROTECTED] 2006-04-07 02:08 --- This is obviously a problem with at least not logging the problem! eBay gets OOM all the time in the application stack that are recoverable. This behavior is unacceptable for an enterprise server. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31426] - OutOfMemoryError: unable to create new native thread - and tomcat hangs
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=31426. 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=31426 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2006-04-07 02:08 --- This is obviously a problem with at least not logging the problem! eBay gets OOM all the time in the application stack that are recoverable. This behavior is unacceptable for an enterprise server. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configurable AJP Buffer Size
2006/4/6, Mladen Turk [EMAIL PROTECTED]: Jess Holle wrote: Henri Gomez wrote: We recently saw a customer run into this limitation in that all of their headers, etc, would not fit in the first 8K. Waiting for a new AJP version sounds like a non-starter. Can we just have something like a JkOption that allows one to explicitly opt into this arrangement? Address this for mod_jk and Tomcat and one is done for now (though a mod_proxy_ajp shouldn't be far behind). -1. Guys we are talking about protocol! Saying that one part can send a 32K while the other part is expecting 8K will in most cases lead to core dump. If the size is larger then 8K, this is not an AJP13 protocol any more, and I'll be -1 on any attempt to extend the packet size. Like said, we can talk about AJP14, but AJP13 is well established protocol, and ideas that tries to break it will never pass. Well configuring as I said previousy, settings buffer sire in mod_jk (via jkOptions or others way) couldn't be done without doing/settings the same on the Tomcat side. And that code is not present today in jk of course, but need to be introduce in all the Tomcat base (3.3/4.0/4.1/5.0 and 5.5). May be the better will be to discuss what should be the foundation of AJP13 successor. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Challenges for Java hosting
Write you own SecurityManager. http://java.sun.com/docs/books/tutorial/essential/system/writingSMgr.html I have one suggestion regarding tomcat and security manager, but I don´t know if it fits here. We have a huge problem managing security configuration (i.e. catalina.policy). We have a common base policy and an entry for each virtual host. Sometimes clients put unmanaged libraries that require special permissions. We have to reinitialize the JVM to make these permissions take effect. Thanks Renato --- Remy Maucherat [EMAIL PROTECTED] wrote: Hi, This thread started (for whatever reason) on the private list as part of an unrelated discussion. The point is to see what could be improved to make Tomcat more suitable for shared hosting, which is a very nice goal, but unfortunately with very serious issues. I don't see many improvements possibilities, as I consider the following solutions and problems (where each user would at least need its own vhost): - Every virtual host gets its own appBase folder. Having its own folder for JARs just won't work (or it means you were able to use the shared folder successfully, which I doubt). If you use the TOMCAT_HOME/TOMCAT_BASE stuff, each user can get its own shared folder. - There are still tons of JVMs to manage and monitor, which may be a problem. - If the connector should be shared, with the servlet containers running in separate processes, I don't see how to cross the process barrier except by going back to square one (httpd in front, with AJP and many JVMs/Tomcats, each with its own vhost). Some general problems for production are: - No self tuning of the JVM. - No actual isolation, throttling capabilities, etc, provided by the JVM. - Impossibility to control memory leaks (impossible to force discarding classloaders and all associated class defs and instances, for example). - Hard to do thread management (by that I mean, monitor and recover for threads stuck in loops or deadlocked). Any ideas ? I suppose native code could be used to improve the situation in some areas (although I don't know how to do it ;) ). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
