Re: Interested in GSOC ideas
On 04/01/2010 06:30 AM, Mahesh Fernando wrote: > On Sun, Mar 28, 2010 at 11:52 PM, Mark Thomas wrote: > >> On 28/03/2010 17:16, Mahesh Fernando wrote: >>> Hello all, >>> >>> I'm interested about JSR 196 implementation idea. I have some questions. >>> is there anyone to mentor this project? >> [1] >>> do we need to contact mentors before application period starts? >> [2] >>> is it needed to submit detailed designs for projects? >> [2] >>> how will the applications evaluated? >> [3] >>> do all the ideas have same priority during selection or are there some >> ideas >>> with high priorities? >> [3] >>> how many students do you take for tomcat ideas? >> [2],[3] >> > > > Thanks for providing links. > > I saw some other students interested on this idea and also JMX idea. Because > you are the mentor for these projects, will you choose only 1 project among > all these ideas or possible to mentor 2 or more projects? or is there > someone to co-mentor these? I saw Apache encourage to have 1 student per > mentor in above links. > I like the 'SPDY connector' idea too...but because it's still draft > version, will it become a problem to qualify? No. > I mean will it get approved when i make a proposal? > I hope it will. Cheers Jean-Frederic > >> >> [1] http://wiki.apache.org/tomcat/SummerOfCode2010 >> [2] >> http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs >> [3] http://community.apache.org/gsoc.html >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Interested in GSOC ideas
On 01/04/2010 05:30, Mahesh Fernando wrote: > I saw some other students interested on this idea and also JMX idea. Because > you are the mentor for these projects, will you choose only 1 project among > all these ideas or possible to mentor 2 or more projects? or is there > someone to co-mentor these? I saw Apache encourage to have 1 student per > mentor in above links. The proposals will be ranked and the top proposals will be accepted. If it looks like I might end up mentoring multiple projects I'll deal with that when the issue arises. Given students are meant to have been discussing their ideas on this list for the past two weeks, I haven't yet seen the degree of engagament with the Tomcat community I think is required to be successful at GSoC. One of the criteria I will be applying to determine community engagement is "Has the prospective student, submitted an appropriate patch for a non-trivial bugzilla issue, preferrably releated to the same area of code as their GSoC project." > I like the 'SPDY connector' idea too...but because it's still draft > version, will it become a problem to qualify? No. > I mean will it get approved when i make a proposal? The project, as an idea, is already approved. Whether or not it gets accepted is entirely down to the quality of any proposals submitted. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Regarding the Tomcat Manager Application
>Hello , >We are trying to make a security application similar to Tomcat Manager >application. >We have a problem in fetching the username & sessionID for all active sessions >using the tomcat APIs . >Can you please suggest how to get the userName & sessionID ? >If this is not the correct mailing list then could you please help me to post >it to the correct list. >Best Regards & Thanks in Advance, >Sushovan >Extn:8583874 >
Chunked encoding should be used also when not using keepalive
Hello.
Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding if
keepalive is not used. This happens when an HTTP 1.1 request contains a
"Connection: close" header.
I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
keepalive is disabled.
Chunked transfer-encoding is an alternative to content-length, for use when
the content-length cannot initially be determined. While it is mandatory to
have either of them to support keep-alive, its use is not restricted to
keep-alive and one useful immediate benefit of using it is to allow a client
to distinguish a connection abort from a complete response in order to avoid
storing truncated data.
Another useful case is when a reverse-proxy is installed in front of the
server, and this reverse proxy tries to maintain keep-alive connections with
the clients and intends to close the connections with the servers (like
apache 1.3, haproxy, and I think nginx). The lack of content-length and
chunked encoding prevents the proxy from keeping client connections alive.
The "connection: close" sent by the proxy to the server only indicates that
the proxy will send just one request to the server, not that it does not
care about the response length. The same is true when that proxy caches.
Without any content-length nor chunked encoding, the cache could store and
distribute truncated response believing they are complete, while this would
not happen with chunked encoding because the cache will be able to know it
has not seen the end of the response.
The fix seems easy. This is the patch:
Index: java/org/apache/coyote/http11/Http11Processor.java
===
--- java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
18:09:50 CET 2010
+++ java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
18:09:50 CET 2010
@@ -1547,7 +1547,7 @@
(outputFilters[Constants.IDENTITY_FILTER]);
contentDelimitation = true;
} else {
-if (entityBody && http11 && keepAlive) {
+if (entityBody && http11) {
outputBuffer.addActiveFilter
(outputFilters[Constants.CHUNKED_FILTER]);
contentDelimitation = true;
What do you think ?
Regards,
Oscar Frias
Trabber.com
Re: Chunked encoding should be used also when not using keepalive
On 01/04/2010 11:02, Óscar Frías Barranco wrote: > What do you think ? Seems reasonable but I'd like to hear from some of the other committers before making any changes. If the change is made, it needs to be made for all connectors, not just the BIO connector. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Chunked encoding should be used also when not using keepalive
On Thu, 2010-04-01 at 11:28 +0100, Mark Thomas wrote: > On 01/04/2010 11:02, Óscar Frías Barranco wrote: > > What do you think ? > > Seems reasonable but I'd like to hear from some of the other committers > before making any changes. > > If the change is made, it needs to be made for all connectors, not just > the BIO connector. It is not needed in the spec and is more expensive, as closing the connection is one of the valid content delimitation methods. His reverse proxy argument is probably the worst one: "connection: close" does not land in the response by accident, it is added for good reason. This is just begging for hacks at this point. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Chunked encoding should be used also when not using keepalive
Doing this would be bad. When serving JSP's (or anything dynamic greater than the buffer size) - the content length is not sent to the client. So when the end of the request is sent - there is no signal to the client to let them know the request is over and they can start a new request over the same connection. With chunked encoded - we can get away with no content length header because the each chunk as the length. -Tim On 4/1/2010 6:02 AM, Óscar Frías Barranco wrote: Hello. Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding if keepalive is not used. This happens when an HTTP 1.1 request contains a "Connection: close" header. I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if keepalive is disabled. Chunked transfer-encoding is an alternative to content-length, for use when the content-length cannot initially be determined. While it is mandatory to have either of them to support keep-alive, its use is not restricted to keep-alive and one useful immediate benefit of using it is to allow a client to distinguish a connection abort from a complete response in order to avoid storing truncated data. Another useful case is when a reverse-proxy is installed in front of the server, and this reverse proxy tries to maintain keep-alive connections with the clients and intends to close the connections with the servers (like apache 1.3, haproxy, and I think nginx). The lack of content-length and chunked encoding prevents the proxy from keeping client connections alive. The "connection: close" sent by the proxy to the server only indicates that the proxy will send just one request to the server, not that it does not care about the response length. The same is true when that proxy caches. Without any content-length nor chunked encoding, the cache could store and distribute truncated response believing they are complete, while this would not happen with chunked encoding because the cache will be able to know it has not seen the end of the response. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Chunked encoding should be used also when not using keepalive
Wait a sec ... not enough coffee. I might have answered a totally different question (and incorrectly too) -Tim On 4/1/2010 6:42 AM, Tim Funk wrote: Doing this would be bad. When serving JSP's (or anything dynamic greater than the buffer size) - the content length is not sent to the client. So when the end of the request is sent - there is no signal to the client to let them know the request is over and they can start a new request over the same connection. With chunked encoded - we can get away with no content length header because the each chunk as the length. -Tim On 4/1/2010 6:02 AM, Óscar Frías Barranco wrote: Hello. Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding if keepalive is not used. This happens when an HTTP 1.1 request contains a "Connection: close" header. I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if keepalive is disabled. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Chunked encoding should be used also when not using keepalive
On 01/04/2010 11:39, Remy Maucherat wrote: > On Thu, 2010-04-01 at 11:28 +0100, Mark Thomas wrote: >> On 01/04/2010 11:02, Óscar Frías Barranco wrote: >>> What do you think ? >> >> Seems reasonable but I'd like to hear from some of the other committers >> before making any changes. >> >> If the change is made, it needs to be made for all connectors, not just >> the BIO connector. > > It is not needed in the spec and is more expensive, as closing the > connection is one of the valid content delimitation methods. So it comes down to "Is the extra expense of chunked encoding a price worth paying so UAs and proxies can tell if a response was unexpectedly truncated, eg due to network error?" I don't have any hard figures (I'll see if I can come up with some) but my instinct is that this would be a price worth paying. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Chunked encoding should be used also when not using keepalive
Agree with Remy. If 'connection: close' is sent by the client, then tomcat needs to close the connection on the end of the response. So sending the results via chunked encoding is extra overhead which is not needed. A good argument to add is chunked encoding would that it gives the client the best guess on whether the entire response was returned (by receiving the last full chunk). But that argument is weak. -Tim On 4/1/2010 6:39 AM, Remy Maucherat wrote: On Thu, 2010-04-01 at 11:28 +0100, Mark Thomas wrote: On 01/04/2010 11:02, Óscar Frías Barranco wrote: What do you think ? Seems reasonable but I'd like to hear from some of the other committers before making any changes. If the change is made, it needs to be made for all connectors, not just the BIO connector. It is not needed in the spec and is more expensive, as closing the connection is one of the valid content delimitation methods. His reverse proxy argument is probably the worst one: "connection: close" does not land in the response by accident, it is added for good reason. This is just begging for hacks at this point. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Chunked encoding should be used also when not using keepalive
OMG ... That is the argument made in the original request. (I need to re-read and think more before response) I'm really sorry for the noise, worst april 1 ever. Please put me on /ignore for the rest of the day. My opinion on the change is +0. (The change has some penalties, but the net effect might be good) -Tim On 4/1/2010 6:54 AM, Tim Funk wrote: A good argument to add is chunked encoding would that it gives the client the best guess on whether the entire response was returned (by receiving the last full chunk). But that argument is weak. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Chunked encoding should be used also when not using keepalive
On Thu, Apr 1, 2010 at 12:52, Mark Thomas wrote: > So it comes down to "Is the extra expense of chunked encoding a price > worth paying so UAs and proxies can tell if a response was unexpectedly > truncated, eg due to network error?" > > I don't have any hard figures (I'll see if I can come up with some) but > my instinct is that this would be a price worth paying. > I forgot to mention that Apache HTTP Server uses chunked encoding also when it receives a "Connection: close" header. I do not know if they analized the trade-off but in any case this is what they do. Oscar
Re: Chunked encoding should be used also when not using keepalive
On Thu, Apr 1, 2010 at 12:39, Remy Maucherat wrote: > > His reverse proxy argument is probably the worst one: "connection: > close" does not land in the response by accident, it is added for good > reason. This is just begging for hacks at this point. > Sorry, I will try to clarify this point. Tomcat adding the "connection: close" header in the response is not the problem. Problem is that as the response (from Tomcat to the reverse proxy) does not contain a Content-Length and is not chunked, it cannot be included in a keepalived connection from the reverse proxy to the client.
[Tomcat Wiki] Trivial Update of "FrontPage" by Konstant inKolinko
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The "FrontPage" page has been changed by KonstantinKolinko.
The comment on this change is: Use direct link to FAQ pages, instead of going
through redirect at t.a.o.
http://wiki.apache.org/tomcat/FrontPage?action=diff&rev1=52&rev2=53
--
= Welcome to the Apache Tomcat Wiki =
{{http://tomcat.apache.org/images/tomcat.gif}}
- This is the Wiki for Apache Tomcat, a Servlet and Java Server Pages container
developed under the Apache License. The main documentation for this product is
at [[http://tomcat.apache.org|tomcat.apache.org]]. Below is a list of some
useful pages: we encourage everyone to contribute to these pages or start new
ones as desired. But before you do, please check out the main documentation
site as well as the [[http://tomcat.apache.org/faq|FAQ]] and the
[[http://tomcat.apache.org/lists.html|mailing lists]] (whose archives are
searchable).
+ This is the Wiki for Apache Tomcat, a Servlet and Java Server Pages container
developed under the Apache License. The main documentation for this product is
at [[http://tomcat.apache.org|tomcat.apache.org]]. Below is a list of some
useful pages: we encourage everyone to contribute to these pages or start new
ones as desired. But before you do, please check out the main documentation
site as well as the [[FAQ|FAQ]] and the
[[http://tomcat.apache.org/lists.html|mailing lists]] (whose archives are
searchable).
* '''[[GettingStarted|Getting Started]]''' - Getting started with Tomcat.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r929958 - /tomcat/tc5.5.x/trunk/STATUS.txt
Author: kkolinko Date: Thu Apr 1 13:16:35 2010 New Revision: 929958 URL: http://svn.apache.org/viewvc?rev=929958&view=rev Log: vote Modified: tomcat/tc5.5.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=929958&r1=929957&r2=929958&view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Thu Apr 1 13:16:35 2010 @@ -152,4 +152,9 @@ PATCHES PROPOSED TO BACKPORT: CATALINA_HOME so any issues will be visible then. Patch provided by mdietze +1: markt + 0: kkolinko: When CDPATH is set, it creates an ambiguity in behaviour of + "cd". That is why there is output there. + By the way, the patch that you are proposing is probably the following + (there is no link above): + http://svn.apache.org/viewvc?rev=928732&view=rev -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r929958 - /tomcat/tc5.5.x/trunk/STATUS.txt
On 01/04/2010 14:16, kkoli...@apache.org wrote: > Author: kkolinko > Date: Thu Apr 1 13:16:35 2010 > New Revision: 929958 > > URL: http://svn.apache.org/viewvc?rev=929958&view=rev > Log: > vote > > Modified: > tomcat/tc5.5.x/trunk/STATUS.txt > > Modified: tomcat/tc5.5.x/trunk/STATUS.txt > URL: > http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=929958&r1=929957&r2=929958&view=diff > == > --- tomcat/tc5.5.x/trunk/STATUS.txt (original) > +++ tomcat/tc5.5.x/trunk/STATUS.txt Thu Apr 1 13:16:35 2010 > @@ -152,4 +152,9 @@ PATCHES PROPOSED TO BACKPORT: >CATALINA_HOME so any issues will be visible then. >Patch provided by mdietze >+1: markt > + 0: kkolinko: When CDPATH is set, it creates an ambiguity in behaviour of > + "cd". That is why there is output there. > + By the way, the patch that you are proposing is probably the following > + (there is no link above): > + http://svn.apache.org/viewvc?rev=928732&view=rev The user may actually want the behaviour triggered by setting CDPATH hence why I opted to swallow the output rather than unset it. If the behaviour is unexpected, the display of CATALINA_HOME will at least show what is going on. That said, I had a hard time coming up with a use case where this was even an issue, let alone one where setting CDPATH was useful. If this doesn't gather enough votes then I'd be content with a WONTFIX resolution. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Chunked encoding should be used also when not using keepalive
+1 on switching to chunked by default.
I don't think the extra few bytes are a problem ( or few extra
objects/cycles on server ) - at least compared with not knowing if the
response was really fully sent.
Costin
2010/4/1 Óscar Frías Barranco
> Hello.
>
> Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding if
> keepalive is not used. This happens when an HTTP 1.1 request contains a
> "Connection: close" header.
> I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
> keepalive is disabled.
>
> Chunked transfer-encoding is an alternative to content-length, for use when
> the content-length cannot initially be determined. While it is mandatory
> to
> have either of them to support keep-alive, its use is not restricted to
> keep-alive and one useful immediate benefit of using it is to allow a
> client
> to distinguish a connection abort from a complete response in order to
> avoid
> storing truncated data.
>
> Another useful case is when a reverse-proxy is installed in front of the
> server, and this reverse proxy tries to maintain keep-alive connections
> with
> the clients and intends to close the connections with the servers (like
> apache 1.3, haproxy, and I think nginx). The lack of content-length and
> chunked encoding prevents the proxy from keeping client connections alive.
> The "connection: close" sent by the proxy to the server only indicates that
> the proxy will send just one request to the server, not that it does not
> care about the response length. The same is true when that proxy caches.
> Without any content-length nor chunked encoding, the cache could store and
> distribute truncated response believing they are complete, while this would
> not happen with chunked encoding because the cache will be able to know it
> has not seen the end of the response.
>
> The fix seems easy. This is the patch:
>
> Index: java/org/apache/coyote/http11/Http11Processor.java
> ===
> --- java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
> 18:09:50 CET 2010
> +++ java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
> 18:09:50 CET 2010
> @@ -1547,7 +1547,7 @@
> (outputFilters[Constants.IDENTITY_FILTER]);
> contentDelimitation = true;
> } else {
> -if (entityBody && http11 && keepAlive) {
> +if (entityBody && http11) {
> outputBuffer.addActiveFilter
> (outputFilters[Constants.CHUNKED_FILTER]);
> contentDelimitation = true;
>
>
> What do you think ?
>
> Regards,
> Oscar Frias
> Trabber.com
>
svn commit: r929990 - in /tomcat/tc5.5.x/trunk: STATUS.txt build/build.properties.default build/build.xml connectors/procrun/ container/webapps/docs/changelog.xml
Author: kkolinko
Date: Thu Apr 1 14:31:39 2010
New Revision: 929990
URL: http://svn.apache.org/viewvc?rev=929990&view=rev
Log:
Update to Commons Daemon 1.0.2 and use procrun from upstream distribution
Removed:
tomcat/tc5.5.x/trunk/connectors/procrun/
Modified:
tomcat/tc5.5.x/trunk/STATUS.txt
tomcat/tc5.5.x/trunk/build/build.properties.default
tomcat/tc5.5.x/trunk/build/build.xml
tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml
Modified: tomcat/tc5.5.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=929990&r1=929989&r2=929990&view=diff
==
--- tomcat/tc5.5.x/trunk/STATUS.txt (original)
+++ tomcat/tc5.5.x/trunk/STATUS.txt Thu Apr 1 14:31:39 2010
@@ -124,19 +124,6 @@ PATCHES PROPOSED TO BACKPORT:
+1: kkolinko, markt
-1:
-* Update to Commons Daemon 1.0.2 and use procrun from upstream distribution
- 1)
-svn delete connectors/procrun
- 2)
-
http://people.apache.org/~kkolinko/patches/2010-03-17_tc55_commons-daemon.patch
- +1: kkolinko, mturk, markt
- -1:
- kkolinko - I updated the patch to do not delete "deploy.old" target.
- Regarding "deploy.old": Note, that the commons-daemon files that
were
- copied in that target are already copied by "deploy-static", and
that
- I see no reason why one of the files was copied to
${tomcat.dist},
- as that target updates ${tomcat.build} only.
-
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48717
When a node joins a cluster and it receives all the current sessions, ensure
the sessionCreated event is fired if the Manager is configured to replicate
Modified: tomcat/tc5.5.x/trunk/build/build.properties.default
URL:
http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/build/build.properties.default?rev=929990&r1=929989&r2=929990&view=diff
==
--- tomcat/tc5.5.x/trunk/build/build.properties.default (original)
+++ tomcat/tc5.5.x/trunk/build/build.properties.default Thu Apr 1 14:31:39 2010
@@ -90,11 +90,16 @@ commons-launcher.loc=${base-commons.loc}
# - Commons Daemon, version 1.0-Alpha or later -
-commons-daemon.home=${base.path}/commons-daemon-1.0.1
-commons-daemon.lib=${commons-daemon.home}
-commons-daemon.jar=${commons-daemon.lib}/commons-daemon.jar
-commons-daemon.loc=${base-commons.loc}/daemon/binaries/commons-daemon-1.0.1.tar.gz
-commons-daemon.jsvc.tar.gz=${commons-daemon.lib}/bin/jsvc.tar.gz
+commons-daemon.version=1.0.2
+commons-daemon.home=${base.path}/commons-daemon-${commons-daemon.version}
+commons-daemon.jar=${commons-daemon.home}/commons-daemon-${commons-daemon.version}.jar
+commons-daemon.native.win.home=${commons-daemon.home}/windows
+commons-daemon.native.win.mgr.exe=${commons-daemon.native.win.home}/prunmgr.exe
+commons-daemon.native.src.tgz=${commons-daemon.home}/commons-daemon-${commons-daemon.version}-native-src.tar.gz
+commons-daemon.native.win.zip=${commons-daemon.home}/commons-daemon-${commons-daemon.version}-bin-windows.zip
+commons-daemon.bin.loc=${base-commons.loc}/daemon/binaries/${commons-daemon.version}/commons-daemon-${commons-daemon.version}-bin.tar.gz
+commons-daemon.native.src.loc=${base-commons.loc}/daemon/source/commons-daemon-${commons-daemon.version}-native-src.tar.gz
+commons-daemon.native.win.loc=${base-commons.loc}/daemon/binaries/${commons-daemon.version}/windows/commons-daemon-${commons-daemon.version}-bin-windows.zip
# - Commons Digester, version 1.4 or later -
Modified: tomcat/tc5.5.x/trunk/build/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/build/build.xml?rev=929990&r1=929989&r2=929990&view=diff
==
--- tomcat/tc5.5.x/trunk/build/build.xml (original)
+++ tomcat/tc5.5.x/trunk/build/build.xml Thu Apr 1 14:31:39 2010
@@ -222,12 +222,12 @@
-
-
-
+
+
+
@@ -703,13 +703,10 @@
+ description="Builds various dependent components - APIs, dbcp, jdt">
-
-
-
-
-
-
Target: Webapps precompilation ...
@@ -1542,16 +1534,16 @@
-
-
+
+
-
+
-
+
@@ -2062,11 +2054,23 @@
-
+
+
+
+
+
+
+
+
+
+
+
+
+
Modified: tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml?rev=929990&r1=929989&r2=929990&view=diff
==
--- tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml (original)
+++ tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml Thu Apr 1
14:31
svn commit: r929998 - in /tomcat/tc6.0.x/trunk: STATUS.txt build.properties.default build.xml dist.xml res/procrun/ webapps/docs/changelog.xml
Author: kkolinko
Date: Thu Apr 1 15:17:29 2010
New Revision: 929998
URL: http://svn.apache.org/viewvc?rev=929998&view=rev
Log:
Update to Commons Daemon 1.0.2 and use procrun from upstream distribution
Removed:
tomcat/tc6.0.x/trunk/res/procrun/
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/build.properties.default
tomcat/tc6.0.x/trunk/build.xml
tomcat/tc6.0.x/trunk/dist.xml
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=929998&r1=929997&r2=929998&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Apr 1 15:17:29 2010
@@ -187,14 +187,6 @@ PATCHES PROPOSED TO BACKPORT:
+1: kkolinko, markt
-1:
-* Update to Commons Daemon 1.0.2 and use procrun from upstream distribution
- 1)
-svn delete res/procrun
- 2)
-
http://people.apache.org/~kkolinko/patches/2010-03-11_tc6_commons-daemon.patch
- +1: kkolinko, mturk, markt
- -1:
-
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48795
Provide an option to allow recompilation on the next request following a JSP
compilation error rather than waiting modifcationTestInterval before the next
Modified: tomcat/tc6.0.x/trunk/build.properties.default
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/build.properties.default?rev=929998&r1=929997&r2=929998&view=diff
==
--- tomcat/tc6.0.x/trunk/build.properties.default (original)
+++ tomcat/tc6.0.x/trunk/build.properties.default Thu Apr 1 15:17:29 2010
@@ -86,8 +86,13 @@ nsis.nsisdl.dll=${nsis.home}/Plugins/NSI
nsis.loc=${base-sf.loc}/nsis/nsis-2.45.zip
# - Commons Daemon, version 1.0-Alpha or later -
-commons-daemon.home=${base.path}/commons-daemon-1.0.1
-commons-daemon.lib=${commons-daemon.home}
-commons-daemon.jar=${commons-daemon.lib}/commons-daemon.jar
-commons-daemon.loc=${base-commons.loc}/daemon/binaries/commons-daemon-1.0.1.tar.gz
-commons-daemon.jsvc.tar.gz=${commons-daemon.lib}/bin/jsvc.tar.gz
+commons-daemon.version=1.0.2
+commons-daemon.home=${base.path}/commons-daemon-${commons-daemon.version}
+commons-daemon.jar=${commons-daemon.home}/commons-daemon-${commons-daemon.version}.jar
+commons-daemon.native.win.home=${commons-daemon.home}/windows
+commons-daemon.native.win.mgr.exe=${commons-daemon.native.win.home}/prunmgr.exe
+commons-daemon.native.src.tgz=${commons-daemon.home}/commons-daemon-${commons-daemon.version}-native-src.tar.gz
+commons-daemon.native.win.zip=${commons-daemon.home}/commons-daemon-${commons-daemon.version}-bin-windows.zip
+commons-daemon.bin.loc=${base-commons.loc}/daemon/binaries/${commons-daemon.version}/commons-daemon-${commons-daemon.version}-bin.tar.gz
+commons-daemon.native.src.loc=${base-commons.loc}/daemon/source/commons-daemon-${commons-daemon.version}-native-src.tar.gz
+commons-daemon.native.win.loc=${base-commons.loc}/daemon/binaries/${commons-daemon.version}/windows/commons-daemon-${commons-daemon.version}-bin-windows.zip
Modified: tomcat/tc6.0.x/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/build.xml?rev=929998&r1=929997&r2=929998&view=diff
==
--- tomcat/tc6.0.x/trunk/build.xml (original)
+++ tomcat/tc6.0.x/trunk/build.xml Thu Apr 1 15:17:29 2010
@@ -473,9 +473,10 @@
+
-
-
+
@@ -719,11 +720,24 @@
+
-
+
+
+
+
+
+
+
+
+
+
+
+
+
Modified: tomcat/tc6.0.x/trunk/dist.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/dist.xml?rev=929998&r1=929997&r2=929998&view=diff
==
--- tomcat/tc6.0.x/trunk/dist.xml (original)
+++ tomcat/tc6.0.x/trunk/dist.xml Thu Apr 1 15:17:29 2010
@@ -306,15 +306,15 @@
-
-
-
-
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=929998&r1=929997&r2=929998&view=diff
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Thu Apr 1 15:17:29 2010
@@ -38,7 +38,16 @@
-
+
+
+
+ Update to Commons Daemon 1.0.2. Use service launcher (procrun)
+ from the Commons Daemon release. Do not keep a copy of it in our source
+ tree. (mturk/kkolinko)
+
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "PoweredBy" by DavidSmith
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The "PoweredBy" page has been changed by DavidSmith.
http://wiki.apache.org/tomcat/PoweredBy?action=diff&rev1=251&rev2=252
--
=== InnoShare ===
{{http://webmail.innoshare.com/images/innoshare_logo_small.jpg}}
[[http://www.innoshare.com/|InnoShare]] - A full-service
[[http://www.innoshare.com/services/atlanta-website-design|web design]],
[[http://www.innoshare.com/services/atlanta-email-newsletters|email
newsletter]],
[[http://www.innoshare.com/services/atlanta-business-web-hosting|web hosting]]
and
[[http://www.innoshare.com/services/atlanta-search-engine-optimization|search
engine optimization]] provider.
+
+ === Infrenion Networks ===
+
+ {{http://www.infrenion.com/images/logo.jpg}} "Cheap UK and US Web Hosting"
[[http://www.infrenion.com/|Infrenion Networks]] - Cheap UK and US Web Hosting
service provider with FFMPEG and TOMCAT v6
+
=== Javaprovider.net ===
{{http://javaprovider.net/img/logo.gif}} [[http://javaprovider.net|Java
Hosting]] - !WebApplication hosting company. We created Java Panel with Tomcat
6.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49035] New: data lost when post a multipart/form-data form
https://issues.apache.org/bugzilla/show_bug.cgi?id=49035 Summary: data lost when post a multipart/form-data form Product: Tomcat Connectors Version: 1.2.28 Platform: All OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: mod_jk AssignedTo: dev@tomcat.apache.org ReportedBy: alexandre.petri...@gmail.com I have a communication problem between Apache and Tomcat. When a post a big form with enctype="multipart/form-data". Sometimes some data are lost. I actived jk's log (with JkLogFile "logs/mod_jk.log" and JkLogLevel trace) and i see 2 packet to transport form's informations. And the lost data is localized between two packet like this : the lost data is : and packets are : --7da28a1a20 82a..Content-Dis position:.form-d ata;.name="utili sationRegroupeme nt[1]"46.0.. [Second packet] .4-- ---7da28a1a2082a ..Content-Dispos ition:.form-data ;.name="etatRegr oupement[1]" The problem is not systematic, it's depend of other input's size. When the transfert is correct i can see this : ---7da1d0620 82a..Content-Dis position:.form-d ata;.name="utili sationRegroupeme nt[1]"46.0.. -7da 1d062082a..Conte nt-Disposition:. form-data;.name= "etatRegroupemen .4.%.#t[1]"E ..-- ---7 da1d062082a..Con tent-Disposition :.form-data;.nam It's not same log. I use apache 2.2.8 mod_jk 1.2.30 (win32) Tomcat 6.x I'm sure it's a mod_jk with enctype="multipart/form-data", because without apache, or with mod_prox, or without enctype, i havn't problem. Thanks AP -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49016] naming-common.jar not compatible with Tomcat 5.5.28
https://issues.apache.org/bugzilla/show_bug.cgi?id=49016 Terry Dixon changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49016] naming-common.jar not compatible with Tomcat 5.5.28
https://issues.apache.org/bugzilla/show_bug.cgi?id=49016 --- Comment #2 from Terry Dixon 2010-04-01 18:43:52 UTC --- Further research of this issue shows that it was the re-jarring step that acutally solved the issue. That is to say that in was not necessary to re-compile the actual class objects within the naming-common.jar file, only to un-jar and re-jar the jar file using Ant1.6.5., this was the only step needed to have the naming-common.jar file successfully run during the classloading step of the tomcat5.5 startup, running under Red Hat Linux EL5, IBM's Java5 and Ant1.6.5. Still hoping for a offically updated version of the naming-common.jar file from catalina/apache/tomcat community. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49016] naming-common.jar not compatible with Tomcat 5.5.28
https://issues.apache.org/bugzilla/show_bug.cgi?id=49016 --- Comment #3 from Konstantin Kolinko 2010-04-01 20:27:43 UTC --- There is no "naming-common.jar" in Tomcat 5.5.28 release. The NamingContextBindingsEnumeration class is in $CATALINA_HOME\common\lib\naming-resources.jar -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49016] naming-common.jar not compatible with Tomcat 5.5.28
https://issues.apache.org/bugzilla/show_bug.cgi?id=49016 --- Comment #4 from Terry Dixon 2010-04-01 21:48:40 UTC --- Confirmed that by not including the naming-common.jar file in the CATALINA_HOME/common/lib directory, tomcat5.5.28 will startup without error. I think that it would be a worth while effort to add a note regarding the merging of the naming-common.jar and naming-resources.jar files as part of the tomcat5.5 Release-Notes so that others who are migrating from tomcat5 to tomcat5.5 will know not to bring the naming-common.jar forward to the tomcat5.5 installation. As of the current tomcat5.5.28 core download file, the Releaes-Notes still list naming-common.jar as part of the Bundled APIs. Thanks for the assistance. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49016] naming-common.jar not compatible with Tomcat 5.5.28
https://issues.apache.org/bugzilla/show_bug.cgi?id=49016 Terry Dixon changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49016] naming-common.jar not compatible with Tomcat 5.5.28
https://issues.apache.org/bugzilla/show_bug.cgi?id=49016 Mark Thomas changed: What|Removed |Added Resolution|WORKSFORME |INVALID --- Comment #5 from Mark Thomas 2010-04-01 22:09:15 UTC --- Correcting resolution. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [ANN] New Tomcat Committer: Keiichi Fujino (kfujino)
Thanks Filip, and thanks everyone for welcome to tomcat project. Best regards. 2010/4/1 Filip Hanik - Dev Lists : > On behalf of the Tomcat committers I am pleased to announce that Keiichi > Fujino (kfujino) has been voted in as a new Tomcat committer. > > Please join me in welcoming him. > > Regards, > Filip > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- Keiichi.Fujino - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r930151 - in /tomcat/site/trunk: docs/whoweare.html xdocs/whoweare.xml
Author: kfujino Date: Fri Apr 2 02:26:38 2010 New Revision: 930151 URL: http://svn.apache.org/viewvc?rev=930151&view=rev Log: Adding kfujino to committers. Modified: tomcat/site/trunk/docs/whoweare.html tomcat/site/trunk/xdocs/whoweare.xml Modified: tomcat/site/trunk/docs/whoweare.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/whoweare.html?rev=930151&r1=930150&r2=930151&view=diff == --- tomcat/site/trunk/docs/whoweare.html (original) +++ tomcat/site/trunk/docs/whoweare.html Fri Apr 2 02:26:38 2010 @@ -340,6 +340,11 @@ open-source projects: you can read more + +Keiichi Fujino (kfujino at apache.org) + + + Modified: tomcat/site/trunk/xdocs/whoweare.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/whoweare.xml?rev=930151&r1=930150&r2=930151&view=diff == --- tomcat/site/trunk/xdocs/whoweare.xml (original) +++ tomcat/site/trunk/xdocs/whoweare.xml Fri Apr 2 02:26:38 2010 @@ -103,6 +103,9 @@ open-source projects: you can read more Tim Whittington (timw at apache.org) +Keiichi Fujino (kfujino at apache.org) + + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47714] Reponse mixed between users
https://issues.apache.org/bugzilla/show_bug.cgi?id=47714 Nageshwar changed: What|Removed |Added Component|mod_jk |Library Version|1.2.28 |1.1.0 Product|Tomcat Connectors |Tomcat Native OS/Version|Linux |Windows 2000 --- Comment #14 from Nageshwar 2010-04-02 05:56:02 UTC --- # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x48b8e1fe, pid=1412, tid=716 # # JRE version: 6.0_16-b01 # Java VM: Java HotSpot(TM) Client VM (14.2-b01 mixed mode windows-x86 ) # Problematic frame: # C [tcnative-1.dll+0xe1fe] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x48710400): JavaThread "http-7000-1" daemon [_thread_in_native, id=716, stack(0x4a14,0x4a18)] siginfo: ExceptionCode=0xc005, reading address 0x0034 Registers: EAX=0x0001, EBX=0x, ECX=0x, EDX=0x0001 ESP=0x4a17ebd8, EBP=0x4a17ebe0, ESI=0x, EDI=0x48710400 EIP=0x48b8e1fe, EFLAGS=0x00010246 Top of Stack: (sp=0x4a17ebd8) 0x4a17ebd8: 48710400 4a17ec1c 4a17ebf8 48b8111f 0x4a17ebe8: 4a17ebf4 0001 0x4a17ebf8: 4a17ec28 00934f8f 48710510 4a17ec1c 0x4a17ec08: 0001 49d3f6b0 0001 0x4a17ec18: 0001 42b3f598 48710400 48710400 0x4a17ec28: 4a17ed28 007d6e48 49d3f6b0 0x4a17ec38: 4a17ec5c 48710400 4a17ec5c 6d99918b 0x4a17ec48: 48710400 6d9991b2 42de44b0 48710400 Instructions: (pc=0x48b8e1fe) 0x48b8e1ee: 5d c2 0c 00 83 f8 01 0f 85 80 00 00 00 8b 75 10 0x48b8e1fe: 8b 46 34 85 c0 74 3a 8b 56 14 c7 42 14 10 00 00 Stack: [0x4a14,0x4a18], sp=0x4a17ebd8, free space=250k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [tcnative-1.dll+0xe1fe] C [tcnative-1.dll+0x111f] J org.apache.tomcat.jni.Address.get(IJ)J J org.apache.coyote.http11.Http11AprProcessor.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V j org.apache.coyote.Request.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V+56 J org.apache.catalina.connector.Request.getRemoteAddr()Ljava/lang/String; J org.apache.catalina.connector.RequestFacade.getRemoteAddr()Ljava/lang/String; J com.ecolog.generic.Session.getSession(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;Ljava/lang/String;)Lcom/ecolog/generic/Session; j org.apache.jsp.warehouse_v3.cartitems_jsp._jspService(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V+71 j org.apache.jasper.runtime.HttpJspBase.service(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V+3 J javax.servlet.http.HttpServlet.service(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V j org.apache.jasper.servlet.JspServletWrapper.service(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;Z)V+395 j org.apache.jasper.servlet.JspServlet.serviceJspFile(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;Ljava/lang/String;Ljava/lang/Throwable;Z)V+134 j org.apache.jasper.servlet.JspServlet.service(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V+436 J javax.servlet.http.HttpServlet.service(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V J org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V J org.apache.catalina.core.ApplicationFilterChain.doFilter(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V J org.apache.catalina.core.StandardWrapperValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V J org.apache.catalina.core.StandardContextValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V J org.apache.catalina.core.StandardHostValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V J org.apache.catalina.valves.ErrorReportValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V J org.apache.catalina.valves.AccessLogValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V J org.apache.catalina.core.StandardEngineValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V J org.apache.catalina.connector.CoyoteAdapter.service(Lorg/apache/coyote/Request;Lorg/apache/coyote/Response;)V J org.apache.coyote.http11.Http11AprProcessor.process(J)Lorg/apach
DO NOT REPLY [Bug 49038] New: Crash in tcnative
https://issues.apache.org/bugzilla/show_bug.cgi?id=49038 Summary: Crash in tcnative Product: Tomcat 6 Version: 6.0.14 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: nageshwarnag...@gmail.com # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x48b8e1fe, pid=1412, tid=716 # # JRE version: 6.0_16-b01 # Java VM: Java HotSpot(TM) Client VM (14.2-b01 mixed mode windows-x86 ) # Problematic frame: # C [tcnative-1.dll+0xe1fe] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x48710400): JavaThread "http-7000-1" daemon [_thread_in_native, id=716, stack(0x4a14,0x4a18)] siginfo: ExceptionCode=0xc005, reading address 0x0034 Registers: EAX=0x0001, EBX=0x, ECX=0x, EDX=0x0001 ESP=0x4a17ebd8, EBP=0x4a17ebe0, ESI=0x, EDI=0x48710400 EIP=0x48b8e1fe, EFLAGS=0x00010246 Top of Stack: (sp=0x4a17ebd8) 0x4a17ebd8: 48710400 4a17ec1c 4a17ebf8 48b8111f 0x4a17ebe8: 4a17ebf4 0001 0x4a17ebf8: 4a17ec28 00934f8f 48710510 4a17ec1c 0x4a17ec08: 0001 49d3f6b0 0001 0x4a17ec18: 0001 42b3f598 48710400 48710400 0x4a17ec28: 4a17ed28 007d6e48 49d3f6b0 0x4a17ec38: 4a17ec5c 48710400 4a17ec5c 6d99918b 0x4a17ec48: 48710400 6d9991b2 42de44b0 48710400 Instructions: (pc=0x48b8e1fe) 0x48b8e1ee: 5d c2 0c 00 83 f8 01 0f 85 80 00 00 00 8b 75 10 0x48b8e1fe: 8b 46 34 85 c0 74 3a 8b 56 14 c7 42 14 10 00 00 Stack: [0x4a14,0x4a18], sp=0x4a17ebd8, free space=250k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [tcnative-1.dll+0xe1fe] C [tcnative-1.dll+0x111f] J org.apache.tomcat.jni.Address.get(IJ)J J org.apache.coyote.http11.Http11AprProcessor.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V j org.apache.coyote.Request.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V+56 J org.apache.catalina.connector.Request.getRemoteAddr()Ljava/lang/String; J org.apache.catalina.connector.RequestFacade.getRemoteAddr()Ljava/lang/String; J com.ecolog.generic.Session.getSession(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;Ljava/lang/String;)Lcom/ecolog/generic/Session; j org.apache.jsp.warehouse_v3.cartitems_jsp._jspService(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V+71 j org.apache.jasper.runtime.HttpJspBase.service(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V+3 J javax.servlet.http.HttpServlet.service(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V j org.apache.jasper.servlet.JspServletWrapper.service(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;Z)V+395 j org.apache.jasper.servlet.JspServlet.serviceJspFile(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;Ljava/lang/String;Ljava/lang/Throwable;Z)V+134 j org.apache.jasper.servlet.JspServlet.service(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V+436 J javax.servlet.http.HttpServlet.service(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V J org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V J org.apache.catalina.core.ApplicationFilterChain.doFilter(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V J org.apache.catalina.core.StandardWrapperValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V J org.apache.catalina.core.StandardContextValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V J org.apache.catalina.core.StandardHostValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V J org.apache.catalina.valves.ErrorReportValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V J org.apache.catalina.valves.AccessLogValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V J org.apache.catalina.core.StandardEngineValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V J org.apache.catalina.connector.CoyoteAdapter.service(Lorg/apache/coyote/Request;Lorg/apache/coyote/Response;)V J org.apache.coyote.http11.Http11AprProcessor.process(J)Lorg/apache/tomcat/util/net/AprEndpoint$Handler$SocketState; J org.apache.coyote.http11.Http11AprProtocol$Http11Connec
DO NOT REPLY [Bug 47774] Illegal context class loader is used when HttpSessionListener is executed.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47774 Keiichi Fujino changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #3 from Keiichi Fujino 2010-04-02 06:14:10 UTC --- I reopned this bug. This is not fixed against 5.5.x. therefore, proposed for 5.5.x. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r930173 - /tomcat/tc5.5.x/trunk/STATUS.txt
Author: kfujino Date: Fri Apr 2 06:23:46 2010 New Revision: 930173 URL: http://svn.apache.org/viewvc?rev=930173&view=rev Log: Proposal of fix of bz47774. Modified: tomcat/tc5.5.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=930173&r1=930172&r2=930173&view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Fri Apr 2 06:23:46 2010 @@ -145,3 +145,10 @@ PATCHES PROPOSED TO BACKPORT: (there is no link above): http://svn.apache.org/viewvc?rev=928732&view=rev -1: + + * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47774 + Ensure web application class loader is used when calling session listeners + http://svn.apache.org/viewvc?view=revision&revision=899138 + http://svn.apache.org/viewvc?view=revision&revision=900131 + +1: kfujino + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
