Re: Issue in AprEndpoint detected by TestCoyoteAdapter
On 23.09.2013 07:27, Mladen Turk wrote:
On 09/22/2013 03:39 PM, Rainer Jung wrote:
On 22.09.2013 13:17, Rainer Jung wrote:
I debugged around my occasional failures for TestCoyoteAdapter when
using APR.
Error is:
SEVERE [http-apr-127.0.0.1-auto-13-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Poller failed with
error [81] : [File descriptor in bad state]
...
Not sure whether the problem is more in the concurrent poll plus remove,
or the following code in poll.c:
TCN_IMPLEMENT_CALL(jint, Poll, remove)(TCN_STDARGS, jlong pollset,
jlong socket)
{
apr_pollfd_t fd;
apr_status_t rv;
tcn_pollset_t *p = J2P(pollset, tcn_pollset_t *);
tcn_socket_t *s = J2P(socket, tcn_socket_t *);
UNREFERENCED_STDARGS;
TCN_ASSERT(socket != 0);
if (s-pe == NULL) {
/* Already removed */
return APR_SUCCESS;
}
Here we return APR_SUCCESS and the code calling Poll.remove in
AprEndpoint always does:
rv = Poll.remove(pollers[i], socket);
if (rv != Status.APR_NOTFOUND) {
pollerSpace[i]++;
connectionCount--;
break;
}
So the pollerSpace and connectionCount numbers are (in/de)cremented.
The following patch seems to fix it for me, at least 150 test runs for
TestCoyoteAdapter were successful:
Index: ../native/branches/1.1.x/native/src/poll.c
===
--- ../native/branches/1.1.x/native/src/poll.c (revision 1525348)
+++ ../native/branches/1.1.x/native/src/poll.c (working copy)
@@ -259,7 +259,7 @@
if (s-pe == NULL) {
/* Already removed */
-return APR_SUCCESS;
+return APR_NOTFOUND;
}
fd.desc_type = APR_POLL_SOCKET;
fd.desc.s = s-sock;
The patch seems fine. I mean any return value should do in theory.
The main question is why is particular socket removed twice
from the Poller. This is called directly from java code
so wrapper seems to call it twice (or more).
I suspect that the socket is first closed and then Poller loop removes it.
Or it can be removed by poll with doRemove == true or during pollset
maintain.
In any case after removed either by poll or maintain returned set of
removed
sockets must be invalidated from pollset so it doesn't use it again in
explicit remove.
I agree that there's probably another problem further up the stack.
Since the apr endpoint explicitely uses the return value of remove to
decide whether something was removed, APT_NOTFOUND seems better. But as
you said: why is it calling remove for a socket not in the poller? When
the endpoint called remove for 2856392, the poller has size one and
consisted only of socket 2218784. Strange.
Here's the more complete log snippet:
SOCKET-1 exists, but will be destroyed before the problem happen,
SOCKET-2 s going to be accepted and later produces the problem,
SOCKET-3 comes into the picture only shortly before the problem happens.
12:19:12.844 FINE [13-exec-4] AprEndpoint$Poller.add socket [SOCKET-1],
timeout [3,000], flags [1]
Here 2 is acceppted
12:19:12.850 FINE [13-Acceptor-0] AprEndpoint.processSocketWithOptions
socket [SOCKET-2]
and added to the poller
12:19:12.853 FINE [13-exec-5] AprEndpoint$Poller.add socket [SOCKET-2],
timeout [3,000], flags [1]
12:19:12.858 FINE [13-Poller] AprEndpoint$Poller.run socket [SOCKET-1]
12:19:12.860 WARNING [13-Poller] AprEndpoint$Poller.addToPoller Adding
to poller number 0 of size 0 socket SOCKET-1
12:19:12.861 WARNING [13-Poller] AprEndpoint$Poller.addToPoller Adding
to poller number 0 returned with 0
Here adding to the poller actually happens
12:19:12.862 FINE [13-Poller] AprEndpoint$Poller.run socket [SOCKET-2]
12:19:12.863 WARNING [13-Poller] AprEndpoint$Poller.addToPoller Adding
to poller number 0 of size 1 socket SOCKET-2
12:19:12.864 WARNING [13-Poller] AprEndpoint$Poller.addToPoller Adding
to poller number 0 returned with 0
Now the poller contains Sockets 1 and 2 and gets polled
12:19:12.865 WARNING [13-Poller] AprEndpoint$Poller.run Polling poller
number 0 of size 2 with timeout 2000
12:19:12.866 WARNING [13-Poller] AprEndpoint$Poller.run Polling poller
number 0 returned with 2
It returns both sockets: port_getn(6, 0x005D0CF8, 8192, 1, 0xB417F6F8)
= 2 [0]
12:19:12.867 FINE [13-Poller] AprEndpoint$Poller.run Processing socket
[SOCKET-1] for event(s) [1]
12:19:12.869 FINE [13-Poller] AprEndpoint$Poller.run Processing socket
[SOCKET-2] for event(s) [1]
Socket 1 gets destroyed.
12:19:12.871 FINE [13-exec-6] AprEndpoint.destroySocket socket
[SOCKET-1], doIt [true]
Socket 2 is handled by an exec thread which adds it back to the poller:
port_associate(6, 4, 0x000D, 0x0001, 0x0089AB88) = 0
12:19:12.878 FINE [13-exec-7] AprEndpoint$Poller.add socket [SOCKET-2],
timeout [3,000], flags
svn commit: r1525525 - in /tomcat/native/branches/1.1.x: native/src/poll.c xdocs/miscellaneous/changelog.xml
Author: rjung
Date: Mon Sep 23 08:08:56 2013
New Revision: 1525525
URL: http://svn.apache.org/r1525525
Log:
Change return code when removing a socket from a poller, that was
actually not in the poller from APR_SUCCESS to APR_NOTFOUND.
This lead to corrupt poller handling in the Tomcat APR connector,
at least sporadically on Solaris Sparc.
Modified:
tomcat/native/branches/1.1.x/native/src/poll.c
tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml
Modified: tomcat/native/branches/1.1.x/native/src/poll.c
URL:
http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/native/src/poll.c?rev=1525525r1=1525524r2=1525525view=diff
==
--- tomcat/native/branches/1.1.x/native/src/poll.c (original)
+++ tomcat/native/branches/1.1.x/native/src/poll.c Mon Sep 23 08:08:56 2013
@@ -259,7 +259,7 @@ TCN_IMPLEMENT_CALL(jint, Poll, remove)(T
if (s-pe == NULL) {
/* Already removed */
-return APR_SUCCESS;
+return APR_NOTFOUND;
}
fd.desc_type = APR_POLL_SOCKET;
fd.desc.s = s-sock;
Modified: tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml?rev=1525525r1=1525524r2=1525525view=diff
==
--- tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml Mon Sep 23
08:08:56 2013
@@ -36,6 +36,14 @@
new documentation project for Tomcat Native was started.
/p
/section
+section name=Changes between 1.1.28 and 1.1.29
+ changelog
+fix
+ Change return code when removing a socket from a poller, that was
+ actually not in the poller from APR_SUCCESS to APR_NOTFOUND. (rjung)
+/fix
+ /changelog
+/section
section name=Changes between 1.1.27 and 1.1.28
changelog
update
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Issue in AprEndpoint detected by TestCoyoteAdapter
On 09/23/2013 09:54 AM, Rainer Jung wrote: On 23.09.2013 07:27, Mladen Turk wrote: The patch seems fine. I mean any return value should do in theory. The main question is why is particular socket removed twice from the Poller. I agree that there's probably another problem further up the stack. It would be good to check for thread sync issues. Maintain and socket close must be serialized. If the socket is closed while poller is in maintain with the same same socket it might lead to this issue. Also not sure if we have a code with either poll() or maintain() call without doRemove argument set to true. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1525547 - /tomcat/trunk/res/META-INF/tomcat-websocket.jar/services/javax.websocket.server.ServerContainerProvider
Author: markt Date: Mon Sep 23 11:00:19 2013 New Revision: 1525547 URL: http://svn.apache.org/r1525547 Log: ServerContainerProvider was removed from JSR-356 Removed: tomcat/trunk/res/META-INF/tomcat-websocket.jar/services/javax.websocket.server.ServerContainerProvider - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1525548 - /tomcat/tc7.0.x/trunk/res/META-INF/tomcat7-websocket.jar/services/javax.websocket.server.ServerContainerProvider
Author: markt Date: Mon Sep 23 11:02:18 2013 New Revision: 1525548 URL: http://svn.apache.org/r1525548 Log: ServerContainerProvider was removed from JSR-356 Removed: tomcat/tc7.0.x/trunk/res/META-INF/tomcat7-websocket.jar/services/javax.websocket.server.ServerContainerProvider - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SCI discovery ordering
On 22/09/2013 10:55, Jeremy Boynes wrote: On Sep 22, 2013, at 1:44 AM, Mark Thomas ma...@apache.org wrote: On 22/09/2013 00:27, Jeremy Boynes wrote: As a concrete example of how this impacts the behaviour, consider the case where the application includes its own JSP engine. With the RI's delegation model, the application's engine's SCI would execute first allowing it to register a Servlet and mapping to handle the *.jsp pattern. When the container's engine's SCI was executed, that mapping would already be bound and could not be pre-empted (engines already need to allow for that in case the application configured that mapping in its web.xml). If the container is always given priority, then the container's engine would be used rather than the one the application intended. No. It would still be loaded from the application (for that webapp). For two versions of the *same* implementation, yes. Agreed. This is the case the EG was trying to cover. Unfortunately that is just a small part of the total grey area that could do with some clarification. But if they used *different* implementations of the *same functionality,* the container's would always get precedence. For example, if an application included Tyrus's WebSocket implementation it would always be invoked after Tomcat's. Or for JAX-RS, if the container was configured with CXF and the application included Jersey, Jersey would not be able to register its Servlets for the REST endpoints as CXF would have already mapped them. Some time ago, Tomcat allowed users to include container JARs in absolute orderings to handle this sort of situation. However, the EG was very clear that that behaviour was not permitted and that absolute ordering could only include applications JARs. I'm wondering if reverting to something like this might be the way to solve this. We shall see... The issue here is that programmatic registrations cannot modify the existing configuration. Once a framework has registered a servlet, filter, listener or mapping it cannot be replaced by another. Frameworks that applications bundle in WEB-INF/lib need to have a chance to perform their initialization before an equivalent but different implementation provided by the container. This is starting to get really messy. There are enough different edge cases that I'm not such I am keeping track of them all. I'm also not sure that SERVLET_SPEC-79 has captured them all either. Can I suggest the following approach: - start a new wiki page listing all the edge cases / problems / issues we can think of - discuss some solutions to those issues on list - more complex proposals can be documented on the wiki if necessary - document the proposal(s) on the wiki - update SERVLET_SPEC-79 with the full set of issues and solution(s) At that point we can figure out what minimal changes we can make to Tomcat 8 to align it as far as possible to the proposed solution. What I want to avoid is a large / invasive change to Tomcat to align it to the proposed solution only to have to undo / redo it if the EG opts for a different (or worse still no) solution. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.43
Mark, On 9/20/13 7:05 AM, Mark Thomas wrote: On 20/09/2013 11:57, Jeanfrancois Arcand wrote: On 2013-09-20 6:26 AM, Mark Thomas wrote: On 20/09/2013 11:24, Jeanfrancois Arcand wrote: Hi, [X] Broken - do not release I do test/use Tomcat with WebSocket since 7.0.27. 8.0.0-RC1 worked well with jsr356, but 7.0.43 is broken. You can try it by deploying http://search.maven.org/remotecontent?filepath=org/atmosphere/samples/atmosphere-chat/2.0.0/atmosphere-chat-2.0.0.war Just a quick question, were you running on Java 7? Ah! No I wasn't. I think a log message or warning should be written because the jsr356's ServerApplicationConfig is scanned and created with jdk 6, hence initialized. There is a log message when you start with Java 6. It is at INFO level and is written the first time the WebSocket ServletContainerInitializer is called. Thoughts on making that message more prominent / increasing it to WARN ? +1 on increasing it to WARN. -chris signature.asc Description: OpenPGP digital signature
Re: [VOTE] Release Apache Tomcat 8.0.0-RC3
On 20/09/2013 12:35, Mark Thomas wrote: On 20/09/2013 11:36, Mark Thomas wrote: The proposed Apache Tomcat 8.0.0 release candidate 3 is now available for voting. Given this is a release candidate I am working on the basis that it is equivalent to an alpha. The main changes since RC1 are: - Updated spec implementations with results of various grey area discussions from the EG mailing lists - Now uses UTF-8 by default - Switch to async logging and one-line log format by default - New doc style - Refactored TLD parsing (work in progress) - Fixed all the issues reported against RC1 RC2 - Add Servlet 3.1 non-blocking support to the AJP connectors - Fix an issue with the new WebResources and packed WAR files It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC3/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-080/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC3/ The proposed 8.0.0-RC3 release is: [ ] Broken - do not release [X] Alpha - go ahead and release as 8.0.0-RC3 alpha It passes the unit tests on Windows, Linux and OSX. ping. Any more votes? I know Rainer has found some issues with APR on Solaris but since this is at most an alpha release I'm not minded to cancel the release at this point. Of course, if no more votes are forthcoming soon, then the release will fail. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC3
Hi Mark What kind of tests, specific to TC 8.0 are awaited to 'qualify' ? 2013/9/23 Mark Thomas ma...@apache.org On 20/09/2013 12:35, Mark Thomas wrote: On 20/09/2013 11:36, Mark Thomas wrote: The proposed Apache Tomcat 8.0.0 release candidate 3 is now available for voting. Given this is a release candidate I am working on the basis that it is equivalent to an alpha. The main changes since RC1 are: - Updated spec implementations with results of various grey area discussions from the EG mailing lists - Now uses UTF-8 by default - Switch to async logging and one-line log format by default - New doc style - Refactored TLD parsing (work in progress) - Fixed all the issues reported against RC1 RC2 - Add Servlet 3.1 non-blocking support to the AJP connectors - Fix an issue with the new WebResources and packed WAR files It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC3/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-080/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC3/ The proposed 8.0.0-RC3 release is: [ ] Broken - do not release [X] Alpha - go ahead and release as 8.0.0-RC3 alpha It passes the unit tests on Windows, Linux and OSX. ping. Any more votes? I know Rainer has found some issues with APR on Solaris but since this is at most an alpha release I'm not minded to cancel the release at this point. Of course, if no more votes are forthcoming soon, then the release will fail. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC3
On 23/09/2013 06:20, Henri Gomez wrote: Hi Mark What kind of tests, specific to TC 8.0 are awaited to 'qualify' ? Not sure what you mean. The only tests we have are the unit tests. We do not have access to the Java EE 7 TCKs. In terms of this release, I am personally happy if the unit tests pass on all three platforms I have available. I'm keen to get wider feedback from our users and that needs a formal release. In terms of the alpha - beta - stable transition, I plan on including beta in the options once we have an RC that doesn't have any show stopper issues. i.e. I'm expecting 8.0.0 to be beta. For beta - stable, that will depend on the rate and severity of bug reports we get. My guess it stable will be early next year but who knows. Tomcat is pretty stable already and then unit tests seem to be doing a good job catching issues with the new functionality so maybe it could be sooner. Mark 2013/9/23 Mark Thomas ma...@apache.org On 20/09/2013 12:35, Mark Thomas wrote: On 20/09/2013 11:36, Mark Thomas wrote: The proposed Apache Tomcat 8.0.0 release candidate 3 is now available for voting. Given this is a release candidate I am working on the basis that it is equivalent to an alpha. The main changes since RC1 are: - Updated spec implementations with results of various grey area discussions from the EG mailing lists - Now uses UTF-8 by default - Switch to async logging and one-line log format by default - New doc style - Refactored TLD parsing (work in progress) - Fixed all the issues reported against RC1 RC2 - Add Servlet 3.1 non-blocking support to the AJP connectors - Fix an issue with the new WebResources and packed WAR files It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC3/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-080/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC3/ The proposed 8.0.0-RC3 release is: [ ] Broken - do not release [X] Alpha - go ahead and release as 8.0.0-RC3 alpha It passes the unit tests on Windows, Linux and OSX. ping. Any more votes? I know Rainer has found some issues with APR on Solaris but since this is at most an alpha release I'm not minded to cancel the release at this point. Of course, if no more votes are forthcoming soon, then the release will fail. Mark - 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
[Bug 55576] Order of ServletRequest parameters is not preserved
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |NEEDINFO OS||All --- Comment #1 from Mark Thomas ma...@apache.org --- The Servlet specification does defer to W3C for all HTML matters. The text quoted above regarding ordering only applies when application/x-www-form-urlencoded is being used. Strictly, it applies only to the order that the client provides the data. It could be argued that if the client is required to provide the parameters in order in this case then the getParamererXXX() methods should respect that order. Further, if the order needs to be maintained for this one case, it is easier to maintain it for all. However, there is nothing that I can see in either the Servlet or HTML specifications that strcitly requires the Servlet API to present the parameters in the same order as they were received. There is no major performance difference (I am aware of) between HashMap and LinkedHahsMap so I am not against making this change but neither (at this point) do I really see the need for it. One concern I do have is that given that there is not a requirement for this, other containers may not implement it and that could cause portability issues. I am curious as to the use case that supports it. Can you elaborate on why it might be important for the parameters to be returned in the same order as they appear on the form. -- 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: [VOTE] Release Apache Tomcat 8.0.0-RC3
2013/9/20 Mark Thomas ma...@apache.org The proposed Apache Tomcat 8.0.0 release candidate 3 is now available for voting. Given this is a release candidate I am working on the basis that it is equivalent to an alpha. The main changes since RC1 are: - Updated spec implementations with results of various grey area discussions from the EG mailing lists - Now uses UTF-8 by default - Switch to async logging and one-line log format by default - New doc style - Refactored TLD parsing (work in progress) - Fixed all the issues reported against RC1 RC2 - Add Servlet 3.1 non-blocking support to the AJP connectors - Fix an issue with the new WebResources and packed WAR files It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC3/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-080/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC3/ The proposed 8.0.0-RC3 release is: [ ] Broken - do not release [X] Alpha - go ahead and release as 8.0.0-RC3 alpha Checked with some applications that are using the new specifications features. Regards Violeta
Re: [VOTE] Release Apache Tomcat 8.0.0-RC3
On Fri, Sep 20, 2013 at 12:36 PM, Mark Thomas ma...@apache.org wrote: The proposed Apache Tomcat 8.0.0 release candidate 3 is now available for voting. Given this is a release candidate I am working on the basis that it is equivalent to an alpha. The main changes since RC1 are: - Updated spec implementations with results of various grey area discussions from the EG mailing lists - Now uses UTF-8 by default - Switch to async logging and one-line log format by default - New doc style - Refactored TLD parsing (work in progress) - Fixed all the issues reported against RC1 RC2 - Add Servlet 3.1 non-blocking support to the AJP connectors - Fix an issue with the new WebResources and packed WAR files It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC3/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-080/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC3/ The proposed 8.0.0-RC3 release is: [ ] Broken - do not release [X] Alpha - go ahead and release as 8.0.0-RC3 alpha Apache Wicket Native WebSockets based on JSR356 works fine. Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1525593 - /tomcat/trunk/java/org/apache/jasper/compiler/TagFileProcessor.java
Author: markt
Date: Mon Sep 23 13:54:31 2013
New Revision: 1525593
URL: http://svn.apache.org/r1525593
Log:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55582
Correct concurrency issue that can result in two instances of JspServletWrapper
being created for one tag.
Patch provided by Sheldon Shao.
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/TagFileProcessor.java
Modified: tomcat/trunk/java/org/apache/jasper/compiler/TagFileProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/TagFileProcessor.java?rev=1525593r1=1525592r2=1525593view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/TagFileProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/TagFileProcessor.java Mon Sep
23 13:54:31 2013
@@ -529,9 +529,9 @@ class TagFileProcessor {
JspCompilationContext ctxt = compiler.getCompilationContext();
JspRuntimeContext rctxt = ctxt.getRuntimeContext();
-JspServletWrapper wrapper = rctxt.getWrapper(wrapperUri);
synchronized (rctxt) {
+JspServletWrapper wrapper = rctxt.getWrapper(wrapperUri);
if (wrapper == null) {
wrapper = new JspServletWrapper(ctxt.getServletContext(), ctxt
.getOptions(), tagFilePath, tagInfo, ctxt
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55582] Concurrent issue of TagFileProcessor
https://issues.apache.org/bugzilla/show_bug.cgi?id=55582 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Mark Thomas ma...@apache.org --- Thanks for the report. This has been fixed in 8.0.x (for 8.0.0-RC4 onwards) and 7.0.x (for 7.0.44 onwards). -- 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: r1525595 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/jasper/compiler/TagFileProcessor.java webapps/docs/changelog.xml
Author: markt
Date: Mon Sep 23 13:58:50 2013
New Revision: 1525595
URL: http://svn.apache.org/r1525595
Log:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55582
Correct concurrency issue that can result in two instances of JspServletWrapper
being created for one tag.
Patch provided by Sheldon Shao.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/jasper/compiler/TagFileProcessor.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1525593
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/jasper/compiler/TagFileProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/jasper/compiler/TagFileProcessor.java?rev=1525595r1=1525594r2=1525595view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/jasper/compiler/TagFileProcessor.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/jasper/compiler/TagFileProcessor.java
Mon Sep 23 13:58:50 2013
@@ -533,9 +533,9 @@ class TagFileProcessor {
JspCompilationContext ctxt = compiler.getCompilationContext();
JspRuntimeContext rctxt = ctxt.getRuntimeContext();
-JspServletWrapper wrapper = rctxt.getWrapper(wrapperUri);
synchronized (rctxt) {
+JspServletWrapper wrapper = rctxt.getWrapper(wrapperUri);
if (wrapper == null) {
wrapper = new JspServletWrapper(ctxt.getServletContext(), ctxt
.getOptions(), tagFilePath, tagInfo, ctxt
Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1525595r1=1525594r2=1525595view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Mon Sep 23 13:58:50 2013
@@ -55,6 +55,15 @@
They eventually become mixed with the numbered issues. (I.e., numbered
issues to not pop up wrt. others).
--
+section name=Tomcat 7.0.44 (violetagg)
+ subsection name=Jasper
+changelog
+ bug55582/bug: Correct concurrency issue that can result in two
+ instances of JspServletWrapper being created for one tag Patch provided
by
+ Sheldon Shao. (markt)
+/changelog
+ /subsection
+/section
section name=Tomcat 7.0.43 (violetagg) rtext=not released
subsection name=Catalina
changelog
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55576] Order of ServletRequest parameters is not preserved
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576 --- Comment #2 from Christopher Schultz ch...@christopherschultz.net --- (In reply to Mark Thomas from comment #1) I am curious as to the use case that supports it. Can you elaborate on why it might be important for the parameters to be returned in the same order as they appear on the form. Somewhat related: http://host/resource?op=addop=updateop=delete If the application expects left-to-right ordering when fetching op (which IMO is reasonable) then the ordering of the values is quite important. It seems like extending the above use case to parameters with different names would be reasonable, though I can't really envision a use case where the order of unknown request parameter names would be important. -- 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: [VOTE] Release Apache Tomcat 8.0.0-RC3
Mark, On 9/20/13 6:36 AM, Mark Thomas wrote: The proposed Apache Tomcat 8.0.0 release candidate 3 is now available for voting. Given this is a release candidate I am working on the basis that it is equivalent to an alpha. The main changes since RC1 are: - Updated spec implementations with results of various grey area discussions from the EG mailing lists - Now uses UTF-8 by default - Switch to async logging and one-line log format by default - New doc style - Refactored TLD parsing (work in progress) - Fixed all the issues reported against RC1 RC2 - Add Servlet 3.1 non-blocking support to the AJP connectors - Fix an issue with the new WebResources and packed WAR files It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC3/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-080/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC3/ The proposed 8.0.0-RC3 release is: [ ] Broken - do not release [X] Alpha - go ahead and release as 8.0.0-RC3 alpha Debian Linux 2.6, x86_84 Oracle Java 1.7.0_40, 64-bit Server VM Binary ZIP and tarball are the same Source ZIP and tarball are the same MD5 sums are okay GPG sigs are okay Checkstyle is happy tcnative builds fine, with some notes Unit tests pass (except Tribes, known to fail in my environment) Quick smoke test on my own web application (no new features e.g. Websocket are in use) shows no problems (and the hundreds of WARNING logs are now gone). Looks good to me. -chris signature.asc Description: OpenPGP digital signature
Refactoring class loader access to resources
I've mentioned on a couple of different threads that refactoring how the class loader accesses resources was on my TODO list. I haven't done any implementation yet but I have some ideas that I wanted to get some feedback on before I start work. The things I have in mind at this point are: - Extracting anything into the work directory feels like a hack - The class loader should use the same API as every other component - The class loader needs URLs that actually work - The anti-locking options are responsible for a number of the hacks in the class loader The solution I have in mind is along the following lines: - Add a new getClassLoaderResource() to the WebResources interfaces. This will implement the standard WEB-INF/classes then JARs in WEB-INF/lib search order. It should be able to do this without any extraction into the work directory. - Class loader resources will not be cached. - Remove all of the current anti-locking options. - Wrap all InputStreams returned by the class loader and use this wrapper to track whether or not the InputStream has been closed. - Update the memory leak protection code to close any class loader InputStreams that have not been closed when the web application is stopped. - Add a debug option that captures the stack trace of the code that creates the class loader InputStream that can be reported when closing leaked streams. - Add the same InputStream tracking to InputStreams provided by the standard resource implementation. Obviously details TBD as the implementation evolves. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Refactoring class loader access to resources
On 23.09.2013 17:27, Mark Thomas wrote: I've mentioned on a couple of different threads that refactoring how the class loader accesses resources was on my TODO list. I haven't done any implementation yet but I have some ideas that I wanted to get some feedback on before I start work. The things I have in mind at this point are: - Extracting anything into the work directory feels like a hack - The class loader should use the same API as every other component - The class loader needs URLs that actually work - The anti-locking options are responsible for a number of the hacks in the class loader The solution I have in mind is along the following lines: - Add a new getClassLoaderResource() to the WebResources interfaces. This will implement the standard WEB-INF/classes then JARs in WEB-INF/lib search order. It should be able to do this without any extraction into the work directory. A useful feature in TC 6/7 was to add search paths outside of the war to look for config files in order to provide config options special to deployment environments without working with individual war files (via VirtualWebappLoader). I know it is possible with the current resource implementation in TC 8, but will it also be possible after this change, i.e. if the webapp retrieves a config file as a resource via the webapp class loader, can we still configure additional directories to be searched for the resource? - Class loader resources will not be cached. - Remove all of the current anti-locking options. - Wrap all InputStreams returned by the class loader and use this wrapper to track whether or not the InputStream has been closed. - Update the memory leak protection code to close any class loader InputStreams that have not been closed when the web application is stopped. - Add a debug option that captures the stack trace of the code that creates the class loader InputStream that can be reported when closing leaked streams. - Add the same InputStream tracking to InputStreams provided by the standard resource implementation. Obviously details TBD as the implementation evolves. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.43
On 23.09.2013 14:44, Christopher Schultz wrote: Mark, On 9/20/13 7:05 AM, Mark Thomas wrote: On 20/09/2013 11:57, Jeanfrancois Arcand wrote: On 2013-09-20 6:26 AM, Mark Thomas wrote: On 20/09/2013 11:24, Jeanfrancois Arcand wrote: Hi, [X] Broken - do not release I do test/use Tomcat with WebSocket since 7.0.27. 8.0.0-RC1 worked well with jsr356, but 7.0.43 is broken. You can try it by deploying http://search.maven.org/remotecontent?filepath=org/atmosphere/samples/atmosphere-chat/2.0.0/atmosphere-chat-2.0.0.war Just a quick question, were you running on Java 7? Ah! No I wasn't. I think a log message or warning should be written because the jsr356's ServerApplicationConfig is scanned and created with jdk 6, hence initialized. There is a log message when you start with Java 6. It is at INFO level and is written the first time the WebSocket ServletContainerInitializer is called. Thoughts on making that message more prominent / increasing it to WARN ? +1 on increasing it to WARN. Another +1 for WARN. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55576] Order of ServletRequest parameters is not preserved
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576 --- Comment #3 from corythearchit...@outlook.com --- Thomas, thank you for your rapid evaluation and response on this matter. The general use case is the servicing of a request in which the order of parameter evaluation is significant. http://host/resource?country=CApostalcode=N7T5R4 Let's assume this is in context of a general infrastructure that evaluates each parameter in the order received (field validation being just one example of potential triggers). postalcode validation is dependent on the value of country. The specific scenario I am currently dealing with is porting a web service implementation from ASP/IIS to Java/Tomcat. The Microsoft IRequestDictionary.QueryString implementation respects order of insertion, while Tomcat scrambles the order as a result of the backing HashMap collection. I respect your position that there is no explicit specification of the server-side evaluation of HTML parameters. However, I also see no significance to the client-side specification of parameter order beyond the implication that the ordering is also significant to the processing server that consumes it. What other purpose could such an ordering possibly serve? Assuming equivalent performance, what portability issues could arise from a MORE determinate collection implementation? If anyone is currently relying on the iteration order of the existing HashMap implementation, a) they are in for a surprise anyhow, and b) the ServletRequest interface, unfortunately, provides no guarantees, relying on the generic Map and Enumeration interfaces, both of which defer to the implementation for behaviour in this regard. This decision could only be interpreted as an improvement in compliance (with the HTML specification). -- 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: [VOTE] Release Apache Tomcat 8.0.0-RC3
On 20.09.2013 12:36, Mark Thomas wrote:
The proposed 8.0.0-RC3 release is:
[ ] Broken - do not release
[X] Alpha - go ahead and release as 8.0.0-RC3 alpha
+1 as alpha.
Overview:
- MD5 OK
- signatures OK
- key in KEYS file
- gz and zip for src and bin consistent
- src consistent with svn tag
- builds fine but
- Few warning about unsafe or unchecked operations.
Only 0 or 1 new one, some of the RC1 ones are fixed.
See full list at end of mail.
- build result looks consistent with binaries
- no checkstyle complaints
- no Javadoc warnings
- some small MBean data changes
! One unit test failure in TestWebappClassLoaderExecutorMemoryLeak
- analysis ongoing, not a regression
Repeated execution also sometimes show a hang in the unit test.
- Warnings, errors and exception counts during unit tests a bit
higher than for RC 1
- JMX MBean-Comparison with RC 1:
- 2 new MBeans for Example servlets numberwriter and bytecounter
- MBean j2eeType=Filter,name=Set Character Encoding,
WebModule=//localhost/examples, ...
attribute filterInitParameterMap changed from
{encoding=EUC_JP, ignore=true} to
{encoding=UTF-8, ignore=false}
- MBean Catalina:j2eeType=WebModule,*
- attributes tldNamespaceAware and tldValidation are gone
- attribute tldScanTime is always 0
- MBean Catalina:type=Connector,*
new attribute URIEncoding value UTF-8
- MBean Catalina:type=ProtocolHandler,port=8080
new attribute maxExtensionSize value 8192
(attribute does not exist for 8009 AJP ProtocolHandler
but the attribute structure for those two MBeans is quite
different from each other)
- platform MBean java.lang:type=Runtime in system property
tomcat.util.scan.StandardJarScanFilter.jarsToSkip
new entry websocket-api.jar
- platform MBean java.lang:type=OperatingSystem show 87 open file
descriptors instead of 88
- platform MBean java.lang:type=Threading shows 19 threads instead of
18 threads
Build and tests were done using Java 1.7.0_40. OS was Solaris 10 Sparc,
tcnative was 1.1.28 based on APR 1.4.8 and OpenSSL 1.0.1e (plus a few
patches).
Unit test warnings: 108
- 42 more than RC1
- most additional ones in tribes, especially going up from 27 to 59:
org.apache.catalina.tribes.group.interceptors.NonBlockingCoordinator.sendElectionMsgToNextInline
Unable to send election message
to:org.apache.catalina.tribes.membership.MemberImpl[tcp://
- 8 new ones:
org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor The
executor associated with thread pool [http-apr-127.0.0.1-auto-I] has not
fully shutdown. Some application threads may still be running.
- 2 ones gone:
IOException in replication worker, unable to drain channel.
Probable cause: Keep alive socket closed[null].
Unit test SEVERE messages: 457 total (+18 rel RC1).
- 6 times SEVERE: Servlet.service() for servlet [regular] in context
with path [] threw exception
- 3 times SEVERE: Servlet.service() for servlet [servlet] in context
with path [] threw exception
- 7 times SEVERE: The web application [] appears to have started a
thread named [pool-1-thread-X] but has failed to stop it. This is very
likely to create a memory leak.
- 2 times SEVERE: Exception while processing an asynchronous request
- 4 times SEVERE: Error processing coordination message. Could be fatal.
- 4 times less SEVERE: Error reading request, ignored
- 4 times SEVERE: Error configuring application listener of class
org.apache.tomcat.util.descriptor.web.ApplicationListener@HEX replaced
with SEVERE: Error configuring application listener of class
org.apache.catalina.core.NoSuchListener
Here's the top 20 SEVERE messages:
Count Message
48 org.apache.catalina.startup.HostConfig.deployDescriptor Error
deploying configuration descriptor
/.../output/test-tmp/conf/Tomcat/localhost/myapp.xml
48 org.apache.catalina.core.ContainerBase.addChildInternal
ContainerBase.addChild: start:
36 org.apache.catalina.core.StandardWrapperValve.invoke
Servlet.service() for servlet [dispatch] in context with path [] threw
exception [Opps.] with root cause
36 org.apache.catalina.core.ApplicationDispatcher.invoke
Servlet.service() for servlet error threw exception
27 org.apache.tomcat.util.digester.Digester.startElement Begin event
threw exception
21 org.apache.catalina.core.StandardContext.startInternal Error
listenerStart
15 org.apache.catalina.core.StandardWrapperValve.invoke
Servlet.service() for servlet [servlet] in context with path [] threw
exception
13 org.apache.catalina.loader.WebappClassLoader.clearReferencesThreads
The web application [] appears to have started a thread named
[pool-x-thread-y] but has failed to stop it. This is very likely to
create a memory leak.
12
org.apache.tomcat.util.descriptor.web.SecurityConstraint.findUncoveredHttpMethods
For security constraints with URL pattern [/] only the HTTP methods
[POST] are covered. All other methods are uncovered.
12
Re: [VOTE] Release Apache Tomcat 8.0.0-RC3
[X] Alpha - go ahead and release as 8.0.0-RC3 alpha Tested with Atmosphere jsr356 and Servlet 3 Async API. -- Jeanfrancois On 2013-09-20 6:36 AM, Mark Thomas wrote: The proposed Apache Tomcat 8.0.0 release candidate 3 is now available for voting. Given this is a release candidate I am working on the basis that it is equivalent to an alpha. The main changes since RC1 are: - Updated spec implementations with results of various grey area discussions from the EG mailing lists - Now uses UTF-8 by default - Switch to async logging and one-line log format by default - New doc style - Refactored TLD parsing (work in progress) - Fixed all the issues reported against RC1 RC2 - Add Servlet 3.1 non-blocking support to the AJP connectors - Fix an issue with the new WebResources and packed WAR files It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC3/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-080/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC3/ The proposed 8.0.0-RC3 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 8.0.0-RC3 alpha Cheers, Mark - 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: Refactoring class loader access to resources
On 23/09/2013 09:08, Rainer Jung wrote: On 23.09.2013 17:27, Mark Thomas wrote: I've mentioned on a couple of different threads that refactoring how the class loader accesses resources was on my TODO list. I haven't done any implementation yet but I have some ideas that I wanted to get some feedback on before I start work. The things I have in mind at this point are: - Extracting anything into the work directory feels like a hack - The class loader should use the same API as every other component - The class loader needs URLs that actually work - The anti-locking options are responsible for a number of the hacks in the class loader The solution I have in mind is along the following lines: - Add a new getClassLoaderResource() to the WebResources interfaces. This will implement the standard WEB-INF/classes then JARs in WEB-INF/lib search order. It should be able to do this without any extraction into the work directory. A useful feature in TC 6/7 was to add search paths outside of the war to look for config files in order to provide config options special to deployment environments without working with individual war files (via VirtualWebappLoader). I know it is possible with the current resource implementation in TC 8, but will it also be possible after this change, i.e. if the webapp retrieves a config file as a resource via the webapp class loader, can we still configure additional directories to be searched for the resource? Yes (assuming I don't mess up the implementation). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55576] Order of ServletRequest parameters is not preserved
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576 --- Comment #4 from Christopher Schultz ch...@christopherschultz.net --- (In reply to corythearchitect from comment #3) The general use case is the servicing of a request in which the order of parameter evaluation is significant. http://host/resource?country=CApostalcode=N7T5R4 Let's assume this is in context of a general infrastructure that evaluates each parameter in the order received (field validation being just one example of potential triggers). postalcode validation is dependent on the value of country. Isn't postalcode validation is dependens on the value of country part of your business logic? If so, you should always be fetching the country first, then the postalcode. Or are you building a system where the order of the parameters in the request dictates the way validation is performed? In any case, I am +1 for changing HashMap-LinkedHashMap to preserve parameter ordering. -- 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
[Bug 55576] Order of ServletRequest parameters is not preserved
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576 --- Comment #5 from corythearchit...@outlook.com --- Or are you building a system where the order of the parameters in the request dictates the way validation is performed? Essentially, yes. -- 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
[WS] To flush or not to flush
Hi Mark, Unless I missed something, Websockets 1.0 on Servlet 3.1 upgrade doesn't do much flushing, so that the IS/OS used in upgrade must effectively just write immediately the data (and ensure it is really sent over the wire). I find that a bit weird, since during the design of Servlets 3.1, the idea was to retain buffering. Of course, upgrade was then added, char support was taken out of the new IO, and it should be feasible to use this sort of bufferless streams in upgraded mode. But that's a lot of assumptions, shouldn't the websockets implementation just flush ? In any case it would be good to have the buffer vs no buffer choice clarified for the upgraded mode [to be honest, I thought it was like the regular Servlet 3.1 IO mode, minus the HTTP transfer encodings]. Thanks, Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1525675 - in /tomcat/tc7.0.x/tags/TOMCAT_7_0_44: ./ build.properties.default
Author: violetagg Date: Mon Sep 23 19:30:21 2013 New Revision: 1525675 URL: http://svn.apache.org/r1525675 Log: Tag 7.0.44 Added: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ (props changed) - copied from r1525674, tomcat/tc7.0.x/trunk/ Modified: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/build.properties.default Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- bugtraq:append = false Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- bugtraq:label = Bugzilla ID (optional) Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- --- bugtraq:message (added) +++ bugtraq:message Mon Sep 23 19:30:21 2013 @@ -0,0 +1 @@ +Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=%BUGID% Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- bugtraq:number = true Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- bugtraq:url = https://issues.apache.org/bugzilla/show_bug.cgi?id=%BUGID% Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- bugtraq:warnifnoissue = false Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- --- subclipse:tags (added) +++ subclipse:tags Mon Sep 23 19:30:21 2013 @@ -0,0 +1,27 @@ +933020,TOMCAT_7_0_0_RC1,/tomcat/tc7.0.x/tags/TOMCAT_7_0_0_RC1,tag +945257,TOMCAT_7_0_0_RC2,/tomcat/tc7.0.x/tags/TOMCAT_7_0_0_RC2,tag +947494,TOMCAT_7_0_0_RC3,/tomcat/tc7.0.x/tags/TOMCAT_7_0_0_RC3,tag +952212,TOMCAT_7_0_0_RC4,/tomcat/tc7.0.x/tags/TOMCAT_7_0_0_RC4,tag +954232,TOMCAT_7_0_0,/tomcat/tc7.0.x/tags/TOMCAT_7_0_0,tag +981255,TOMCAT_7_0_1,/tomcat/tc7.0.x/tags/TOMCAT_7_0_1,tag +982035,TOMCAT_7_0_2,/tomcat/tc7.0.x/tags/TOMCAT_7_0_2,tag +1003912,TOMCAT_7_0_3,/tomcat/tc7.0.x/tags/TOMCAT_7_0_3,tag +1022637,TOMCAT_7_0_4,/tomcat/tc7.0.x/tags/TOMCAT_7_0_4,tag +1038717,TOMCAT_7_0_5,/tomcat/tc7.0.x/tags/TOMCAT_7_0_5,tag +1057288,TOMCAT_7_0_6,/tomcat/tc7.0.x/tags/TOMCAT_7_0_6,tag +1066773,TOMCAT_7_0_7,/tomcat/tc7.0.x/tags/TOMCAT_7_0_7,tag +1067169,TOMCAT_7_0_8,/tomcat/tc7.0.x/tags/TOMCAT_7_0_8,tag +1075337,TOMCAT_7_0_9,/tomcat/tc7.0.x/tags/TOMCAT_7_0_9,tag +1078282,TOMCAT_7_0_10,/tomcat/tc7.0.x/tags/TOMCAT_7_0_10,tag +1080182,TOMCAT_7_0_11,/tomcat/tc7.0.x/tags/TOMCAT_7_0_11,tag +1087797,TOMCAT_7_0_12,/tomcat/tc7.0.x/tags/TOMCAT_7_0_12,tag +1101230,TOMCAT_7_0_14,/tomcat/tc7.0.x/tags/TOMCAT_7_0_14,tag +1101232,TOMCAT_7_0_13,/tomcat/tc7.0.x/tags/TOMCAT_7_0_13,tag +1131469,TOMCAT_7_0_15,/tomcat/tc7.0.x/tags/TOMCAT_7_0_15,tag +1134562,TOMCAT_7_0_16,/tomcat/tc7.0.x/tags/TOMCAT_7_0_16,tag +1142314,TOMCAT_7_0_17,/tomcat/tc7.0.x/tags/TOMCAT_7_0_17,tag +1143610,TOMCAT_7_0_18,/tomcat/tc7.0.x/tags/TOMCAT_7_0_18,tag +1146504,TOMCAT_7_0_19,/tomcat/tc7.0.x/tags/TOMCAT_7_0_19,tag +1155255,TOMCAT_7_0_20,/tomcat/tc7.0.x/tags/TOMCAT_7_0_20,tag +1162976,TOMCAT_7_0_21,/tomcat/tc7.0.x/tags/TOMCAT_7_0_21,tag +1176597,TOMCAT_7_0_22,/tomcat/tc7.0.x/tags/TOMCAT_7_0_22,tag Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- --- svn:ignore (added) +++ svn:ignore Mon Sep 23 19:30:21 2013 @@ -0,0 +1,7 @@ +.* +build.properties +logs +nbproject +output +work +*.iml Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Mon Sep 23 19:30:21 2013 @@ -0,0 +1 @@ +/tomcat/trunk:1156115-1157160,1157162-1157859,1157862-1157942,1157945-1160347,1160349-1163716,1163718-1166689,1166691-1174340,1174342-1175596,1175598-1175611,1175613-1175932,1175934-1177783,1177785-1177980,1178006-1180720,1180722-1183094,1183096-1187753,1187755,1187775,1187801,1187806,1187809,1187826-1188312,1188314-1188401,1188646-1188840,1188842-1190176,1190178-1195223,1195225-1195953,1195955,1195957-1201238,1201240-1203345,1203347-1206623,1206625-1208046,1208073,1208096,1208114,1208145,1208772,1209194-1212125,1212127-1220291,1220293,1220295-1221321,1221323-1222328,1222332-1222401,1222405-1222795,1222850-1222950,1222969-1225326,1225328-1225463,1225465,1225627,1225629-1226534,1226536-1228908,1228911-1228923,1228927-1229532,1229534-1230766,1230768-1231625,1231627-1233414,1233419-1235207,1235209-1237425,1237427,1237429-1237977,1237981,1237985,1237995,1238070,1238073,1239024-1239048,1239050-1239062,1239135,1239256,1239258-1239485,1239785-1240046,1240101,1240106,1240109,1240112,1240114
svn commit: r1525677 - /tomcat/tc7.0.x/tags/TOMCAT_7_0_44/
Author: violetagg Date: Mon Sep 23 19:32:48 2013 New Revision: 1525677 URL: http://svn.apache.org/r1525677 Log: Remove tag TOMCAT_7_0_44 - subclipse:tags property was not removed. Removed: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1525678 - in /tomcat/tc7.0.x/tags/TOMCAT_7_0_44: ./ build.properties.default
Author: violetagg Date: Mon Sep 23 19:37:37 2013 New Revision: 1525678 URL: http://svn.apache.org/r1525678 Log: Tag 7.0.44 Added: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ (props changed) - copied from r1525674, tomcat/tc7.0.x/trunk/ Modified: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/build.properties.default Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- bugtraq:append = false Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- bugtraq:label = Bugzilla ID (optional) Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- --- bugtraq:message (added) +++ bugtraq:message Mon Sep 23 19:37:37 2013 @@ -0,0 +1 @@ +Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=%BUGID% Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- bugtraq:number = true Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- bugtraq:url = https://issues.apache.org/bugzilla/show_bug.cgi?id=%BUGID% Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- bugtraq:warnifnoissue = false Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- --- svn:ignore (added) +++ svn:ignore Mon Sep 23 19:37:37 2013 @@ -0,0 +1,7 @@ +.* +build.properties +logs +nbproject +output +work +*.iml Propchange: tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Mon Sep 23 19:37:37 2013 @@ -0,0 +1 @@ +/tomcat/trunk:1156115-1157160,1157162-1157859,1157862-1157942,1157945-1160347,1160349-1163716,1163718-1166689,1166691-1174340,1174342-1175596,1175598-1175611,1175613-1175932,1175934-1177783,1177785-1177980,1178006-1180720,1180722-1183094,1183096-1187753,1187755,1187775,1187801,1187806,1187809,1187826-1188312,1188314-1188401,1188646-1188840,1188842-1190176,1190178-1195223,1195225-1195953,1195955,1195957-1201238,1201240-1203345,1203347-1206623,1206625-1208046,1208073,1208096,1208114,1208145,1208772,1209194-1212125,1212127-1220291,1220293,1220295-1221321,1221323-1222328,1222332-1222401,1222405-1222795,1222850-1222950,1222969-1225326,1225328-1225463,1225465,1225627,1225629-1226534,1226536-1228908,1228911-1228923,1228927-1229532,1229534-1230766,1230768-1231625,1231627-1233414,1233419-1235207,1235209-1237425,1237427,1237429-1237977,1237981,1237985,1237995,1238070,1238073,1239024-1239048,1239050-1239062,1239135,1239256,1239258-1239485,1239785-1240046,1240101,1240106,1240109,1240112,1240114 ,1240116,1240118,1240121,1240329,1240474-1240850,1240857,1241087,1241160,1241408-1241822,1241908-1241909,1241912-1242110,1242371-1292130,1292134-1292458,1292464-1292670,1292672-1292776,1292780-1293392,1293397-1297017,1297019-1297963,1297965-1299820,1300108,1300111-1300460,1300520-1300948,1300997,1301006,1301280,1302332,1302348,1302608-1302610,1302649,1302837,1303138,1303163,1303338,1303521,1303587,1303698,1303803,1303852,1304011,1304035,1304037,1304135,1304249,1304253,1304260,1304271,1304275,1304468,1304895,1304930-1304932,1305194,1305943,1305965,1306556,1306579-1306580,1307084,1307310,1307511-1307512,1307579,1307591,1307597,1310636,1310639-1310640,1310642,1310701,1311212,1311995,1327617,1327670,1331766,1333161,1333173,1333827,1334787,1335026,1335257,1335547,1335692,1335711,1335731,1336515,1336813,1336864,1336868,1336884,1337419,1337426,1337546,1337572,1337591-1337595,1337643,1337707,1337719,1337734,1337741,1337745,1338151-1338154,1338178,1342027,1342029,1342315,1342320,1342476,1342 498,1342503,1342717,1342795,1342805,1343044-1343046,1343335,1343394,1343400,1343629,1343708,1343718,1343895,1344063,1344068,1344250,1344266,1344515,1344528,1344612,1344629,1344725,1344868,1344890,1344893,1344896,1344901,1345020,1345029,1345039,1345287-1345290,1345294,1345309,1345325,1345357,1345367,1345579-1345580,1345582,1345688,1345699,1345704,1345731-1345732,1345737,1345744,1345752,1345754,1345779,1345781,1345846,1346107,1346376,1346404,1346510,1346514,1346519,1346581,1346635,1346644,1346683,1346794,1346885,1346932,1347034,1347047,1347087,1347108-1347109,1347583,1347737,1348105,1348357,1348398,1348425,1348461-1348495,1348498,1348752,1348762,1348772,1348776,1348859,1348968,1348973,1348989,1349007,1349237,1349298,1349317,1349410,1349473,1349539,1349879,1349887,1349893,1349922,1349984,1350124,1350241,1350243,1350294-1350295,1350299,1350864,1350900,1351010,1351054,1351056,1351068,1351134-1351135,1351148,1351259,1351604,1351636-1351640,1351991,1351993,1352011,1352056,1352059,1352661,1
[Bug 55576] Order of ServletRequest parameters is not preserved
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEEDINFO|NEW -- 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
[Bug 55576] Order of ServletRequest parameters is not preserved
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576 --- Comment #6 from mgrigorov mgrigo...@apache.org --- In my opinion this requirement and the use case are weak. In the best case I'd try to avoid depending on any ordering in the application. But if ordering is really required then I would encode the parameter values and parse them myself and not rely on some container specific feature. E.g.: ?ops=op1|op2|op3something=else, or any other encoding that will work for my use case. With URL encoded value the syntax could be quite rich. On the other hand replacing HashMap with LinkedHashMap will not cause performance degradation so I don't mind such change. -- 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: Refactoring class loader access to resources
The main issue of t8 is it breaks some scanning features when relying on URLClassLoader (getURLs()), not perfect but common in libs... Le 23 sept. 2013 19:00, Mark Thomas ma...@apache.org a écrit : On 23/09/2013 09:08, Rainer Jung wrote: On 23.09.2013 17:27, Mark Thomas wrote: I've mentioned on a couple of different threads that refactoring how the class loader accesses resources was on my TODO list. I haven't done any implementation yet but I have some ideas that I wanted to get some feedback on before I start work. The things I have in mind at this point are: - Extracting anything into the work directory feels like a hack - The class loader should use the same API as every other component - The class loader needs URLs that actually work - The anti-locking options are responsible for a number of the hacks in the class loader The solution I have in mind is along the following lines: - Add a new getClassLoaderResource() to the WebResources interfaces. This will implement the standard WEB-INF/classes then JARs in WEB-INF/lib search order. It should be able to do this without any extraction into the work directory. A useful feature in TC 6/7 was to add search paths outside of the war to look for config files in order to provide config options special to deployment environments without working with individual war files (via VirtualWebappLoader). I know it is possible with the current resource implementation in TC 8, but will it also be possible after this change, i.e. if the webapp retrieves a config file as a resource via the webapp class loader, can we still configure additional directories to be searched for the resource? Yes (assuming I don't mess up the implementation). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Refactoring class loader access to resources
On 23/09/2013 13:21, Romain Manni-Bucau wrote: The main issue of t8 is it breaks some scanning features when relying on URLClassLoader (getURLs()), not perfect but common in libs... Example(s) please. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r2954 [2/2] - in /dev/tomcat/tomcat-7/v7.0.44: ./ bin/ bin/embed/ bin/extras/ src/
Added: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.asc == --- dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.asc (added) +++ dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.asc Mon Sep 23 20:28:26 2013 @@ -0,0 +1,17 @@ +-BEGIN PGP SIGNATURE- +Version: GnuPG v2.0.21 (MingW32) + +iQIcBAABCgAGBQJSQKIrAAoJECCLCrHWMBHH5GsP/jXQyWSSsQiuhY6+z6PikKjU +iztqq6q4v3v0KoTZ9b30eczEz96f37xNpiIzn/+dzXQa+W5Ai6kcq3tMdM4fwIeQ +eSYbbvaM4wMIYtOdyhJtcsSgqZwDzP2nZRPnrgYfRXcKcy/RN3HSg7lbGCIuZt35 +DvjD/TSIWGuGRlDMPKWLXQRh/pI4F1Y+VPyU06bxHEMTip79VugraXC92INnbT3B +7aUcjRbBvxCQnsvr3cRZAJSM3EBl+iiq5LpY7S95Ak5G676jH4WPr07/wvQqC4BH +VzAEW7cA449hX1/JTeb+HAvpfSaGyuWlVdnjneKB8uaNaZN8agNr71Di/7wvOjP3 +ht7W6k5h7tb+pqGhKd0HClCIjqcclA/eUHPPlZ0xQH/hDR9W2fskcCoC+C1GI0WL +ortuhYrkRVxk6LjIbSlODKGxO2fABEdO23KbumwM2tcAqG+2xuxcaZXxfoZQQJCU +GEU58MoC45x4jZYSePC/TVOChFVhAB2+zIiC1J0S++1mYgbPZWGW28SnPjP4iZPo +1znseFQtMGBvJS1p4aGWs+vouOm/O1OWhsxdTfpORrhRMYEQAqbEiZDnNzvvCTES +z2z2RKuvkwfLxITT/W1Vt3WQpV/CEMXnwwQ5EUrVAoBCCiHxVJBAsO9o81ku9w5V +NkguH7fu5JYqLhh0dbPr +=5kih +-END PGP SIGNATURE- Added: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.md5 == --- dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.md5 (added) +++ dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.md5 Mon Sep 23 20:28:26 2013 @@ -0,0 +1 @@ +8012a0f1747fb8e4526e4200c4ad26c5 *apache-tomcat-7.0.44-src.tar.gz \ No newline at end of file Added: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip == Binary file - no diff available. Propchange: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip -- svn:mime-type = application/octet-stream Added: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip.asc == --- dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip.asc (added) +++ dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip.asc Mon Sep 23 20:28:26 2013 @@ -0,0 +1,17 @@ +-BEGIN PGP SIGNATURE- +Version: GnuPG v2.0.21 (MingW32) + +iQIcBAABCgAGBQJSQKHdAAoJECCLCrHWMBHH8CoP/ApeYqY9mZvmgxioN2Z9tfSf +3MO+cj91fAVZ7MVWXMZSoojo/9WBY8xTnsRXciy+N3sEsPBnUVmmATgoX44Si2q/ +E0xuYchvgYuHtBTPnnQOqgVmg1X9hNKCwVwa6RDKyXGww8XgbzkO1QIvODaW2it/ +LP/ot3EJ6eAYus1jMxg0zOt9pEcrGeau6nV0v5c49jHMQaNXwuAU+/2OEN7ONZAc +JYtKoIuLk/Oqkd0RCTebgw7btCuQ2ZUWfFdwKE41bgagzE+Txyc3laEGFaVmObL5 +TSc8x8iYAMnTlEeOm2W+OC0yBbGdlUeHXKakRTHX8uuYKhkGEKkEWAITyRsGdqhy +O9lAVJziygzMoOw0v7kDYsZDY4YlABwqYf85GC24eR79jBjerEWptTo2rss3NY9f +++SM4kxAS659e+mJ0OiHM5FqkQABg1nLC+5PkEKgMlO6GdFcVNaPCy6ZoAnn2R2A +CVbgpFtX8uG+xjMl149XlEZeZnFG2JKoByIT/ky2g7Sl3BmWoszOcFqHn8qiO2yg +1Zy3iezqAT6kB5QdKFZKfVeRII7qYu8OYp55Pw+qpOsE8893qF+N9q/j1vu+rkFM +cTmI/FSv+FBw/uiIi/6CKtxbPOXFroSqV+Odn172jjKaHvVePuJvYp9Q/OWtUbLT +E+NNOt3JxBEajt2q4TNs +=zmIV +-END PGP SIGNATURE- Added: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip.md5 == --- dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip.md5 (added) +++ dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip.md5 Mon Sep 23 20:28:26 2013 @@ -0,0 +1 @@ +bc11cc041e4c4006eb61fda67e92ccc5 *apache-tomcat-7.0.44-src.zip \ No newline at end of file - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Refactoring class loader access to resources
Xbean (so openwebbeans), groovy (so spring lang, groovy etc...) Le 23 sept. 2013 22:27, Mark Thomas ma...@apache.org a écrit : On 23/09/2013 13:21, Romain Manni-Bucau wrote: The main issue of t8 is it breaks some scanning features when relying on URLClassLoader (getURLs()), not perfect but common in libs... Example(s) please. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Refactoring class loader access to resources
On 23/09/2013 13:29, Romain Manni-Bucau wrote: Xbean (so openwebbeans), groovy (so spring lang, groovy etc...) That doesn't help. It needs to be of the form With Tomcat 7 we got... but with Tomcat 8 we get It might also need a and it doesn't work because... depending on how obvious the breakage is. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r2954 [2/2] - in /dev/tomcat/tomcat-7/v7.0.44: ./ bin/ bin/embed/ bin/extras/ src/
Added: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.asc == --- dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.asc (added) +++ dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.asc Mon Sep 23 20:28:26 2013 @@ -0,0 +1,17 @@ +-BEGIN PGP SIGNATURE- +Version: GnuPG v2.0.21 (MingW32) + +iQIcBAABCgAGBQJSQKIrAAoJECCLCrHWMBHH5GsP/jXQyWSSsQiuhY6+z6PikKjU +iztqq6q4v3v0KoTZ9b30eczEz96f37xNpiIzn/+dzXQa+W5Ai6kcq3tMdM4fwIeQ +eSYbbvaM4wMIYtOdyhJtcsSgqZwDzP2nZRPnrgYfRXcKcy/RN3HSg7lbGCIuZt35 +DvjD/TSIWGuGRlDMPKWLXQRh/pI4F1Y+VPyU06bxHEMTip79VugraXC92INnbT3B +7aUcjRbBvxCQnsvr3cRZAJSM3EBl+iiq5LpY7S95Ak5G676jH4WPr07/wvQqC4BH +VzAEW7cA449hX1/JTeb+HAvpfSaGyuWlVdnjneKB8uaNaZN8agNr71Di/7wvOjP3 +ht7W6k5h7tb+pqGhKd0HClCIjqcclA/eUHPPlZ0xQH/hDR9W2fskcCoC+C1GI0WL +ortuhYrkRVxk6LjIbSlODKGxO2fABEdO23KbumwM2tcAqG+2xuxcaZXxfoZQQJCU +GEU58MoC45x4jZYSePC/TVOChFVhAB2+zIiC1J0S++1mYgbPZWGW28SnPjP4iZPo +1znseFQtMGBvJS1p4aGWs+vouOm/O1OWhsxdTfpORrhRMYEQAqbEiZDnNzvvCTES +z2z2RKuvkwfLxITT/W1Vt3WQpV/CEMXnwwQ5EUrVAoBCCiHxVJBAsO9o81ku9w5V +NkguH7fu5JYqLhh0dbPr +=5kih +-END PGP SIGNATURE- Added: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.md5 == --- dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.md5 (added) +++ dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.tar.gz.md5 Mon Sep 23 20:28:26 2013 @@ -0,0 +1 @@ +8012a0f1747fb8e4526e4200c4ad26c5 *apache-tomcat-7.0.44-src.tar.gz \ No newline at end of file Added: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip == Binary file - no diff available. Propchange: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip -- svn:mime-type = application/octet-stream Added: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip.asc == --- dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip.asc (added) +++ dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip.asc Mon Sep 23 20:28:26 2013 @@ -0,0 +1,17 @@ +-BEGIN PGP SIGNATURE- +Version: GnuPG v2.0.21 (MingW32) + +iQIcBAABCgAGBQJSQKHdAAoJECCLCrHWMBHH8CoP/ApeYqY9mZvmgxioN2Z9tfSf +3MO+cj91fAVZ7MVWXMZSoojo/9WBY8xTnsRXciy+N3sEsPBnUVmmATgoX44Si2q/ +E0xuYchvgYuHtBTPnnQOqgVmg1X9hNKCwVwa6RDKyXGww8XgbzkO1QIvODaW2it/ +LP/ot3EJ6eAYus1jMxg0zOt9pEcrGeau6nV0v5c49jHMQaNXwuAU+/2OEN7ONZAc +JYtKoIuLk/Oqkd0RCTebgw7btCuQ2ZUWfFdwKE41bgagzE+Txyc3laEGFaVmObL5 +TSc8x8iYAMnTlEeOm2W+OC0yBbGdlUeHXKakRTHX8uuYKhkGEKkEWAITyRsGdqhy +O9lAVJziygzMoOw0v7kDYsZDY4YlABwqYf85GC24eR79jBjerEWptTo2rss3NY9f +++SM4kxAS659e+mJ0OiHM5FqkQABg1nLC+5PkEKgMlO6GdFcVNaPCy6ZoAnn2R2A +CVbgpFtX8uG+xjMl149XlEZeZnFG2JKoByIT/ky2g7Sl3BmWoszOcFqHn8qiO2yg +1Zy3iezqAT6kB5QdKFZKfVeRII7qYu8OYp55Pw+qpOsE8893qF+N9q/j1vu+rkFM +cTmI/FSv+FBw/uiIi/6CKtxbPOXFroSqV+Odn172jjKaHvVePuJvYp9Q/OWtUbLT +E+NNOt3JxBEajt2q4TNs +=zmIV +-END PGP SIGNATURE- Added: dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip.md5 == --- dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip.md5 (added) +++ dev/tomcat/tomcat-7/v7.0.44/src/apache-tomcat-7.0.44-src.zip.md5 Mon Sep 23 20:28:26 2013 @@ -0,0 +1 @@ +bc11cc041e4c4006eb61fda67e92ccc5 *apache-tomcat-7.0.44-src.zip \ No newline at end of file - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[RESULT][VOTE] Release Apache Tomcat 8.0.0-RC3
+1 (alpha) : binding - markt, schultz, rjung, jfarcand non-binding - Martin Grigorov No other votes were cast. The vote therefore passes. I'll start the process of releasing the bits. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r2955 - /dev/tomcat/tomcat-8/v8.0.0-RC3/ /release/tomcat/tomcat-8/v8.0.0-RC3/
Author: markt Date: Mon Sep 23 20:44:33 2013 New Revision: 2955 Log: Release Apache Tomcat 8.0.0-RC3 Added: release/tomcat/tomcat-8/v8.0.0-RC3/ - copied from r2954, dev/tomcat/tomcat-8/v8.0.0-RC3/ Removed: dev/tomcat/tomcat-8/v8.0.0-RC3/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r2955 - /dev/tomcat/tomcat-8/v8.0.0-RC3/ /release/tomcat/tomcat-8/v8.0.0-RC3/
Author: markt Date: Mon Sep 23 20:44:33 2013 New Revision: 2955 Log: Release Apache Tomcat 8.0.0-RC3 Added: release/tomcat/tomcat-8/v8.0.0-RC3/ - copied from r2954, dev/tomcat/tomcat-8/v8.0.0-RC3/ Removed: dev/tomcat/tomcat-8/v8.0.0-RC3/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
OT: Adding Filters and odd WebLogic Behavior
This is very off topic, and for that I apologize. I'm working on fixing a bug in Log4j 2, and we've discovered something that just doesn't make any sense to me. I /believe/ it's a problem with WebLogic's implementation of the Servlet 3.0 specification, but I could be wrong, and based on my previous experience trying to communicate with WebLogic support, I figured I'd solicit some feedback from the Servlet spec experts on this list to see if I'm in the wrong before I try to bark up that tree again. What we discovered is that if you add a filter programmatically using addFilter(String filterName, String className) or addFilter(String filterName, Class? extends Filter filterClass), everything works fine. The filter's init method is called during application startup, it is invoked in the proper place in the chain, and the destroy method is called during application shutdown, all in the right order. However, if you add the filter using addFilter(String filterName, Filter filter), this is not the case. The filter _is_ still invoked in the proper place in the chain, but its init method is _never_ called. WebLogic ignores the init method completely. The destroy method, however, _is_ still called on application shutdown. Again, this is the _WebLogic_ behavior. I have not been able to duplicate this in Tomcat. Tomcat appears to function the same no matter which method I use to add the filter. Furthermore, I can't find anything in the spec that would support WebLogic's behavior. One thought thrown out was that WebLogic assumed you had already called the init method since you were passing in an instance, but I don't see anything in the spec that supports such an assumption. Am I missing something? Or is WebLogic broken here, as I suspect? Thanks, Nick (BTW, thankfully it doesn't matter to us which method we use, so we're just switching to a different method. But if it's a problem, WebLogic still needs to fix it.) smime.p7s Description: S/MIME cryptographic signature
svn commit: r1525696 - in /tomcat/trunk/java/org/apache: catalina/util/ParameterMap.java tomcat/util/http/Parameters.java
Author: markt
Date: Mon Sep 23 20:52:58 2013
New Revision: 1525696
URL: http://svn.apache.org/r1525696
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55576
Preserve the order that request parameters were presented by the client.
Modified:
tomcat/trunk/java/org/apache/catalina/util/ParameterMap.java
tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java
Modified: tomcat/trunk/java/org/apache/catalina/util/ParameterMap.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/util/ParameterMap.java?rev=1525696r1=1525695r2=1525696view=diff
==
--- tomcat/trunk/java/org/apache/catalina/util/ParameterMap.java (original)
+++ tomcat/trunk/java/org/apache/catalina/util/ParameterMap.java Mon Sep 23
20:52:58 2013
@@ -14,17 +14,13 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*/
-
-
package org.apache.catalina.util;
-
-import java.util.HashMap;
+import java.util.LinkedHashMap;
import java.util.Map;
import org.apache.tomcat.util.res.StringManager;
-
/**
* Extended implementation of strongHashMap/strong that includes a
* codelocked/code property. This class can be used to safely expose
@@ -35,8 +31,7 @@ import org.apache.tomcat.util.res.String
* @author Craig R. McClanahan
* @version $Id$
*/
-
-public final class ParameterMapK,V extends HashMapK,V {
+public final class ParameterMapK,V extends LinkedHashMapK,V {
private static final long serialVersionUID = 1L;
Modified: tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java?rev=1525696r1=1525695r2=1525696view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java Mon Sep 23
20:52:58 2013
@@ -23,7 +23,7 @@ import java.nio.charset.StandardCharsets
import java.util.ArrayList;
import java.util.Collections;
import java.util.Enumeration;
-import java.util.HashMap;
+import java.util.LinkedHashMap;
import java.util.Map;
import org.apache.tomcat.util.buf.B2CConverter;
@@ -49,8 +49,8 @@ public final class Parameters {
private static final StringManager sm =
StringManager.getManager(org.apache.tomcat.util.http);
-private final HashMapString,ArrayListString paramHashValues =
-new HashMap();
+private final MapString,ArrayListString paramHashValues =
+new LinkedHashMap();
private boolean didQueryParameters=false;
private MessageBytes queryMB;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[VOTE] Release Apache Tomcat 7.0.44
The proposed Apache Tomcat 7.0.44 release is now available for voting. This release candidate contains JSR-356 Java WebSocket 1.0 implementation. Note that use of this functionality requires Java 7. It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.44/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-090/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_44/ The proposed 7.0.44 release is: [ ] Broken - do not release [ ] Stable - go ahead and release as 7.0.44 Stable Regards Violeta
Why does mod_jk require a C++ compiler instead of just C?
All, Someone recently on the users list[1] had some trouble building mod_jk and it turned out that the problem was a missing c++ compiler. I did some quick checking and it doesn't look like mod_jk requires a c++ compiler for any actual compilation -- that is, everything is declared as extern C and no obvious c++ features in use. httpd advertises requirements for autoconf, libtool, and an ANSI-C compiler (not C++). I didn't actually try to build httpd without having c++ available. Is this simply an oversight in the configure script? Are we stupidly requiring a C++ compiler, or is there a reason that it is required? If it's required, I'd like to document it in BUILDING.txt. If it's not required, can we fix configure so that it doesn't bomb without a C++ compiler? Actually, if it's required, maybe we can try to figure out how to remove that requirement. Thanks, -chris [1] http://markmail.org/thread/ikrcc4fb477n2nlj signature.asc Description: OpenPGP digital signature
Re: OT: Adding Filters and odd WebLogic Behavior
On 23/09/2013 13:47, Nick Williams wrote: tldr: I'd say that is a WebLogic bug This is very off topic, and for that I apologize. I'm working on fixing a bug in Log4j 2, and we've discovered something that just doesn't make any sense to me. I /believe/ it's a problem with WebLogic's implementation of the Servlet 3.0 specification, but I could be wrong, and based on my previous experience trying to communicate with WebLogic support, I figured I'd solicit some feedback from the Servlet spec experts on this list to see if I'm in the wrong before I try to bark up that tree again. What we discovered is that if you add a filter programmatically using addFilter(String filterName, String className) or addFilter(String filterName, Class? extends Filter filterClass), everything works fine. The filter's init method is called during application startup, it is invoked in the proper place in the chain, and the destroy method is called during application shutdown, all in the right order. However, if you add the filter using addFilter(String filterName, Filter filter), this is not the case. The filter _is_ still invoked in the proper place in the chain, but its init method is _never_ called. WebLogic ignores the init method completely. The destroy method, however, _is_ still called on application shutdown. Again, this is the _WebLogic_ behavior. I have not been able to duplicate this in Tomcat. Tomcat appears to function the same no matter which method I use to add the filter. Furthermore, I can't find anything in the spec that would support WebLogic's behavior. One thought thrown out was that WebLogic assumed you had already called the init method since you were passing in an instance, but I don't see anything in the spec that supports such an assumption. Am I missing something? Or is WebLogic broken here, as I suspect? Servlet 3.0 section 6.2.1 is fairly strong evidence for a WebLogic bug. As is the Javadoc for Filter.init() You might want to check the equivalent addServlet method as well. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1525703 - in /tomcat/tc7.0.x/trunk: build.properties.default res/maven/mvn.properties.default
Author: violetagg Date: Mon Sep 23 21:02:01 2013 New Revision: 1525703 URL: http://svn.apache.org/r1525703 Log: Prep for next version Modified: tomcat/tc7.0.x/trunk/build.properties.default tomcat/tc7.0.x/trunk/res/maven/mvn.properties.default Modified: tomcat/tc7.0.x/trunk/build.properties.default URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/build.properties.default?rev=1525703r1=1525702r2=1525703view=diff == --- tomcat/tc7.0.x/trunk/build.properties.default (original) +++ tomcat/tc7.0.x/trunk/build.properties.default Mon Sep 23 21:02:01 2013 @@ -27,7 +27,7 @@ # - Version Control Flags - version.major=7 version.minor=0 -version.build=44 +version.build=45 version.patch=0 version.suffix=-dev Modified: tomcat/tc7.0.x/trunk/res/maven/mvn.properties.default URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/res/maven/mvn.properties.default?rev=1525703r1=1525702r2=1525703view=diff == --- tomcat/tc7.0.x/trunk/res/maven/mvn.properties.default (original) +++ tomcat/tc7.0.x/trunk/res/maven/mvn.properties.default Mon Sep 23 21:02:01 2013 @@ -35,7 +35,7 @@ maven.asf.release.repo.url=https://repos maven.asf.release.repo.repositoryId=apache.releases # Release version info -maven.asf.release.deploy.version=7.0.44 +maven.asf.release.deploy.version=7.0.45 #Where do we load the libraries from tomcat.lib.path=../../output/build/lib - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55576] Order of ServletRequest parameters is not preserved
https://issues.apache.org/bugzilla/show_bug.cgi?id=55576 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Mark Thomas ma...@apache.org --- Fixed in 8.0.x for 8.0.0-RC4 and 7.0.x for 7.0.45. -- 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: Why does mod_jk require a C++ compiler instead of just C?
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Why does mod_jk require a C++ compiler instead of just C? everything is declared as extern C Wouldn't such declarations require a C++ compiler? I don't think C can parse that. Perhaps the fix would be to wrapper those portions of the function declarations and definitions with #ifdef __cplusplus/#endif. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Why does mod_jk require a C++ compiler instead of just C?
Chuck, On 9/23/13 5:09 PM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Why does mod_jk require a C++ compiler instead of just C? everything is declared as extern C Wouldn't such declarations require a C++ compiler? I don't think C can parse that. Perhaps the fix would be to wrapper those portions of the function declarations and definitions with #ifdef __cplusplus/#endif. I've taken another look and it seems that the places where extern C is used are all in the PCRE package and already have #ifdef __cplusplus surrounding them. -chris signature.asc Description: OpenPGP digital signature
Re: Why does mod_jk require a C++ compiler instead of just C?
All, On 9/23/13 4:58 PM, Christopher Schultz wrote: Someone recently on the users list[1] had some trouble building mod_jk and it turned out that the problem was a missing c++ compiler. I did some quick checking and it doesn't look like mod_jk requires a c++ compiler for any actual compilation -- that is, everything is declared as extern C and no obvious c++ features in use. httpd advertises requirements for autoconf, libtool, and an ANSI-C compiler (not C++). I didn't actually try to build httpd without having c++ available. Is this simply an oversight in the configure script? Are we stupidly requiring a C++ compiler, or is there a reason that it is required? I was just able to build mod_jk on Amazon Linux (roughly RHEL) by: 1. Installing http-devel and gcc-c++ packages 2. Running configure 3. Removing gcc-c++ and gcc46-c++ packages (this removes the C++ compiler) 4. Running make This resulted in a .so file that I have not actually tried running (in httpd), but have every reason to believe would work just fine. I think this is just an erroneous requirement of configure. Can anyone give me some pointers for how to modify the capabilities-scanning that configure does? -chris signature.asc Description: OpenPGP digital signature
buildbot failure in ASF Buildbot on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/4999 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1525696 Blamelist: markt BUILD FAILED: failed compile_1 sincerely, -The Buildbot
[GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 25 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-test : Tomcat 8.x, a web server implementing the Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on junit exists, no need to add for property hamcrest.jar. -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -DEBUG- Dependency on tomcat-trunk exists, no need to add for property tomcat-dbcp.home. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/build/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_work/build_tomcat-trunk_tomcat-trunk-test.html Work Name: build_tomcat-trunk_tomcat-trunk-test (Type: Build) Work ended in a state of : Failed Elapsed: 56 mins 49 secs Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-20130924.jar -Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-2.1-SNAPSHOT.jar -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20130924-native-src.tar.gz -Dexamples.sources.skip=true -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps -Djdt.jar=/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20130924.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20130924-native-src.tar.gz -Dtest.accesslog=true -Dcommons-pool.home=/srv/gump/public/workspace/apache-commons/pool -Dcommons-dbcp.home=/ srv/gump/public/workspace/apache-commons/dbcp -Deasymock.jar=/srv/gump/public/workspace/easymock/easymock/target/easymock-3.3-SNAPSHOT.jar -Dhamcrest.jar=/srv/gump/public/workspace/junit/dist/junit-20130924.jar -Dcglib.jar=/srv/gump/packages/cglib/cglib-nodep-2.2.jar test [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servle t-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/websocket-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-storeconfig.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-jni.jar:/srv/gump/public/workspace/tomcat
Re: Refactoring class loader access to resources
I already explained how t8 loader and WebResource breaks libs based on std URLClassLoader Here is the class in xbean http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/src/main/java/org/apache/xbean/finder/ClassLoaders.java I know we can workaround it but then we miss classes in the loader (was the reason to use getURLs). Another thing is getURLs is insanely fast compared to the other algorithm. Here is the xbean case but a lot of libs do it cause that's the only real way to find urls from loaders. Another thing is jar:war urls will totally break common scanners (all since it was not existing, isnt it?). So tomee, spring, owb, weld, ... will be broken. Finally getURLs still say it respects addURL which doesnt look right (sadly) Le 23 sept. 2013 22:35, Mark Thomas ma...@apache.org a écrit : On 23/09/2013 13:29, Romain Manni-Bucau wrote: Xbean (so openwebbeans), groovy (so spring lang, groovy etc...) That doesn't help. It needs to be of the form With Tomcat 7 we got... but with Tomcat 8 we get It might also need a and it doesn't work because... depending on how obvious the breakage is. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
