Re: job opportunity
Steven, I'm a Senior Architect/Developer in NY with more then 15 years industry experience and I've been working with Tomcat/JBoss for more then 3 years. If you're interested please contact me via email ([EMAIL PROTECTED]) or cellphone (646.209.4143). My resume is attached. Regards, -- Bernd Prager - Original Message - From: Steven Pincus [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, June 02, 2003 9:27 AM Subject: job opportunity Greetings - By way of introduction, my name is Steven Pincus and I work for an executive search firm in NY by the name of R.W. Davis Co. We are currently working, on behalf of our large investment banking client, to locate a TomCat/JBoss expert. I was hoping to connect with you to find out if you would be interested in discussing this role in a bit more detail, either for yourself or someone you may know. I would appreciate a prompt call back. Thanks - Steven Steven Pincus R.W. Davis Co. 90 Park Avenue New York, NY 10016 Tel. (212)231-4400 ext. 216 Fax (212)993-8080 Cell (973)722-2163 [EMAIL PROTECTED] www.rwdavisco.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18595] - Jasper Compile error for paths with spaces in them
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=18595. 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=18595 Jasper Compile error for paths with spaces in them --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 14:36 --- I have experienced this and have tracked it down to a problem in Ant. It is triggered by (a) a long javac command line, usually caused by long paths to a lib directory with lots of jars in it, combined with (b) spaces in the path to the Tomcat directory (more specifically to the work directory within the Tomcat directory). The problem is documented in Ant bug 10499. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19725] - jsp compiler fails on windows if context docbase is too long
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=19725. 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=19725 jsp compiler fails on windows if context docbase is too long --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 14:39 --- I can confirm that this is a problem with long paths. I have experienced this and have tracked it down to a problem in Ant. It is triggered by (a) a long javac command line, usually caused by long paths to a lib directory with lots of jars in it, combined with (b) spaces in the path to the Tomcat directory (more specifically to the work directory within the Tomcat directory). The problem is documented in Ant bug 10499. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18595] - Jasper Compile error for paths with spaces in them
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=18595. 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=18595 Jasper Compile error for paths with spaces in them --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 14:53 --- A duplicate was filed since; a (reported) possible workaround is to set the fork init-param of the Jasper servlet to false. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20171] - weird: log4j and filter initialization
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=20171. 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=20171 weird: log4j and filter initialization [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 15:33 --- It turns out that the problem was in our application. In catalina.sh, we messed up classpath a little bit to include log4j.jar for developement, this makes commons-logging to look for log4j even for catalina's internal logging calls (as I understand it). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15974] - Original stack trace is lost
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=15974. 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=15974 Original stack trace is lost [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 15:58 --- Please, read my original request again: As you can see, on the 4.1.18 version, the root cause does not show the stack trace entering the 'throwError' method of the class, as does the 3.3a version. Tomcat gave me *a* root cause, but not *the* root cause I would expect. Take a closer look at the root cause shown on Tomcat 4.1.18. From that, I wouldn't know that the 'throwError' method of my class generated the exception. Compare the two root causes I gave you: On 4.1.x: javax.servlet.ServletException: just testing at org.apache.jasper.runtime.PageContextImpl.handlePageException (PageContextImpl.java:533) at org.apache.jsp.myError_jsp._jspService(myError_jsp.java:49) [...] On 3.3.x: java.lang.Exception: just testing at com.eadweb.StackTraceTest.throwError(StackTraceTest.java:5) at myError_2._jspService(myError_2.java:53) [...] What's shown on both before the _jspService line? Is it equal? No! The second one shows the stack trace for the original root cause before the _jspService. That's why the throwError method of my class appears on it. In the first one (4.1.x), there's no information about my classes, but only about Tomcat's classes. As I said, it seems that the original stack trace is lost, and it's very bad, because knowing which of my classes generated the exception helps me much to fix the problem. Do you understand the problem now? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15974] - Original stack trace is lost
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=15974.
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=15974
Original stack trace is lost
--- Additional Comments From [EMAIL PROTECTED] 2003-06-03 16:06 ---
It seems like, at some point, the Tomcat's error handling classes did something
like this:
[...]
} catch (Exception ex /* original application exception */) {
throw new ServletException(ex.getMessage());
}
In this case, the stack trace of the original application exception caught is
lost, replaced by the ServletException's one.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18967] - NullPointerException instead of error message when running JspC
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=18967. 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=18967 NullPointerException instead of error message when running JspC --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 17:32 --- This bug is especially serious since it can hide errors that are not reproducible when precompilation is off. For instance, I added a taglib to my project. Without precompilation, I get no errors. When I precompile, I get an NPE with no explanation. After I realized that the taglib was the problem, I added another step to my build process (to pre-pre-compile the tags). However, since some time had passed since I added the tags, it wasn't obvious. In other words, this NPE hides errors that are difficult to fix (the don't precompile workaround isn't always available) and makes precompilation risky from a development standpoint. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Change docBase without losing requests?
[apologies if this comes through as a duplicate; the list management software seems to be upset about my envelope From address] I am working on a web app deployment mechanism based on tomcat. Tomcat's deployment options are excellent; I especially appreciate the ability to deploy a Context with an XML descriptor. What I need to be able to do is to update the code behind a particular web app, without losing any requests. reload seems to do an excellent job of this, but in my case, I have a large number of instances of the same application sharing code on disk. To update them, I want to change the context to point to a new docBase. Currently, the only way I see to do this within tomcat is by removing the context and installing a new one in its place. Of course, with this approach, there is a window here where requests will return an error, rather than being queued. Looking at how reload currently works, it seems like it should be relatively straightforward to extend tomcat to be able to do this. But is this the right approach? Is there a better plan? -- - mdz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] Commons dependencies
Tomcat 5.0.x, like many other major Jakarta projects, depends on a lot of stuff from the Commons. Most of those are in a stable state, but a few are either in between two stable releases, or not yet released. Here's the list of the components which will need to be released as stable before Tomcat 5.0 gets stable. I'm associating a proposed owner for the component, based on past interactions with the components. - el: Core JSP 2.0 feature; this is a critical component, and needs to get released simultaneaously with Tomcat 5; I think a RM is needed for that component [Kin-Man, Jan, Craig ?] - modeler: Basis for Tomcat 5 JMX features, with a lot of new impressively efficient functionality since release 1.0; again, a critical component [Costin (do you have enough time to continue being the RM of that component ?)] - daemon: Home of Mladen's procrun, a very promising exe wrapper for Java programs on Windows; this also contains a Unix wrapper for Java programs; the Unix wrapper could be advertised as the recommended solution to run Tomcat on 80 on Unix, and included as source with Tomcat's binary d/l; this component is currently in the sandbox, and would need to be either moved ASAP to commons proper, or be migrated to j-t-c (if thought to be too Tomcat specific to exist in the commons); a RM will be needed [Mladen, Jean-Frederic] - dbcp: There are some BZ issues related to DBCP, so if there's a new DBCP release (I've seen some Struts 1.1 related activity), we'll need to include it [Glenn] - fileupload: Used by the HTML manager to upload the webapp to be deployed; 1.0 RC 1 is soon to be released, with an API breakage (deprecated method removal between beta releases (TM)); 1.0 is supposed to occur before Struts 1.1 [Glenn] I think that's it for now. About the daemon Unix wrapper: there was some proprietary interfaces defined in there. It was agreed some time ago to use reflection instead of these interfaces; looking at the native code, the interfaces are still being used. Could that be fixed ? Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] Watchdog and test suites
The question is really simple: Where is Watchdog 5.0 (or whatever it will be called) ? Watchdog 4.0 can be used already to test a lot of stuff, but there's clearly a need (and AFAIK a requirement) to get the test suite out there along with TC 5. On the Tomcat side, I will try to resurrect the tester, and integrate it (with Watchdog) as part of the release target. I'll admit that's mostly for my own convinience (as with the whole release target, actually) :-) I'll do that (unless somebody does it in the meantime :) ) when I am done with the deployer refactoring. Thanks, Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Change docBase without losing requests?
Matt Zimmerman wrote: [apologies if this comes through as a duplicate; the list management software seems to be upset about my envelope From address] I am working on a web app deployment mechanism based on tomcat. Tomcat's deployment options are excellent; I especially appreciate the ability to deploy a Context with an XML descriptor. What I need to be able to do is to update the code behind a particular web app, without losing any requests. reload seems to do an excellent job of this, but in my case, I have a large number of instances of the same application sharing code on disk. To update them, I want to change the context to point to a new docBase. Currently, the only way I see to do this within tomcat is by removing the context and installing a new one in its place. Of course, with this approach, there is a window here where requests will return an error, rather than being queued. Looking at how reload currently works, it seems like it should be relatively straightforward to extend tomcat to be able to do this. But is this the right approach? Is there a better plan? Well, if you look at the (recent) archives for tomcat-dev, you'll see I'm working on a pretty extensive refactoring of the deployer in TC 5. That should provide the features you mention. You can comment or contribute if you wish, of course. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4350] - SSLAuthenticator did not associate SSO session
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=4350. 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=4350 SSLAuthenticator did not associate SSO session --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 18:34 --- Any news since October 2001 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs/images add.gif code.gif design.gif docs.gif fix.gif update.gif
remm2003/06/03 13:32:55
Modified:webapps/docs project.xml tomcat-docs.xsl
Added: webapps/docs changelog.xml developers.xml status.xml
webapps/docs/images add.gif code.gif design.gif docs.gif
fix.gif update.gif
Log:
- Add changelog, status, and developers list.
- All this is stolen from Slide; I've missed a nice changelog for too long, so
I plan to use that to do the TC 5.0.x changelog.
Revision ChangesPath
1.12 +5 -3 jakarta-tomcat-catalina/webapps/docs/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/project.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- project.xml 14 May 2003 22:08:02 - 1.11
+++ project.xml 3 Jun 2003 20:32:55 - 1.12
@@ -38,7 +38,7 @@
/menu
menu name=Reference
-item name=Release Noteshref=RELEASE-NOTES.txt/
+item name=Release Notes href=RELEASE-NOTES.txt/
item name=Tomcat Configuration href=config/index.html/
item name=JK Documentation href=coyote/jk2/index.html/
item name=Servlet API Javadocs href=servletapi/index.html/
@@ -47,13 +47,15 @@
menu name=Tomcat Development
item name=Building from Source href=BUILDING.txt/
-item name=Changelog href=CHANGELOG.txt/
+item name=Changelog href=changelog.html/
+item name=Statushref=status.html/
+item name=Developershref=developers.html/
item name=Functional Specs. href=catalina/funcspecs/index.html/
item name=Catalina Javadocs href=catalina/docs/api/index.html/
item name=Coyote Javadocs
href=coyote/api/org/apache/coyote/package-summary.html/
item name=HTTP/1.1 Javadocs href=coyote/http11/api/index.html/
item name=Util Javadocs href=coyote/util/index.html/
-item name=Jasper Javadocs
href=jasper/docs/api/index.html/
+item name=Jasper Javadocs href=jasper/docs/api/index.html/
/menu
/body
1.4 +88 -2 jakarta-tomcat-catalina/webapps/docs/tomcat-docs.xsl
Index: tomcat-docs.xsl
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/tomcat-docs.xsl,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- tomcat-docs.xsl 15 Jan 2003 03:40:43 - 1.3
+++ tomcat-docs.xsl 3 Jun 2003 20:32:55 - 1.4
@@ -33,7 +33,8 @@
xsl:variable name=sub-banner-fgselect='#ff'/
xsl:variable name=source-color select='#023264'/
xsl:variable name=attributes-color select='#023264'/
-
+ xsl:variable name=table-th-bg select='#039acc'/
+ xsl:variable name=table-td-bg select='#a0ddf0'/
!-- Process an entire document into an HTML page --
xsl:template match=document
@@ -324,6 +325,91 @@
a name={$name}xsl:apply-templates//a
/xsl:otherwise
/xsl:choose
+ /xsl:template
+
+ !-- Changelog related tags --
+ xsl:template match=changelog
+table border=0 cellpadding=2 cellspacing=2
+ xsl:apply-templates/
+/table
+ /xsl:template
+
+ xsl:template match=changelog/add
+tr
+ xsl:variable name=srcxsl:value-of
select=$relative-path//images/add.gif/xsl:variable
+ tdimg alt=add class=icon src={$src}//td
+ tdxsl:apply-templates//td
+/tr
+ /xsl:template
+
+ xsl:template match=changelog/update
+tr
+ xsl:variable name=srcxsl:value-of
select=$relative-path//images/update.gif/xsl:variable
+ tdimg alt=update class=icon src={$src}//td
+ tdxsl:apply-templates//td
+/tr
+ /xsl:template
+
+ xsl:template match=changelog/design
+tr
+ xsl:variable name=srcxsl:value-of
select=$relative-path//images/design.gif/xsl:variable
+ tdimg alt=design class=icon src={$src}//td
+ tdxsl:apply-templates//td
+/tr
+ /xsl:template
+
+ xsl:template match=changelog/docs
+tr
+ xsl:variable name=srcxsl:value-of
select=$relative-path//images/docs.gif/xsl:variable
+ tdimg alt=docs class=icon src={$src}//td
+ tdxsl:apply-templates//td
+/tr
+ /xsl:template
+
+ xsl:template match=changelog/fix
+tr
+ xsl:variable name=srcxsl:value-of
select=$relative-path//images/fix.gif/xsl:variable
+ tdimg alt=fix class=icon src={$src}//td
+ tdxsl:apply-templates//td
+/tr
+ /xsl:template
+
+ xsl:template match=changelog/scode
+tr
+ xsl:variable name=srcxsl:value-of
select=$relative-path//images/code.gif/xsl:variable
+ tdimg
cvs commit: jakarta-tomcat-5 build.xml CHANGELOG TODO.txt
remm2003/06/03 14:38:52
Modified:.build.xml
Removed: .CHANGELOG TODO.txt
Log:
- Remove old todo and changelog.
Revision ChangesPath
1.129 +0 -14 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.128
retrieving revision 1.129
diff -u -r1.128 -r1.129
--- build.xml 27 May 2003 19:37:18 - 1.128
+++ build.xml 3 Jun 2003 21:38:52 - 1.129
@@ -595,8 +595,6 @@
copy file=./RELEASE-NOTES
tofile=${tomcat.build}/webapps/tomcat-docs/RELEASE-NOTES.txt
filtering=true /
-copy file=./CHANGELOG
-tofile=${tomcat.build}/webapps/tomcat-docs/CHANGELOG.txt /
!-- Build JARs for webapps classes --
mkdir dir=${tomcat.build}/server/webapps/admin/WEB-INF/lib /
@@ -1245,9 +1243,6 @@
copy file=RELEASE-NOTES
todir=${tomcat.release}/v${version}
filtering=true/
-copy file=CHANGELOG
- todir=${tomcat.release}/v${version}
- filtering=true/
copy file=resources/welcome.main.html
tofile=${tomcat.release}/v${version}/README.html
filtering=true/
@@ -1284,8 +1279,6 @@
zipfileset dir=${tomcat.dist} prefix=${final.name}
includes=RELEASE-NOTES /
zipfileset dir=${tomcat.dist} prefix=${final.name}
- includes=CHANGELOG /
- zipfileset dir=${tomcat.dist} prefix=${final.name}
includes=RUNNING.txt /
zipfileset dir=${tomcat.dist} prefix=${final.name}
includes=BENCHMARKS.txt /
@@ -1302,8 +1295,6 @@
includes=README.txt /
zipfileset dir=${tomcat.dist} prefix=${final.name}-embed
includes=RELEASE-NOTES /
- zipfileset dir=${tomcat.dist} prefix=${final.name}-embed
- includes=CHANGELOG /
/zip
/target
@@ -1317,8 +1308,6 @@
includes=README.txt /
zipfileset dir=${tomcat.dist} prefix=${final.name}-deployer
includes=RELEASE-NOTES /
- zipfileset dir=${tomcat.dist} prefix=${final.name}-deployer
- includes=CHANGELOG /
/zip
/target
@@ -1368,7 +1357,6 @@
include name=LICENSE /
include name=README.txt /
include name=RELEASE-NOTES /
-include name=CHANGELOG /
include name=RUNNING.txt /
include name=BENCHMARKS.txt /
exclude name=bin/catalina.sh /
@@ -1394,7 +1382,6 @@
include name=LICENSE /
include name=README.txt /
include name=RELEASE-NOTES /
-include name=CHANGELOG /
/tarfileset
tarfileset dir=${tomcat.embed} prefix=${final.name}-embed
include name=** /
@@ -1412,7 +1399,6 @@
include name=LICENSE /
include name=README.txt /
include name=RELEASE-NOTES /
-include name=CHANGELOG /
/tarfileset
tarfileset dir=${tomcat.deployer} prefix=${final.name}-deployer
include name=** /
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[5] reference to 2.3 dtd instead of 2.4?
The dtd in jakarta-servletapi-5\jsr154\examples\WEB-INF\web.xml says: !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; Is this right? -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] reference to 2.3 dtd instead of 2.4?
Tim Funk wrote: The dtd in jakarta-servletapi-5\jsr154\examples\WEB-INF\web.xml says: !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; Is this right? Yes it is. The examples doesn't contains any new 2.4 features. Of course it will be better if we improve the examples to demonstrate the new 2.4 features. -- Jeanfrancois -Tim - 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 19382] - EL to String conversion outputs 0
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=19382.
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=19382
EL to String conversion outputs 0
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||WORKSFORME
--- Additional Comments From [EMAIL PROTECTED] 2003-06-04 00:26 ---
Hmm. The latest nighly shows that the output to be body onload=, as
expected. So I'll assume that this has been fixed.
As to ${param.onload + ''} results in 0. This is actually correct. JSP 2.0
JFD3 (http://jcp.org/aboutJava/communityprocess/first/jsr152/index3.html)
JSP.2.3.5.1 indicates that the operator +, when applied to null and '', results
in a value 0. In EL, + is used for additions, not concatenations.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20463] New: - Jasper2 ant task generate invalid package name
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=20463.
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=20463
Jasper2 ant task generate invalid package name
Summary: Jasper2 ant task generate invalid package name
Product: Tomcat 4
Version: 4.1.24
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
jasper2 ant task simple translate path name as package name, so a path like
'webapp/2' generate invalid package name '${package}.2'.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20463] - Jasper2 ant task generate invalid package name
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=20463. 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=20463 Jasper2 ant task generate invalid package name --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 02:05 --- Created an attachment (id=6618) a bug demo ant task example - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20463] - Jasper2 ant task generate invalid package name
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=20463.
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=20463
Jasper2 ant task generate invalid package name
--- Additional Comments From [EMAIL PROTECTED] 2003-06-04 02:11 ---
The attachment is a complete bug demo archived as jar file, here is ant task xml
snippet.
target name=JspC depends=init
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath refid=compile.classpath/
/taskdef
jasper2
verbose=3
package=jsp.foresee
uriroot=${webapp.home}
outputDir=${build.home}/src /
javac
srcdir=${build.home}/src
destdir=${build.home}/classes
deprecation=${compile.deprecation}
encoding=UTF-8
debug=on
classpath refid=compile.classpath/
/javac
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
StandardSession.java
Hi I am using Tomcat 4.0.6 with JBoss 3.0.5. I am getting the following exception when I try to set to the value into HttpSession. Note it is not always. Very randomly I get this exception. The same code works fine in many instances. Can someone address this problem? java.lang.IllegalStateException: removeAttribute: Session already invalidated at org.apache.catalina.session.StandardSession.removeAttribute(StandardSession.java:1052) at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1152) at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:191) at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:191) at org.apache.jsp.postlogin$jsp._jspService(postlogin$jsp.java:95) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:201) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2347) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1027) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1125) at java.lang.Thread.run(Thread.java:536) Thanks shankar.
Re: [5.0] Commons dependencies
Remy Maucherat wrote: - modeler: Basis for Tomcat 5 JMX features, with a lot of new impressively efficient functionality since release 1.0; again, a critical component [Costin (do you have enough time to continue being the RM of that component ?)] I have very little free time - if anyone could do the release it would be great. There are no changes from M1 - I'll check bugzilla to see what remains to be done. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18595] - Jasper Compile error for paths with spaces in them
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=18595. 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=18595 Jasper Compile error for paths with spaces in them --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 06:27 --- Hi Tomcat developers, the next ant nightly build (http://cvs.apache.org/builds/ant/nightly/2003-06-04) contains a fix for the bug 10499 see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10499 This might solve this issue too. Individual users might want to patch their ant.jar or replace it with the one of the nightly build if they are affected by this problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19725] - jsp compiler fails on windows if context docbase is too long
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=19725. 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=19725 jsp compiler fails on windows if context docbase is too long --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 06:31 --- As Joe Boon said, this might in fact be caused by the bug 10499 in ant. the next ant nightly build (http://cvs.apache.org/builds/ant/nightly/2003-06-04) contains a fix for the bug 10499 see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10499 This might solve this issue too. Individual users might want to patch their ant.jar or replace it with the one of the nightly build if they are affected by this problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19145] - http to https redirect fails on non-standard ports
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=19145. 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=19145 http to https redirect fails on non-standard ports --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 06:42 --- I just noticed that this problem does not occur in Opera 7. That is, with the ports left to 8080 and 8443, and the HTTP connector redirect port set to 8443, Opera 7 correctly forwards the request to the non-standard HTTPS port. On the hunch that this is an IE-only problem, I've been looking for a related knowledge base article on the Microsoft web site, but I haven't found it yet. If I find one, I'll post it here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Commons dependencies
Costin Manolache wrote: Remy Maucherat wrote: - modeler: Basis for Tomcat 5 JMX features, with a lot of new impressively efficient functionality since release 1.0; again, a critical component [Costin (do you have enough time to continue being the RM of that component ?)] I have very little free time - if anyone could do the release it would be great. There are no changes from M1 - I'll check bugzilla to see what remains to be done. Ok, I undertsand; too bad :-( Any volunteers ? (again, this is a critical item) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jasper bug exposed through Struts ?
Hello list, recently I filed the following bug against Struts: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20155 However, it is not quite clear that this is a Struts bug. The Struts developers argue in the bug report that this may be a bug in Jasper and its classloading behavior. Or at the very least, that there is a flaw in the jasper-howto document, and in the build.xml example, which should include application jar files in Jspc classpath: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jasper-howto.html Can the Jasper experts please comment on this ? Where is the problem ? Thanks Petr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] fileupload 1.0 RC 1 API breakage
The attached works for me (against commons-fileupload HEAD). I didn't do
anything about it since I wasn't sure which version of fileupload we were
targeting.
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]; Jakarta
Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 12:09 AM
Subject: [5.0] fileupload 1.0 RC 1 API breakage
FileUpload.setRepositoryPath(String) and FileItem(String) were removed
from the fileupload RC 1 release, which breaks the Tomcat 4.1.x and
5.0.x build. The first method has no apparent replacement (but I didn't
try to dig around).
This is clearly an unacceptable situation from the Tomcat perspective
:-( I'm hoping there can be positive solutions to the problem ...
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---BeginMessage---
Hi,
I'm not set up to build Tomcat, so I can't verify these changes, but I've
attached a patch that should fix the Gump breakage.
--
Martin Cooper
Craig McClanahan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-02/tomcat-catalina.html
Buildfile: build.xml
flags:
flags.display:
[echo] --- Build environment for Catalina ---
[echo] If ${property_name} is displayed, then the property is not
set)
[echo] --- Build options ---
[echo] full.dist=${full.dist}
[echo] build.sysclasspath=only
[echo] compile.debug=${compile.debug}
[echo] compile.deprecation=${compile.deprecation}
[echo] compile.optimize=${compile.optimize}
[echo] --- Ant Flags ---
[echo] style task available (required)=true
[echo] --- JDK ---
[echo] jdk.1.2.present=true
[echo] jdk.1.3.present=true
[echo] jdk.1.4.present=true
[echo] --- Source Dependencies ---
[echo] jtc.home.present=true
[echo] --- Required Libraries ---
[echo] beanutils.present=true
[echo] collections.present=true
[echo] digester.present=true
[echo] jaxp.present=true
[echo] jndi.present=true
[echo] logging.present=true
[echo] regexp.present=true
[echo] servlet.present=true
[echo] --- Optional Libraries ---
[echo] daemon.present=${daemon.present}
[echo] dbcp.present=${dbcp.present}
[echo] fileupload.present=true
[echo] jaas.present=true
[echo] javamail.present=${javamail.present}
[echo] jmx.present=${jmx.present}
[echo] jsse.present=true
[echo] jta.present=${jta.present}
[echo] junit.present=${junit.present}
[echo] ldap.present=true
[echo] modeler.present=${modeler.present}
[echo] pool.present=${pool.present}
[echo] tyrex.present=${tyrex.present}
[echo] --- Required JARs ---
[echo] jndi.jar.present(except JDK 1.3+)=${jndi.jar.present}
[echo] regexp.jar.present=true
[echo] servlet.jar.present=true
[echo] xerces.jar.present(except JDK 1.4+ or
xerces2)=${xerces.jar.present}
[echo] xerces2.jars.present(except JDK 1.4+ or
xerces1)=${xerces2.jars.present}
[echo] --- Optional JARs ---
[echo] daemon.jar.present=${daemon.jar.present}
[echo] dbcp.jar.present=${dbcp.jar.present}
[echo] fileupload.jar.present=${fileupload.jar.present}
[echo] jaas.jar.present=${jaas.jar.present}
[echo] javamail.jar.present=${javamail.jar.present}
[echo] jdbc20ext.jar.present=${jdbc20ext.jar.present}
[echo] jmx.jar.present=${jmx.jar.present}
[echo] jta.jar.present=${jta.jar.present}
[echo] junit.jar.present=${junit.jar.present}
[echo] ldap.jar.present=${ldap.jar.present}
[echo] modeler.jar.present=${modeler.jar.present}
[echo] pool.jar.present=${pool.jar.present}
[echo] tyrex.jar.present=${tyrex.jar.present}
[echo] --- Conditional compilation flags ---
[echo] compile.daemon=${compile.daemon}
[echo] compile.dbcp=${compile.dbcp}
[echo] compile.jaas=true
[echo] compile.javamail=${compile.javamail}
[echo] compile.jmx=${compile.jmx}
[echo] compile.jndi=true
[echo] compile.jsse=true
[echo] compile.jta=${compile.jta}
[echo] compile.junit=${compile.junit}
[echo] compile.ldap=true
[echo] compile.ssi=true
[echo] compile.tyrex=${compile.tyrex}
[echo] --- Distribution flags ---
[echo] copy.daemon.jar=${copy.daemon.jar}
[echo] copy.dbcp.jar=${copy.dbcp.jar}
[echo] copy.jaas.jar=${copy.jaas.jar}
[echo] copy.jdbc20ext.jar=${copy.jdbc20ext.jar}
[echo] copy.javamail.jar=${copy.javamail.jar}
[echo] copy.jmx.jar=${copy.jmx.jar}
[echo] copy.jndi.jar=${copy.jndi.jar}
[echo]
DO NOT REPLY [Bug 19145] - http to https redirect fails on non-standard ports
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=19145. 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=19145 http to https redirect fails on non-standard ports --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 07:55 --- Well, maybe Opera is less strict than the other browsers. Could you check with a telnet and post the result ? If the location header has the correct scheme (https) and port number (8443), then the bug is with the clients (and, AFAIK, there's no possible workaround :-( ). telnet some_host 8080 GET /some_confidential_url HTTP/1.1 Host: some_host:8080 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Commons dependencies
Remy Maucherat wrote: Tomcat 5.0.x, like many other major Jakarta projects, depends on a lot of stuff from the Commons. Most of those are in a stable state, but a few are either in between two stable releases, or not yet released. Here's the list of the components which will need to be released as stable before Tomcat 5.0 gets stable. I'm associating a proposed owner for the component, based on past interactions with the components. - el: Core JSP 2.0 feature; this is a critical component, and needs to get released simultaneaously with Tomcat 5; I think a RM is needed for that component [Kin-Man, Jan, Craig ?] - modeler: Basis for Tomcat 5 JMX features, with a lot of new impressively efficient functionality since release 1.0; again, a critical component [Costin (do you have enough time to continue being the RM of that component ?)] - daemon: Home of Mladen's procrun, a very promising exe wrapper for Java programs on Windows; this also contains a Unix wrapper for Java programs; the Unix wrapper could be advertised as the recommended solution to run Tomcat on 80 on Unix, and included as source with Tomcat's binary d/l; this component is currently in the sandbox, and would need to be either moved ASAP to commons proper, or be migrated to j-t-c (if thought to be too Tomcat specific to exist in the commons); a RM will be needed [Mladen, Jean-Frederic] The daemon moved from tomcat to common and now back to tomcat. That does not help to advertise the project. - dbcp: There are some BZ issues related to DBCP, so if there's a new DBCP release (I've seen some Struts 1.1 related activity), we'll need to include it [Glenn] - fileupload: Used by the HTML manager to upload the webapp to be deployed; 1.0 RC 1 is soon to be released, with an API breakage (deprecated method removal between beta releases (TM)); 1.0 is supposed to occur before Struts 1.1 [Glenn] I think that's it for now. About the daemon Unix wrapper: there was some proprietary interfaces defined in there. It was agreed some time ago to use reflection instead of these interfaces; looking at the native code, the interfaces are still being used. Could that be fixed ? Sure. Comments ? Does someone has one example of code using reflection? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager HTMLManagerServlet.java
billbarker2003/06/04 00:58:59
Modified:webapps/manager/WEB-INF/classes/org/apache/catalina/manager
HTMLManagerServlet.java
Log:
Update to use the commons-fileupload-rc1 interface.
Submitted by: Martin Cooper [EMAIL PROTECTED]
Revision ChangesPath
1.2 +7 -7
jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
Index: HTMLManagerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- HTMLManagerServlet.java 26 Mar 2003 09:49:18 - 1.1
+++ HTMLManagerServlet.java 4 Jun 2003 07:58:58 - 1.2
@@ -84,7 +84,7 @@
import org.apache.catalina.Host;
import org.apache.catalina.util.ServerInfo;
import org.apache.commons.fileupload.FileItem;
-import org.apache.commons.fileupload.FileUpload;
+import org.apache.commons.fileupload.DiskFileUpload;
import org.apache.commons.fileupload.FileUploadException;
/**
@@ -195,7 +195,7 @@
String message = ;
// Create a new file upload handler
-FileUpload upload = new FileUpload();
+DiskFileUpload upload = new DiskFileUpload();
// Get the tempdir
File tempdir = (File) getServletContext().getAttribute
@@ -259,7 +259,7 @@
(htmlManagerServlet.installUploadWarExists,war);
break;
}
-warUpload.write(file.getCanonicalPath());
+warUpload.write(file);
try {
URL url = file.toURL();
war = url.toString();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.properties.default
billbarker2003/06/04 01:06:14
Modified:.build.properties.default
Log:
Default commons-fileupload to nightly build for now.
Revision ChangesPath
1.90 +4 -4 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.89
retrieving revision 1.90
diff -u -r1.89 -r1.90
--- build.properties.default 28 Apr 2003 17:50:25 - 1.89
+++ build.properties.default 4 Jun 2003 08:06:13 - 1.90
@@ -160,11 +160,11 @@
commons-pool.loc=http://www.apache.org/dist/jakarta/commons/pool/binaries/pool-1.0.1.tar.gz
-# - Commons FileUpload, version 1.0 or later -
-commons-fileupload.home=${base.path}/commons-fileupload-1.0-beta-1
+# - Commons FileUpload, version 1.0-20030531 or later -
+commons-fileupload.home=${base.path}/commons-fileupload-1.0-rc1
commons-fileupload.lib=${commons-fileupload.home}
commons-fileupload.jar=${commons-fileupload.lib}/commons-fileupload-1.0-beta-1.jar
-commons-fileupload.loc=http://www.apache.org/dist/jakarta/commons/fileupload/binaries/commons-fileupload-1.0-beta-1.tar.gz
+commons-fileupload.loc=http://www.apache.org/dist/jakarta/commons/nightly/fileupload/commons-fileupload-20030531.tar.gz
# - Java Management Extensions (JMX), JMX RI 1.0.1 or later or MX4J 1.1 or
later -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.properties.default
billbarker2003/06/04 01:20:43
Modified:.build.properties.default
Log:
Forgot one change.
Revision ChangesPath
1.91 +2 -2 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.90
retrieving revision 1.91
diff -u -r1.90 -r1.91
--- build.properties.default 4 Jun 2003 08:06:13 - 1.90
+++ build.properties.default 4 Jun 2003 08:20:43 - 1.91
@@ -163,7 +163,7 @@
# - Commons FileUpload, version 1.0-20030531 or later -
commons-fileupload.home=${base.path}/commons-fileupload-1.0-rc1
commons-fileupload.lib=${commons-fileupload.home}
-commons-fileupload.jar=${commons-fileupload.lib}/commons-fileupload-1.0-beta-1.jar
+commons-fileupload.jar=${commons-fileupload.lib}/commons-fileupload-1.0-dev.jar
commons-fileupload.loc=http://www.apache.org/dist/jakarta/commons/nightly/fileupload/commons-fileupload-20030531.tar.gz
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
someone@microsoft.com
Thank you for sending e-mail to [EMAIL PROTECTED] This is an automatic reply sent in response to your e-mail. [EMAIL PROTECTED] is an example e-mail account that is used only for testing purposes and is not monitored. For information related to Microsoft products, please check the Microsoft Web site at: http://www.microsoft.com For technical support information related to Microsoft products, please check the Microsoft Product Support Services Web site at: http://support.microsoft.com/directory/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP] Build Failure - tomcat-catalina
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-04/tomcat-catalina.html
Buildfile: build.xml
flags:
flags.display:
[echo] --- Build environment for Catalina ---
[echo] If ${property_name} is displayed, then the property is not set)
[echo] --- Build options ---
[echo] full.dist=${full.dist}
[echo] build.sysclasspath=only
[echo] compile.debug=${compile.debug}
[echo] compile.deprecation=${compile.deprecation}
[echo] compile.optimize=${compile.optimize}
[echo] --- Ant Flags ---
[echo] style task available (required)=true
[echo] --- JDK ---
[echo] jdk.1.2.present=true
[echo] jdk.1.3.present=true
[echo] jdk.1.4.present=true
[echo] --- Source Dependencies ---
[echo] jtc.home.present=true
[echo] --- Required Libraries ---
[echo] beanutils.present=true
[echo] collections.present=true
[echo] digester.present=true
[echo] jaxp.present=true
[echo] jndi.present=true
[echo] logging.present=true
[echo] regexp.present=true
[echo] servlet.present=true
[echo] --- Optional Libraries ---
[echo] daemon.present=${daemon.present}
[echo] dbcp.present=${dbcp.present}
[echo] fileupload.present=true
[echo] jaas.present=true
[echo] javamail.present=${javamail.present}
[echo] jmx.present=${jmx.present}
[echo] jsse.present=true
[echo] jta.present=${jta.present}
[echo] junit.present=${junit.present}
[echo] ldap.present=true
[echo] modeler.present=${modeler.present}
[echo] pool.present=${pool.present}
[echo] tyrex.present=${tyrex.present}
[echo] --- Required JARs ---
[echo] jndi.jar.present(except JDK 1.3+)=${jndi.jar.present}
[echo] regexp.jar.present=true
[echo] servlet.jar.present=true
[echo] xerces.jar.present(except JDK 1.4+ or xerces2)=${xerces.jar.present}
[echo] xerces2.jars.present(except JDK 1.4+ or xerces1)=${xerces2.jars.present}
[echo] --- Optional JARs ---
[echo] daemon.jar.present=${daemon.jar.present}
[echo] dbcp.jar.present=${dbcp.jar.present}
[echo] fileupload.jar.present=${fileupload.jar.present}
[echo] jaas.jar.present=${jaas.jar.present}
[echo] javamail.jar.present=${javamail.jar.present}
[echo] jdbc20ext.jar.present=${jdbc20ext.jar.present}
[echo] jmx.jar.present=${jmx.jar.present}
[echo] jta.jar.present=${jta.jar.present}
[echo] junit.jar.present=${junit.jar.present}
[echo] ldap.jar.present=${ldap.jar.present}
[echo] modeler.jar.present=${modeler.jar.present}
[echo] pool.jar.present=${pool.jar.present}
[echo] tyrex.jar.present=${tyrex.jar.present}
[echo] --- Conditional compilation flags ---
[echo] compile.daemon=${compile.daemon}
[echo] compile.dbcp=${compile.dbcp}
[echo] compile.jaas=true
[echo] compile.javamail=${compile.javamail}
[echo] compile.jmx=${compile.jmx}
[echo] compile.jndi=true
[echo] compile.jsse=true
[echo] compile.jta=${compile.jta}
[echo] compile.junit=${compile.junit}
[echo] compile.ldap=true
[echo] compile.ssi=true
[echo] compile.tyrex=${compile.tyrex}
[echo] --- Distribution flags ---
[echo] copy.daemon.jar=${copy.daemon.jar}
[echo] copy.dbcp.jar=${copy.dbcp.jar}
[echo] copy.jaas.jar=${copy.jaas.jar}
[echo] copy.jdbc20ext.jar=${copy.jdbc20ext.jar}
[echo] copy.javamail.jar=${copy.javamail.jar}
[echo] copy.jmx.jar=${copy.jmx.jar}
[echo] copy.jndi.jar=${copy.jndi.jar}
[echo] copy.jta.jar=${copy.jta.jar}
[echo] copy.ldap.jar=${copy.ldap.jar}
[echo] copy.logging.jar=true
[echo] copy.modeler.jar=${copy.modeler.jar}
[echo] copy.pool.jar=${copy.pool.jar}
[echo] copy.tyrex.jar=${copy.tyrex.jar}
[echo] copy.xerces.jar=${copy.xerces.jar}
[echo] copy.xerces2.jars=${copy.xerces2.jars}
build-prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/bin
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/classes
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/lib
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/common/endorsed
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/conf
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/logs
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/classes
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/server/lib
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-4.0/catalina/build/shared/classes
[mkdir] Created dir:
[GUMP] Build timed out - jk
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-04/jakarta-tomcat-jk-native.html
Buildfile: build.xml
init:
[echo] /home/rubys
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk
[echo] linux=true solaris=${solaris} win32=${win32} hpux=${hpux}
netware=${netware}
apache20:
apache13:
iis:
netscape:
jni:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni
[so] Compiling 4 out of 4
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_map.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_pool.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_util.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c
Linking /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni/jni_connect.so
/home/rubys/bin/timeout: timed out
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20473] New: - ajp13 connection between apache and tomcat is not encrypted
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=20473. 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=20473 ajp13 connection between apache and tomcat is not encrypted Summary: ajp13 connection between apache and tomcat is not encrypted Product: Tomcat 4 Version: 4.0 Beta 1 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The connection between apache and tomcat is not encrypted. This means if your network is breached and a packet sniffer installed then your credit card details / passwords etc can be picked up even though the connection to apache was https encrypted. This tar adds an extra channel which provides a TLS encrypted channel between apache and tomcat. With this encrypted channel this means that data transfer between apache and tomcat is re-encryted. The channel adds in the ability to do the following type of connections. tomcat apache communicate securly but not authenticating each other. Tomcat will only let in connections from a host who's cert has been signed by a CA it trusts. Apache will only connect to a tomcat whos CA it trusts Both apache and tomcat will only allow connections from to hosts that it trusts their CA. Note: This trusting has NOTHING to do with the browsers connection to apache. Both apache and tomcat will pass nothing to either end about this secure connection - it is as transparent as if it were a normal socket connection. Note - 2: You need jsse.jar and jcert.jar for tomcat and openssl for apache. Best if you have setup apache with ssl ( otherwise whats the point eh ?) I have this running with jdk1.4 on linux. Tested with both apache 1.3 and apache 2. I've used tomcat 4.1.24 on the tomcat end. Although I don't see why it won't work with any tomcat 4.x or tmocat 5.x versions. TC3 i don't know! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20473] - ajp13 connection between apache and tomcat is not encrypted
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=20473. 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=20473 ajp13 connection between apache and tomcat is not encrypted --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 11:05 --- Created an attachment (id=6621) tar gz of files needed both patches and new files (diff -c) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20473] - ajp13 connection between apache and tomcat is not encrypted
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=20473. 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=20473 ajp13 connection between apache and tomcat is not encrypted [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 11:08 --- Implementing encryption on this link will use too much resources, on both Apache and Tomcat side. If you absolutly need a cyphered support, I suggest you to use a ssh tunnel for such purporses. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20473] - ajp13 connection between apache and tomcat is not encrypted
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=20473. 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=20473 ajp13 connection between apache and tomcat is not encrypted [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|LATER | --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 12:07 --- So, Let me get this right. In order to use *less* resources we need to twice the amount of work ? ( ie on box a run apache sshtunnel and on box b run tomcat sshtunnel) This doesn't make sense to me. Having tested this on a p2 300 (both ends) it doesn't add much overhead to the poor box. AJP13 is very good with keep-alive connections. The majority of the overhead is on the initial connection. The encryption whilst the connection is alive is relativly low. That being said I can understand that the average user of Tomcat apache doesn't care too much about the security level between apache tomcat. The fact that they have a secure site with an insecure connecting layer won't bother them. However for the bigger/enterprise user of this technology, this might be of concern. Security teams will be interrested in this. Of course if you have two machines on the open net and you are taking credit card details etc please think about the implications. I suggest that in the same way that Java has the 'javax.' classes we should consider a level of extensions for mod_jk2. After all *ALL* the work has been done it's all here you just need to use it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20473] - ajp13 connection between apache and tomcat is not encrypted
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=20473. 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=20473 ajp13 connection between apache and tomcat is not encrypted [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 12:16 --- Using a ssh tunnel consume less resource SINCE you do crypto with native code on both side, whereas in you're solution, we're doing crypto on Apache (native) and Tomcat (java). In many configuration, Apache and Tomcat are on the same box, so the packet are local and when tomcats are remotes, which is the case for large deployment, the security SHOULD BE HANDLED for each configuration/requirement. I found a little crasy to see HTTP SSL requests, decryped by Apache, then reencrypted by Apache for Tomcat (in ajp13) and then redecrypted by Tomcat. Also you shoudn't use bugzilla for such reports. It's not an error but a missing feature so the request should be sent on tomcat-dev where developpers could respond to you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Error: unable to compile class for jsp
Hi, I have the following error when iam running my application and i couldn't figure out what exactly my problem is. I have searched the forums but none of the solution couldn't help to sort my problem. previously my application use to run properly but suddenly it use to give problem. iam using JBoss-2.4.3_Tomcat-3.2.3 and iam running the application on unix operating system. Here is the problem Error: 500 Location: /vinet/jsp/index.jsp Internal Servlet Error: org.apache.jasper.JasperException: Unable to compile class for JSP at org.apache.jasper.servlet.JspServlet.doLoadJSP(JspServlet.java:630) at org.apache.jasper.servlet.JasperLoader12.loadJSP(JasperLoader12.java:146) at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:542) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspSe rvlet.java:258) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:268) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:429) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:500) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405) at org.apache.tomcat.core.Handler.service(Handler.java:287) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:81 2) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:758) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:213) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) Root cause: java.lang.NullPointerException at org.apache.tomcat.loader.AdaptiveClassLoader.loadClass(AdaptiveClassLoader.j ava:471) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:136) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at org.apache.jasper.servlet.JspServlet.doLoadJSP(JspServlet.java:617) at org.apache.jasper.servlet.JasperLoader12.loadJSP(JasperLoader12.java:146) at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:542) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspSe rvlet.java:258) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:268) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:429) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:500) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405) at org.apache.tomcat.core.Handler.service(Handler.java:287) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:81 2) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:758) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:213) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) I have to solve it urgently. regards, phani. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 'missing feature' ajp13 connection between apache and tomcat is notencrypted
Taking this out of bugzilla. You say 'I found a little crasy to see HTTP SSL requests, decryped by Apache, then reencrypted by Apache for Tomcat (in ajp13) and then redecrypted by Tomcat.' How does this differ to your ssh tunnel idea ? Mine : browser talks https to apache apache connects directly to a secure channel which transfers ajp13 over the SSL encrypted link to tomcat. Resources On the sending server : encryption on apache making network connection to dest server. On the destination server: A SecureSocket connection decrypting data transfer ( in java of course) ssh tunnel version: browser talks https to apache apache connects to ssh tunnel running on localhostas plain uncrypted ajp13 which then connects to and encrypts the data transfer to another ssh tunnel running on the destination server which then decrypts the data and sends the plain ajp13 onto tomcat. Resources : On the sending server: ssh tunnel listening encrypting data transfered to it. On the destination server : ssh tunnel listening for inbound connections decrypting and connecting to Tomcat listening for inbound insecure connections. In essense both are doing the same. Just with the channel you don't have to rely on extra programs to work. I haven't done any speed comparisons between java doing encrypted links and native code. If you are saying that java just can't do encryption at a sufficient speed to be useful I'll have to take your word for it. Out of interrest is anyone out there using the https JK2 connector ? Does it work ? or is the speed of java doing encryption make the https connector unusable ? If there is a massive performance hit with Java doing SSL decryption it might be worth using sshtunnel on the destination server. But I really can't believe it will be that bad. Thanks David [EMAIL PROTECTED] rg To: [EMAIL PROTECTED] cc: 04/06/2003 13:16 Subject: DO NOT REPLY [Bug 20473] - ajp13 connection between apache and tomcat is not encrypted Please respond to Tomcat Developers List 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=20473. 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=20473 ajp13 connection between apache and tomcat is not encrypted [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-06-04 12:16 --- Using a ssh tunnel consume less resource SINCE you do crypto with native code on both side, whereas in you're solution, we're doing crypto on Apache (native) and Tomcat (java). In many configuration, Apache and Tomcat are on the same box, so the packet are local and when tomcats are remotes, which is the case for large deployment, the security SHOULD BE HANDLED for each configuration/requirement. I found a little crasy to see HTTP SSL requests, decryped by Apache, then reencrypted by Apache for Tomcat (in ajp13) and then redecrypted by Tomcat. Also you shoudn't use bugzilla for such reports. It's not an error but a missing feature so the request should be sent on tomcat-dev where developpers could respond to you.
Re: [5.0] Commons dependencies
I will take care of the HTML Manager and file upload if no one else gets to it. Same for a reveiw of DBCP. But I won't have time until next week. Regards, Glenn Remy Maucherat wrote: Tomcat 5.0.x, like many other major Jakarta projects, depends on a lot of stuff from the Commons. Most of those are in a stable state, but a few are either in between two stable releases, or not yet released. Here's the list of the components which will need to be released as stable before Tomcat 5.0 gets stable. I'm associating a proposed owner for the component, based on past interactions with the components. - el: Core JSP 2.0 feature; this is a critical component, and needs to get released simultaneaously with Tomcat 5; I think a RM is needed for that component [Kin-Man, Jan, Craig ?] - modeler: Basis for Tomcat 5 JMX features, with a lot of new impressively efficient functionality since release 1.0; again, a critical component [Costin (do you have enough time to continue being the RM of that component ?)] - daemon: Home of Mladen's procrun, a very promising exe wrapper for Java programs on Windows; this also contains a Unix wrapper for Java programs; the Unix wrapper could be advertised as the recommended solution to run Tomcat on 80 on Unix, and included as source with Tomcat's binary d/l; this component is currently in the sandbox, and would need to be either moved ASAP to commons proper, or be migrated to j-t-c (if thought to be too Tomcat specific to exist in the commons); a RM will be needed [Mladen, Jean-Frederic] - dbcp: There are some BZ issues related to DBCP, so if there's a new DBCP release (I've seen some Struts 1.1 related activity), we'll need to include it [Glenn] - fileupload: Used by the HTML manager to upload the webapp to be deployed; 1.0 RC 1 is soon to be released, with an API breakage (deprecated method removal between beta releases (TM)); 1.0 is supposed to occur before Struts 1.1 [Glenn] I think that's it for now. About the daemon Unix wrapper: there was some proprietary interfaces defined in there. It was agreed some time ago to use reflection instead of these interfaces; looking at the native code, the interfaces are still being used. Could that be fixed ? Comments ? Remy - 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: Error: unable to compile class for jsp
(this is more of a tomcat users problem as it's not to do with tomcat itself, but rather your application) But. It looks like your jsp file is trying to use a class which isn't availiable. Possibly the class file is corrupt or compiled with a different JDK I'm just guessing based on the null pointer exception below. You might want to check that the jar that contains the class is OK. All the best David phani [EMAIL PROTECTED]To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] nchi.comcc: Subject: Error: unable to compile class for jsp 04/06/2003 11:49 Please respond to Tomcat Developers List Hi, I have the following error when iam running my application and i couldn't figure out what exactly my problem is. I have searched the forums but none of the solution couldn't help to sort my problem. previously my application use to run properly but suddenly it use to give problem. iam using JBoss-2.4.3_Tomcat-3.2.3 and iam running the application on unix operating system. Here is the problem Error: 500 Location: /vinet/jsp/index.jsp Internal Servlet Error: org.apache.jasper.JasperException: Unable to compile class for JSP at org.apache.jasper.servlet.JspServlet.doLoadJSP(JspServlet.java:630) at org.apache.jasper.servlet.JasperLoader12.loadJSP(JasperLoader12.java:146) at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:542) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspSe rvlet.java:258) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:268) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:429) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:500) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405) at org.apache.tomcat.core.Handler.service(Handler.java:287) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:81 2) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:758) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:213) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) Root cause: java.lang.NullPointerException at org.apache.tomcat.loader.AdaptiveClassLoader.loadClass(AdaptiveClassLoader.j ava:471) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:136) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at org.apache.jasper.servlet.JspServlet.doLoadJSP(JspServlet.java:617) at org.apache.jasper.servlet.JasperLoader12.loadJSP(JasperLoader12.java:146) at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:542) at
RE: [5.0] Commons dependencies
I don't think I have commons commit privilege. Can you apply this one line patch? The log should say - Fix to return String instead of ObjectName type for getObjectName following JSR77 spec. cvs server: Diffing . Index: BaseModelMBean.java === RCS file: /home/cvs/jakarta-commons/modeler/src/java/org/apache/commons/modeler/ BaseModelMBean.java,v retrieving revision 1.22 diff -r1.22 BaseModelMBean.java 1325c1325 return oname; --- return oname.toString(); Thanks, Amy Costin Manolache [EMAIL PROTECTED] wrote: There seem to be no bugs open for modeler in Bugzilla (Zarro Boogs found ;)), so the next step is a release vote it appears... Yes. There is one problem that Amy reported few weeks ago - I don't know how it was resolved. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Free online calendar with sync to Outlook(TM).
[5.0] fileupload 1.0 RC 1 API breakage
FileUpload.setRepositoryPath(String) and FileItem(String) were removed from the fileupload RC 1 release, which breaks the Tomcat 4.1.x and 5.0.x build. The first method has no apparent replacement (but I didn't try to dig around). This is clearly an unacceptable situation from the Tomcat perspective :-( I'm hoping there can be positive solutions to the problem ... Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] fileupload 1.0 RC 1 API breakage
Martin Cooper wrote: I posted a patch to the Tomcat-Dev list yesterday which should fix this problem. Apparently, nobody on the Tomcat-Dev list paid any attention to my post. The methods in question have been deprecated for some time. I have not seen the patch email on tomcat-dev. Perhaps its in the moderator queue. BTW, use of FileUpload was implemented in Tomcat once there was a Beta release of FileUpload. So the API must have changed since the Beta release. I have gone out of my way to help FileUpload clients avoid exactly this kind of issue. It really ticks me off to see this kind of message, when I have gone to great lengths to make sure that the clients I know about are made aware of the changes before they happen. Thats great that you performed notifications to known clients. :-) Somehow Tomcat slipped through the cracks. :-( I don't recall seeing anything about this on the Tomcat list. I wlll admit that I subscribe to commons-dev but often don't keep up with messages related to the code bases there I am interested in. Get your own act together, Tomcat developers, before you start pointing the finger at those of us who really try hard to maintain compatibility across Jakarta projects. Was this really necessary? The email below went to both the commons-dev and tomcat -dev lists. If Remy was pointing the finger at anyone, it was at his fellow Tomcat Developers. Thats how I interpreted it. We (tomcat devs) will fix use of FileUpload in Tomcat and move on, no big deal. Regards, Glenn -- Martin Cooper On Wed, 4 Jun 2003, Remy Maucherat wrote: FileUpload.setRepositoryPath(String) and FileItem(String) were removed from the fileupload RC 1 release, which breaks the Tomcat 4.1.x and 5.0.x build. The first method has no apparent replacement (but I didn't try to dig around). This is clearly an unacceptable situation from the Tomcat perspective :-( I'm hoping there can be positive solutions to the problem ... Remy - 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]
