svn commit: r1071556 - /tomcat/trunk/test/org/apache/catalina/filters/TestRemoteIpFilter.java
Author: markt
Date: Thu Feb 17 09:20:16 2011
New Revision: 1071556
URL: http://svn.apache.org/viewvc?rev=1071556view=rev
Log:
Prevent NPE in unit tests as a result of r1067718
Modified:
tomcat/trunk/test/org/apache/catalina/filters/TestRemoteIpFilter.java
Modified: tomcat/trunk/test/org/apache/catalina/filters/TestRemoteIpFilter.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/filters/TestRemoteIpFilter.java?rev=1071556r1=1071555r2=1071556view=diff
==
--- tomcat/trunk/test/org/apache/catalina/filters/TestRemoteIpFilter.java
(original)
+++ tomcat/trunk/test/org/apache/catalina/filters/TestRemoteIpFilter.java Thu
Feb 17 09:20:16 2011
@@ -118,6 +118,11 @@ public class TestRemoteIpFilter extends
public void setScheme(String scheme) {
getCoyoteRequest().scheme().setString(scheme);
}
+
+@Override
+public void setAttribute(String name, Object value) {
+// NOOP. Prevents NPE during testing.
+}
}
public static final String TEMP_DIR = System.getProperty(java.io.tmpdir);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1071557 - /tomcat/trunk/test/org/apache/catalina/loader/TestVirtualWebappLoader.java
Author: markt Date: Thu Feb 17 09:29:58 2011 New Revision: 1071557 URL: http://svn.apache.org/viewvc?rev=1071557view=rev Log: Fix test failure now r1069056 has added stricter checks for state transitions Modified: tomcat/trunk/test/org/apache/catalina/loader/TestVirtualWebappLoader.java Modified: tomcat/trunk/test/org/apache/catalina/loader/TestVirtualWebappLoader.java URL: http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/loader/TestVirtualWebappLoader.java?rev=1071557r1=1071556r2=1071557view=diff == --- tomcat/trunk/test/org/apache/catalina/loader/TestVirtualWebappLoader.java (original) +++ tomcat/trunk/test/org/apache/catalina/loader/TestVirtualWebappLoader.java Thu Feb 17 09:29:58 2011 @@ -46,16 +46,16 @@ public class TestVirtualWebappLoader ext ctx.resourcesStart(); File dir = new File(test/webapp-3.0-fragments/WEB-INF/lib); loader.setVirtualClasspath(dir.getAbsolutePath() + /*.jar); -loader.startInternal(); +loader.start(); String[] repos = loader.getRepositories(); assertEquals(2,repos.length); -loader.stopInternal(); +loader.stop(); // ToDo: Why doesn't remove repositories? repos = loader.getRepositories(); assertEquals(2, repos.length); // no leak -loader.startInternal(); +loader.start(); repos = loader.getRepositories(); assertEquals(2,repos.length); - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1071560 - /tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
Author: rjung
Date: Thu Feb 17 09:51:17 2011
New Revision: 1071560
URL: http://svn.apache.org/viewvc?rev=1071560view=rev
Log:
Remove duplicate code.
The implementation in the base class is identical and all other http11
implementations also inherit it from there.
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?rev=1071560r1=1071559r2=1071560view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java Thu Feb
17 09:51:17 2011
@@ -987,22 +987,6 @@ public class Http11NioProcessor extends
}
-/**
- * Determine if we must drop the connection because of the HTTP status
- * code. Use the same list of codes as Apache/httpd.
- */
-@Override
-protected boolean statusDropsConnection(int status) {
-return status == 400 /* SC_BAD_REQUEST */ ||
- status == 408 /* SC_REQUEST_TIMEOUT */ ||
- status == 411 /* SC_LENGTH_REQUIRED */ ||
- status == 413 /* SC_REQUEST_ENTITY_TOO_LARGE */ ||
- status == 414 /* SC_REQUEST_URI_TOO_LONG */ ||
- status == 500 /* SC_INTERNAL_SERVER_ERROR */ ||
- status == 503 /* SC_SERVICE_UNAVAILABLE */ ||
- status == 501 /* SC_NOT_IMPLEMENTED */;
-}
-
@Override
protected AbstractInputBuffer getInputBuffer() {
return inputBuffer;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1071561 - in /tomcat/trunk: java/javax/el/BeanELResolver.java java/org/apache/el/parser/AstValue.java test/org/apache/el/TestMethodExpressionImpl.java webapps/docs/changelog.xml
Author: markt
Date: Thu Feb 17 09:59:30 2011
New Revision: 1071561
URL: http://svn.apache.org/viewvc?rev=1071561view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50790
Improve method resolution in EL expressions
Add test cases for this bug
Modified:
tomcat/trunk/java/javax/el/BeanELResolver.java
tomcat/trunk/java/org/apache/el/parser/AstValue.java
tomcat/trunk/test/org/apache/el/TestMethodExpressionImpl.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/javax/el/BeanELResolver.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/el/BeanELResolver.java?rev=1071561r1=1071560r2=1071561view=diff
==
--- tomcat/trunk/java/javax/el/BeanELResolver.java (original)
+++ tomcat/trunk/java/javax/el/BeanELResolver.java Thu Feb 17 09:59:30 2011
@@ -413,7 +413,8 @@ public class BeanELResolver extends ELRe
}
Method[] methods = clazz.getMethods();
for (Method m : methods) {
-if (m.getParameterTypes().length == paramCount) {
+if (methodName.equals(m.getName())
+m.getParameterTypes().length == paramCount) {
// Same number of parameters - use the first match
matchingMethod = m;
break;
Modified: tomcat/trunk/java/org/apache/el/parser/AstValue.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/el/parser/AstValue.java?rev=1071561r1=1071560r2=1071561view=diff
==
--- tomcat/trunk/java/org/apache/el/parser/AstValue.java (original)
+++ tomcat/trunk/java/org/apache/el/parser/AstValue.java Thu Feb 17 09:59:30
2011
@@ -156,8 +156,8 @@ public final class AstValue extends Simp
AstMethodParameters mps =
(AstMethodParameters) this.children[i+1];
// This is a method
-base = resolver.invoke(ctx, base, suffix,
-mps.getParameterTypes(ctx), mps.getParameters(ctx));
+base = resolver.invoke(ctx, base, suffix, null,
+mps.getParameters(ctx));
i+=2;
} else {
// This is a property
Modified: tomcat/trunk/test/org/apache/el/TestMethodExpressionImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/el/TestMethodExpressionImpl.java?rev=1071561r1=1071560r2=1071561view=diff
==
--- tomcat/trunk/test/org/apache/el/TestMethodExpressionImpl.java (original)
+++ tomcat/trunk/test/org/apache/el/TestMethodExpressionImpl.java Thu Feb 17
09:59:30 2011
@@ -349,4 +349,18 @@ public class TestMethodExpressionImpl ex
String actual = (String) me1.invoke(context, null);
assertEquals(Hello Tomcat from B, actual);
}
+
+public void testBug50790a() throws Exception {
+ValueExpression ve = factory.createValueExpression(context,
+#{beanAA.name.contains(beanA.name)},
java.lang.Boolean.class);
+Boolean actual = (Boolean) ve.getValue(context);
+assertEquals(Boolean.TRUE, actual);
+}
+
+public void testBug50790b() throws Exception {
+ValueExpression ve = factory.createValueExpression(context,
+#{beanA.name.contains(beanAA.name)},
java.lang.Boolean.class);
+Boolean actual = (Boolean) ve.getValue(context);
+assertEquals(Boolean.FALSE, actual);
+}
}
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1071561r1=1071560r2=1071561view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Thu Feb 17 09:59:30 2011
@@ -107,6 +107,9 @@
not result in String constants that are too long for valid Java code.
(markt)
/fix
+ fix
+bug50790/bug: Improve method resolution in EL expressions. (markt)
+ /fix
/changelog
/subsection
subsection name=Cluster
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50790] EL parser needs to be more dynamic
https://issues.apache.org/bugzilla/show_bug.cgi?id=50790 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mark Thomas ma...@apache.org 2011-02-17 04:59:55 EST --- Thanks for the report. This has been fixed in 7.0.x and will be included in 7.0.9 onwards. -- 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: Connection draining when upload to large
On 10.02.2011 18:44, Mark Thomas wrote: On 10/02/2011 13:04, Rainer Jung wrote: Servlet 3 standardizes file uploads. It contains the ability to limit on request size, pretty much the same as commons fileupload supported for many years. It seems when this conditions triggers the rest of the request inout stream is still drained at the end of the request. swallowInput is not being set to false. It seems there's still no server-side prevention against huge uploads possible. The upload is not put into memory, but the thread is only freed once the whole request body is read. Shouldn't Tomcat ignore the rest of data and close the connection in this case? Yep. Because of Bill's remark about HTTP compliance and the result of my browser tests, I think the default behaviour at least for TC before 7 should stay as is. I implemented a simple patch for the TC 7 HTTP connectors using a custom request property to allow the application to signal to the container, that it should drop the connection and not drain it: http://people.apache.org/~rjung/patches/tomcat-trunk-upload-abort.patch Default: unchanged behaviour. Since there's no universally correct setting and the correct behaviour depends on the application use case a request attribute sounded OK. A connector configuration or system property doesn't sound right and a context configuration might be nasty to get pushed down to the connector code, though I didn't check that (although I could likely again use a request attribute to push the info down to the connector). I still need to experiment with the AJP connectors. It wasn't obvious from the impl how it handles the situation. Any hints about where to add stuff to the docs? Are people fine with making it controllable via the request attribute? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1071565 - in /tomcat/trunk: java/org/apache/catalina/Context.java java/org/apache/catalina/core/ApplicationDispatcher.java java/org/apache/catalina/core/StandardContext.java webapps/docs/
Author: markt
Date: Thu Feb 17 10:32:07 2011
New Revision: 1071565
URL: http://svn.apache.org/viewvc?rev=1071565view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50789
Provide an option to enable ServletRequestListeners for forwards as required by
some CDI frameworks.
Modified:
tomcat/trunk/java/org/apache/catalina/Context.java
tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
tomcat/trunk/webapps/docs/changelog.xml
tomcat/trunk/webapps/docs/config/context.xml
Modified: tomcat/trunk/java/org/apache/catalina/Context.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/Context.java?rev=1071565r1=1071564r2=1071565view=diff
==
--- tomcat/trunk/java/org/apache/catalina/Context.java (original)
+++ tomcat/trunk/java/org/apache/catalina/Context.java Thu Feb 17 10:32:07 2011
@@ -1315,5 +1315,18 @@ public interface Context extends Contain
* deployment. If not specified, defaults to the empty string.
*/
public String getWebappVersion();
+
+/**
+ * Configure whether or not requests listeners will be fired on forwards
for
+ * this Context.
+ */
+public void setFireRequestListenersOnForwards(boolean enable);
+
+/**
+ * Determine whether or not requests listeners will be fired on forwards
for
+ * this Context.
+ */
+public boolean getFireRequestListenersOnForwards();
+
}
Modified: tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java?rev=1071565r1=1071564r2=1071565view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java Thu
Feb 17 10:32:07 2011
@@ -453,19 +453,31 @@ final class ApplicationDispatcher
DispatcherType disInt = (DispatcherType)
request.getAttribute(ApplicationFilterFactory.DISPATCHER_TYPE_ATTR);
if (disInt != null) {
-if (disInt != DispatcherType.ERROR) {
-state.outerRequest.setAttribute
-(ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR,
- getCombinedPath());
-state.outerRequest.setAttribute
-(ApplicationFilterFactory.DISPATCHER_TYPE_ATTR,
- DispatcherType.FORWARD);
-invoke(state.outerRequest, response, state);
-} else {
-invoke(state.outerRequest, response, state);
+boolean doInvoke = true;
+
+if (context.getFireRequestListenersOnForwards()
+!context.fireRequestInitEvent(request)) {
+doInvoke = false;
+}
+
+if (doInvoke) {
+if (disInt != DispatcherType.ERROR) {
+state.outerRequest.setAttribute
+(ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR,
+ getCombinedPath());
+state.outerRequest.setAttribute
+(ApplicationFilterFactory.DISPATCHER_TYPE_ATTR,
+ DispatcherType.FORWARD);
+invoke(state.outerRequest, response, state);
+} else {
+invoke(state.outerRequest, response, state);
+}
+
+if (context.getFireRequestListenersOnForwards()) {
+context.fireRequestDestroyEvent(request);
+}
}
}
-
}
Modified: tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardContext.java?rev=1071565r1=1071564r2=1071565view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Thu Feb 17
10:32:07 2011
@@ -833,10 +833,24 @@ public class StandardContext extends Con
private String webappVersion = ;
private boolean addWebinfClassesResources = false;
+
+private boolean fireRequestListenersOnForwards = false;
// - Context Properties
+@Override
+public void setFireRequestListenersOnForwards(boolean enable) {
+fireRequestListenersOnForwards = enable;
+}
+
+
+@Override
+public boolean getFireRequestListenersOnForwards() {
+return fireRequestListenersOnForwards;
+}
+
+
public void setAddWebinfClassesResources(
DO NOT REPLY [Bug 50789] custom error pages and CDI/weld problem
https://issues.apache.org/bugzilla/show_bug.cgi?id=50789 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mark Thomas ma...@apache.org 2011-02-17 05:32:54 EST --- I have added a new option to the Context that enabled ServletRequestListeners to be fired on Forwards. This is in 7.0.x and will be included in 7.0.9 onwards. -- 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: Connection draining when upload to large
On 17/02/2011 10:30, Rainer Jung wrote: On 10.02.2011 18:44, Mark Thomas wrote: On 10/02/2011 13:04, Rainer Jung wrote: Servlet 3 standardizes file uploads. It contains the ability to limit on request size, pretty much the same as commons fileupload supported for many years. It seems when this conditions triggers the rest of the request inout stream is still drained at the end of the request. swallowInput is not being set to false. It seems there's still no server-side prevention against huge uploads possible. The upload is not put into memory, but the thread is only freed once the whole request body is read. Shouldn't Tomcat ignore the rest of data and close the connection in this case? Yep. Because of Bill's remark about HTTP compliance and the result of my browser tests, I think the default behaviour at least for TC before 7 should stay as is. I'd be happy to address the original issue and not swallow the input when a user attempts to upload too large a file. I also need to read through the HTTP spec and see what exactly we are breaking by not reading the entire input stream. I implemented a simple patch for the TC 7 HTTP connectors using a custom request property to allow the application to signal to the container, that it should drop the connection and not drain it: http://people.apache.org/~rjung/patches/tomcat-trunk-upload-abort.patch Default: unchanged behaviour. Looks like the default behaviour is changed in some cases. Since there's no universally correct setting and the correct behaviour depends on the application use case a request attribute sounded OK. A connector configuration or system property doesn't sound right and a context configuration might be nasty to get pushed down to the connector code, though I didn't check that (although I could likely again use a request attribute to push the info down to the connector). I still need to experiment with the AJP connectors. It wasn't obvious from the impl how it handles the situation. Any hints about where to add stuff to the docs? Are people fine with making it controllable via the request attribute? I'm not particularly comfortable with this. I'm having a hard time coming up with a use case where some requests are swallowed and some are not. I think I'd prefer a per Connector or per Context attribute. I need to read the right part of the HTTP spec though since the wording there is likely to influence my views. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Connection draining when upload to large
On 17/02/2011 10:41, Mark Thomas wrote: On 17/02/2011 10:30, Rainer Jung wrote: On 10.02.2011 18:44, Mark Thomas wrote: On 10/02/2011 13:04, Rainer Jung wrote: Servlet 3 standardizes file uploads. It contains the ability to limit on request size, pretty much the same as commons fileupload supported for many years. It seems when this conditions triggers the rest of the request inout stream is still drained at the end of the request. swallowInput is not being set to false. It seems there's still no server-side prevention against huge uploads possible. The upload is not put into memory, but the thread is only freed once the whole request body is read. Shouldn't Tomcat ignore the rest of data and close the connection in this case? Yep. Because of Bill's remark about HTTP compliance and the result of my browser tests, I think the default behaviour at least for TC before 7 should stay as is. I'd be happy to address the original issue and not swallow the input when a user attempts to upload too large a file. I also need to read through the HTTP spec and see what exactly we are breaking by not reading the entire input stream. Just read section 8.2 of RFC 2616. There are a fair number of SHOULDs in this section for both the client and the server. The requirement that server read all input and not close the connection (on the basis that the client will stop sending data when it receives an error status code) is SHOULD NOT rather than MUST NOT. Further, the spec explicitly allows the server to close the connection for DOS protection. Given this, I am leaning even more towards just fixing the original issue that the connection is not dropped when the request exceeds the upload limit and leaving the rest of the behaviour unchanged. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Connection draining when upload to large
On 17.02.2011 11:58, Mark Thomas wrote: On 17/02/2011 10:41, Mark Thomas wrote: On 17/02/2011 10:30, Rainer Jung wrote: On 10.02.2011 18:44, Mark Thomas wrote: On 10/02/2011 13:04, Rainer Jung wrote: Servlet 3 standardizes file uploads. It contains the ability to limit on request size, pretty much the same as commons fileupload supported for many years. It seems when this conditions triggers the rest of the request inout stream is still drained at the end of the request. swallowInput is not being set to false. It seems there's still no server-side prevention against huge uploads possible. The upload is not put into memory, but the thread is only freed once the whole request body is read. Shouldn't Tomcat ignore the rest of data and close the connection in this case? Yep. Because of Bill's remark about HTTP compliance and the result of my browser tests, I think the default behaviour at least for TC before 7 should stay as is. I'd be happy to address the original issue and not swallow the input when a user attempts to upload too large a file. I also need to read through the HTTP spec and see what exactly we are breaking by not reading the entire input stream. Just read section 8.2 of RFC 2616. There are a fair number of SHOULDs in this section for both the client and the server. The requirement that server read all input and not close the connection (on the basis that the client will stop sending data when it receives an error status code) is SHOULD NOT rather than MUST NOT. Further, the spec explicitly allows the server to close the connection for DOS protection. Given this, I am leaning even more towards just fixing the original issue that the connection is not dropped when the request exceeds the upload limit and leaving the rest of the behaviour unchanged. Just one more data point: with Firefox the browser doesn't read the response from the connection if the server closes his side of the connection before reading all data. Firefox tries to proceed sending until the TCP/IP stack of the server starts responding with reset packets. A that time it is to late to read the response. If you read all data from the connection, then the browser will start reading the response and display it, even if the response was alread send much earlier. But nowadays uploads are more often handled by JavaScript or Flash etc. solutions running inside the browser which actually do not expect real answer. Closing the connection here results i an error status that the calling JavaScript code might be able to handle and reflect in the UI. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Test suite failures for TC 7 (MBeanUtils, host null)
I get test suite failures for TC 7 right now. I'm not sure whether it is because I changed my testing environment, but the failure seems to be pretty special, namely a NullPointerException in MBeanUtils.createObjectName() line 532. I added some logging and the reason is, that the host returned by Container host = context.getParent(); is null. Feb 17, 2011 11:56:48 AM org.apache.catalina.deploy.NamingResources destroyInternal WARNING: namingResources.mbeanDestroyFail java.lang.NullPointerException at org.apache.catalina.mbeans.MBeanUtils.createObjectName(MBeanUtils.java:532) at org.apache.catalina.mbeans.MBeanUtils.destroyMBean(MBeanUtils.java:1154) at org.apache.catalina.deploy.NamingResources.destroyInternal(NamingResources.java:976) at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:277) at org.apache.catalina.core.StandardContext.destroyInternal(StandardContext.java:5484) at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:277) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:969) at org.apache.catalina.core.ContainerBase.destroyInternal(ContainerBase.java:1108) at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:277) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:969) at org.apache.catalina.core.ContainerBase.destroyInternal(ContainerBase.java:1108) at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:277) at org.apache.catalina.core.StandardService.destroyInternal(StandardService.java:593) at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:277) at org.apache.catalina.core.StandardServer.destroyInternal(StandardServer.java:788) at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:277) at org.apache.catalina.startup.Tomcat.destroy(Tomcat.java:323) The MBean name for the first failure is Catalina:type=Environment,resourcetype=Context,context=/examples,host=NULL,name=name3 (I replaced host.getName() with NULL when host is null) but there are many such failures during the test run. Not sure, but because it always seems to happen on destroy, it might be a lifecycle issue? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Test suite failures for TC 7 (MBeanUtils, host null)
2011/2/17 Rainer Jung rainer.j...@kippdata.de: I get test suite failures for TC 7 right now. I'm not sure whether it is because I changed my testing environment, but the failure seems to be pretty special, namely a NullPointerException in MBeanUtils.createObjectName() line 532. I have an old working copy (updated yesterday), i.e. before Mark's http://svn.apache.org/viewvc?view=revisionrevision=1071556 and I also observe those NPEs with namingResources.mbeanDestroyFail So it is not specific to your environment. I do not know yet whether any of today's commits fixes them. (BTW, seeing plain namingResources.mbeanDestroyFail in the logs means that the message is not found in the resource file.) These failures (and no nagging about them on the list) mean that there is no CI tool that runs the tests for us. The buildbot runs ant release and the release target does not depend on the test one. http://ci.apache.org/builders/tomcat-trunk/ Shouldn't we ask buildbot admins to replace that with ant release test? I do not quite remember how it was configured previously (I think that ant test was a separate step in the build sequence, named like compile_1). Apparently Gump does not test it either. Any more ideas how CI testing should be configured? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Test suite failures for TC 7 (MBeanUtils, host null)
On 17/02/2011 12:02, Konstantin Kolinko wrote: 2011/2/17 Rainer Jung rainer.j...@kippdata.de: I get test suite failures for TC 7 right now. I'm not sure whether it is because I changed my testing environment, but the failure seems to be pretty special, namely a NullPointerException in MBeanUtils.createObjectName() line 532. I have an old working copy (updated yesterday), i.e. before Mark's http://svn.apache.org/viewvc?view=revisionrevision=1071556 and I also observe those NPEs with namingResources.mbeanDestroyFail So it is not specific to your environment. I do not know yet whether any of today's commits fixes them. Not yet. I only fixed the test failures. (BTW, seeing plain namingResources.mbeanDestroyFail in the logs means that the message is not found in the resource file.) That is likely to be my fault - I'll fix that. These failures (and no nagging about them on the list) mean that there is no CI tool that runs the tests for us. The buildbot runs ant release and the release target does not depend on the test one. http://ci.apache.org/builders/tomcat-trunk/ Shouldn't we ask buildbot admins to replace that with ant release test? +1 Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1071591 - /tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties
Author: markt
Date: Thu Feb 17 12:10:32 2011
New Revision: 1071591
URL: http://svn.apache.org/viewvc?rev=1071591view=rev
Log:
Fix typo
Modified:
tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties
Modified: tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties?rev=1071591r1=1071590r2=1071591view=diff
==
--- tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties Thu
Feb 17 12:10:32 2011
@@ -44,5 +44,4 @@ webXml.version.nfe=Unable to parse [{0}]
webXml.wrongFragmentName=Used a wrong fragment name {0} at web.xml
absolute-ordering tag!
namingResources.mbeanCreateFail=Failed to create MBean for naming resource
[{0}]
-namingResoucres.mbeanDestroyFail=Failed to destroy MBean for naming resource
[{1}]
-
+namingResources.mbeanDestroyFail=Failed to destroy MBean for naming resource
[{1}]
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1071592 - /tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties
Author: markt
Date: Thu Feb 17 12:11:36 2011
New Revision: 1071592
URL: http://svn.apache.org/viewvc?rev=1071592view=rev
Log:
Typo? Copy and paste error?
Modified:
tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties
Modified: tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties?rev=1071592r1=1071591r2=1071592view=diff
==
--- tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties Thu
Feb 17 12:11:36 2011
@@ -44,4 +44,4 @@ webXml.version.nfe=Unable to parse [{0}]
webXml.wrongFragmentName=Used a wrong fragment name {0} at web.xml
absolute-ordering tag!
namingResources.mbeanCreateFail=Failed to create MBean for naming resource
[{0}]
-namingResources.mbeanDestroyFail=Failed to destroy MBean for naming resource
[{1}]
+namingResources.mbeanDestroyFail=Failed to destroy MBean for naming resource
[{0}]
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Test suite failures for TC 7 (MBeanUtils, host null)
On 17/02/2011 12:06, Mark Thomas wrote: On 17/02/2011 12:02, Konstantin Kolinko wrote: 2011/2/17 Rainer Jung rainer.j...@kippdata.de: I get test suite failures for TC 7 right now. I'm not sure whether it is because I changed my testing environment, but the failure seems to be pretty special, namely a NullPointerException in MBeanUtils.createObjectName() line 532. I have an old working copy (updated yesterday), i.e. before Mark's http://svn.apache.org/viewvc?view=revisionrevision=1071556 and I also observe those NPEs with namingResources.mbeanDestroyFail So it is not specific to your environment. I do not know yet whether any of today's commits fixes them. Not yet. I only fixed the test failures. The issue is lifecycle related around removing children from parents. There are currently a bunch of 'fixes' for various edge cases. I am plan to review the whole process and will probably re-factor this part of the life-cycle code. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1071601 - /tomcat/trunk/java/org/apache/catalina/core/ContainerBase.java
Author: markt
Date: Thu Feb 17 13:10:36 2011
New Revision: 1071601
URL: http://svn.apache.org/viewvc?rev=1071601view=rev
Log:
Fix NPEs on shutdown. Loop is prevented above when the child is removed.
Modified:
tomcat/trunk/java/org/apache/catalina/core/ContainerBase.java
Modified: tomcat/trunk/java/org/apache/catalina/core/ContainerBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/ContainerBase.java?rev=1071601r1=1071600r2=1071601view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/ContainerBase.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/ContainerBase.java Thu Feb 17
13:10:36 2011
@@ -959,8 +959,6 @@ public abstract class ContainerBase exte
fireContainerEvent(REMOVE_CHILD_EVENT, child);
-// Set child's parent to null to prevent a loop
-child.setParent(null);
try {
// child.destroy() may have already been called which would have
// triggered this call. If that is the case, no need to destroy the
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1071614 - /tomcat/trunk/java/org/apache/coyote/http11/Http11Protocol.java
Author: markt
Date: Thu Feb 17 14:04:37 2011
New Revision: 1071614
URL: http://svn.apache.org/viewvc?rev=1071614view=rev
Log:
Remove unnecessary code.
I don't see a code path that could result in the socket being in the map at
this point
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11Protocol.java
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11Protocol.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11Protocol.java?rev=1071614r1=1071613r2=1071614view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11Protocol.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11Protocol.java Thu Feb 17
14:04:37 2011
@@ -193,7 +193,6 @@ public class Http11Protocol extends Abst
// complete or dispatch)
return processor.asyncPostProcess();
} else {
-connections.remove(socket);
socket.setAsync(false);
recycledProcessors.offer(processor);
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1071617 - /tomcat/trunk/java/org/apache/coyote/ajp/AjpProtocol.java
Author: markt
Date: Thu Feb 17 14:11:41 2011
New Revision: 1071617
URL: http://svn.apache.org/viewvc?rev=1071617view=rev
Log:
Remove unnecessary code.
I don't see a code path that could result in the socket being in the map at
this point
Modified:
tomcat/trunk/java/org/apache/coyote/ajp/AjpProtocol.java
Modified: tomcat/trunk/java/org/apache/coyote/ajp/AjpProtocol.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ajp/AjpProtocol.java?rev=1071617r1=1071616r2=1071617view=diff
==
--- tomcat/trunk/java/org/apache/coyote/ajp/AjpProtocol.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ajp/AjpProtocol.java Thu Feb 17
14:11:41 2011
@@ -188,7 +188,6 @@ public class AjpProtocol extends Abstrac
// complete or dispatch)
return processor.asyncPostProcess();
} else {
-connections.remove(socket);
socket.setAsync(false);
recycledProcessors.offer(processor);
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50780] AjpConnectionHandler keeps many connections causing memory leak
https://issues.apache.org/bugzilla/show_bug.cgi?id=50780 --- Comment #3 from Mark Thomas ma...@apache.org 2011-02-17 09:18:17 EST --- Yes it does still happen with 7.0.8 and is specific to the APR implementation of the AJP connector. Testing a fix now... -- 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
[Tomcat Wiki] Update of DocumentInOtherLanguages by huyuchengus
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The DocumentInOtherLanguages page has been changed by huyuchengus. http://wiki.apache.org/tomcat/DocumentInOtherLanguages?action=diffrev1=4rev2=5 -- Here is a list of Tomcat documents in other languages. - * [[http://tomcat.jaxmao.org/|Tomcat 5.5 中文应用手册]] Chinese translation of Tomcat 5.5 document + * [[http://tomcat.jaxmao.org/|Tomcat 5.5 中文应用手册]] Chinese translation of Tomcat 5.5 document + * [[http://www.ossez.com/forumdisplay.php?fid=21 |OSS 技术技术 - Tomcat 社区]] Tomcat Social Group for Chinese - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of DocumentInOtherLanguages by huyuchengus
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The DocumentInOtherLanguages page has been changed by huyuchengus. http://wiki.apache.org/tomcat/DocumentInOtherLanguages?action=diffrev1=5rev2=6 -- Here is a list of Tomcat documents in other languages. + [[Tomcat 中文文档]] - * [[http://tomcat.jaxmao.org/|Tomcat 5.5 中文应用手册]] Chinese translation of Tomcat 5.5 document - * [[http://www.ossez.com/forumdisplay.php?fid=21 |OSS 技术技术 - Tomcat 社区]] Tomcat Social Group for Chinese + === 参考链接 === + + [[http://www.ossez.com/forumdisplay.php?fid=21 |OSS 计算技术 - Tomcat 社区]] Tomcat Social Group for Chinese + + [[http://tomcat.jaxmao.org/|Tomcat 5.5 中文应用手册]] Chinese translation of Tomcat 5.5 document + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of Tomcat 中文文档 by huyuchengus
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The Tomcat 中文文档 page has been changed by huyuchengus. http://wiki.apache.org/tomcat/Tomcat%20%E4%B8%AD%E6%96%87%E6%96%87%E6%A1%A3 -- New page: 以下内容由 [[http://www.ossez.com/forumdisplay.php?fid=21|OSS 计算技术 - Tomcat 中文社区]] 贡献。 更多的详细内容请访问下面的地址[[http://www.ossez.com/forumdisplay.php?fid=21|http://www.ossez.com/forumdisplay.php?fid=21]] = Tomcat 简介 = Tomcat是Apache 软件基金会（Apache Software Foundation）的Jakarta 项目中的一个核心项目，由Apache、Sun 和其他一些公司及个人共同开发而成。由于有了Sun 的参与和支持，最新的Servlet 和JSP 规范总是能在Tomcat 中得到体现，Tomcat 5 支持最新的Servlet 2.4 和JSP 2.0 规范。因为Tomcat 技术先进、性能稳定，而且免费，因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可，成为目前比较流行的Web 应用服务器。目前最新版本是6.0。 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of Tomcat 中文文档 by huyuchengus
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The Tomcat 中文文档 page has been changed by huyuchengus. http://wiki.apache.org/tomcat/Tomcat%20%E4%B8%AD%E6%96%87%E6%96%87%E6%A1%A3?action=diffrev1=1rev2=2 -- = Tomcat 简介 = Tomcat是Apache 软件基金会（Apache Software Foundation）的Jakarta 项目中的一个核心项目，由Apache、Sun 和其他一些公司及个人共同开发而成。由于有了Sun 的参与和支持，最新的Servlet 和JSP 规范总是能在Tomcat 中得到体现，Tomcat 5 支持最新的Servlet 2.4 和JSP 2.0 规范。因为Tomcat 技术先进、性能稳定，而且免费，因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可，成为目前比较流行的Web 应用服务器。目前最新版本是6.0。 + == Tomcat 索引 == + 这里的索引为与 Tomcat 相关的知识，通过版本划分来提供一个快速索引，通过这个方式来提高知识的利用效率。 + + *[[Tomcat 特性]] + *[[Tomcat 安装/使用]] + *[[Tomcat 优化]] + + == Tomcat 常见问题 == + + [[Category:OSS Tomcat]] + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-taglibs-standard (in module tomcat-taglibs) 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-taglibs-standard has an issue affecting its community
integration.
This issue affects 2 projects,
and has been outstanding for 89 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-taglibs-standard : Standard Taglib
- tomcat-taglibs-standard-install : JSP Taglibs
Full details are available at:
http://vmgump.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-INFO- Optional dependency httpunit failed with reason build failed
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/tomcat-taglibs/standard/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/tomcat-taglibs/standard/pom.xml
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/gump_work/build_tomcat-taglibs_tomcat-taglibs-standard.html
Work Name: build_tomcat-taglibs_tomcat-taglibs-standard (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 3 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings
/srv/gump/public/workspace/tomcat-taglibs/standard/gump_mvn_settings.xml
install
[Working Directory: /srv/gump/public/workspace/tomcat-taglibs/standard]
M2_HOME: /opt/maven2
-
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/srv/gump/public/workspace/tomcat-taglibs/standard/spec/src/test/resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] No sources to compile
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [bundle:bundle {execution: default-bundle}]
[INFO] [install:install {execution: default-install}]
[INFO] Installing
/srv/gump/public/workspace/tomcat-taglibs/standard/spec/target/taglibs-standard-spec-1.2-SNAPSHOT.jar
to
/srv/gump/public/workspace/mvnlocalrepo/shared/org/apache/taglibs/taglibs-standard-spec/1.2-SNAPSHOT/taglibs-standard-spec-1.2-SNAPSHOT.jar
[INFO] [bundle:install {execution: default-install}]
[INFO] Parsing
file:/srv/gump/public/workspace/mvnlocalrepo/shared/repository.xml
[INFO] Installing
org/apache/taglibs/taglibs-standard-spec/1.2-SNAPSHOT/taglibs-standard-spec-1.2-SNAPSHOT.jar
[INFO] Writing OBR metadata
[INFO]
[INFO] Building Apache Standard Taglib - JSTL Implementation
[INFO]task-segment: [install]
[INFO]
[INFO] [remote-resources:process {execution: default}]
[INFO] snapshot org.apache.taglibs:taglibs-standard-spec:1.2-SNAPSHOT: checking
for updates from apache.snapshots
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'41e8402b5b2bbecd9b89b2dd62ed903da669bd31'; remote = 'html
head
' - RETRYING
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'41e8402b5b2bbecd9b89b2dd62ed903da669bd31'; remote = 'html
head
' - IGNORING
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve dependencies for one or more projects in the reactor.
Reason: Unable to read local copy of metadata: Cannot read metadata from
'/srv/gump/public/workspace/mvnlocalrepo/shared/org/apache/taglibs/taglibs-standard-spec/1.2-SNAPSHOT/maven-metadata-apache.snapshots.xml':
end tag name /p must match start tag name br from line 6 (position: TEXT
seen ...a href=/home page/a.\n/p... @8:5)
org.apache.taglibs:taglibs-standard-spec:jar:1.2-SNAPSHOT
Path to dependency:
1) org.apache.taglibs:taglibs-standard-impl:bundle:1.2-SNAPSHOT
2) org.apache.taglibs:taglibs-standard-spec:jar:1.2-SNAPSHOT
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 2 seconds
[INFO] Finished at: Thu Feb 17 15:12:36 UTC 2011
[INFO] Final Memory: 22M/54M
[INFO]
[Tomcat Wiki] Update of DocumentInOtherLanguages by markt
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The DocumentInOtherLanguages page has been changed by markt. The comment on this change is: Remove http://tomcat.jaxmao.org/ - currently breaching ASF trademarks. Can be added back when they clean up their act. http://wiki.apache.org/tomcat/DocumentInOtherLanguages?action=diffrev1=6rev2=7 -- [[http://www.ossez.com/forumdisplay.php?fid=21 |OSS 计算技术 - Tomcat 社区]] Tomcat Social Group for Chinese - [[http://tomcat.jaxmao.org/|Tomcat 5.5 中文应用手册]] Chinese translation of Tomcat 5.5 document - - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Tomcat Wiki] Update of Tomcat 中文文档 by huyuchengus
On 17/02/2011 15:07, Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The Tomcat 中文文档 page has been changed by huyuchengus. http://wiki.apache.org/tomcat/Tomcat%20%E4%B8%AD%E6%96%87%E6%96%87%E6%A1%A3?action=diffrev1=2rev2=3 If the Google translation of this page is remotely accurate there are multiple factual errors on that page. I'll dig the author's e-mail out of the the wiki and ask them to fix it. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Apache Tomcat wiki pages
Hi, Thanks for your recent updates to: http://wiki.apache.org/tomcat/Tomcat%20%E4%B8%AD%E6%96%87%E6%96%87%E6%A1%A3 All changes to the wiki are reviewed by the Tomcat developer community and a number of factual errors were discovered in this page: Apache Tomcat is not a Jakarta sub-project and has not been for many years. Apache Tomcat is a top-level project of the ASF. Sun (now Oracle) has not contributed to the development of Tomcat for many years. Better not to mention any companies at all since all the Tomcat developers (and all the ASF committers) act as individuals, not representatives of their employers. Servlet 2.4 and JSP 2.0 are not the latest Servlet and JSP specifications. The latest version of Tomcat is Tomcat 7. Please correct these errors promptly. If the errors are not corrected the page will just be deleted. Kind regards, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1071671 - in /tomcat/trunk: java/org/apache/coyote/ajp/AjpAprProtocol.java webapps/docs/changelog.xml
Author: markt
Date: Thu Feb 17 16:08:08 2011
New Revision: 1071671
URL: http://svn.apache.org/viewvc?rev=1071671view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50780
Fix memory leak in APR implementation of AJP connector introduced by the
refactoring for bug 49884
Modified:
tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java?rev=1071671r1=1071670r2=1071671view=diff
==
--- tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java Thu Feb 17
16:08:08 2011
@@ -197,9 +197,6 @@ public class AjpAprProtocol extends Abst
connections.put(socket, processor);
socket.setAsync(true);
} else {
-if (state == SocketState.OPEN) {
-connections.put(socket, processor);
-}
recycledProcessors.offer(processor);
}
return state;
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1071671r1=1071670r2=1071671view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Thu Feb 17 16:08:08 2011
@@ -99,6 +99,14 @@
/fix
/changelog
/subsection
+ subsection name=Coyote
+changelog
+ fix
+bug50780/bug: Fix memory leak in APR implementation of AJP
+connector introduced by the refactoring for bug49884/bug. (markt)
+ /fix
+/changelog
+ /subsection
subsection name=Jasper
changelog
fix
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50780] AjpConnectionHandler keeps many connections causing memory leak
https://issues.apache.org/bugzilla/show_bug.cgi?id=50780 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Mark Thomas ma...@apache.org 2011-02-17 11:08:23 EST --- This has been fixed in trunk and will be included in 7.0.9 onwards. -- 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: r1071677 - in /tomcat/trunk/java/org/apache/catalina/tribes: group/AbsoluteOrder.java group/ExtendedRpcCallback.java group/RpcMessage.java membership/MemberImpl.java tipis/AbstractReplicat
Author: fhanik
Date: Thu Feb 17 16:23:44 2011
New Revision: 1071677
URL: http://svn.apache.org/viewvc?rev=1071677view=rev
Log:
Correctly use the readFully method. Add a utility method to sort absolute order
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/AbsoluteOrder.java
tomcat/trunk/java/org/apache/catalina/tribes/group/ExtendedRpcCallback.java
(props changed)
tomcat/trunk/java/org/apache/catalina/tribes/group/RpcMessage.java
tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java
tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
Modified: tomcat/trunk/java/org/apache/catalina/tribes/group/AbsoluteOrder.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/AbsoluteOrder.java?rev=1071677r1=1071676r2=1071677view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/group/AbsoluteOrder.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/group/AbsoluteOrder.java Thu
Feb 17 16:23:44 2011
@@ -19,6 +19,7 @@ package org.apache.catalina.tribes.group
import java.io.Serializable;
import java.util.Arrays;
import java.util.Comparator;
+import java.util.List;
import org.apache.catalina.tribes.Member;
@@ -53,10 +54,14 @@ public class AbsoluteOrder {
public static void absoluteOrder(Member[] members) {
-if ( members == null || members.length == 0 ) return;
+if ( members == null || members.length = 1 ) return;
Arrays.sort(members,comp);
}
+public static void absoluteOrder(ListMember members) {
+if ( members == null || members.size() = 1 ) return;
+java.util.Collections.sort(members, comp);
+}
public static class AbsoluteComparator implements ComparatorMember,
Serializable {
Propchange:
tomcat/trunk/java/org/apache/catalina/tribes/group/ExtendedRpcCallback.java
--
svn:eol-style = native
Modified: tomcat/trunk/java/org/apache/catalina/tribes/group/RpcMessage.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/RpcMessage.java?rev=1071677r1=1071676r2=1071677view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/group/RpcMessage.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/group/RpcMessage.java Thu Feb
17 16:23:44 2011
@@ -56,10 +56,10 @@ public class RpcMessage implements Exter
reply = in.readBoolean();
int length = in.readInt();
uuid = new byte[length];
-in.read(uuid, 0, length);
+in.readFully(uuid);
length = in.readInt();
rpcId = new byte[length];
-in.read(rpcId, 0, length);
+in.readFully(rpcId);
message = (Serializable)in.readObject();
}
@@ -100,10 +100,10 @@ public class RpcMessage implements Exter
reply = true;
int length = in.readInt();
uuid = new byte[length];
-in.read(uuid, 0, length);
+in.readFully(uuid);
length = in.readInt();
rpcId = new byte[length];
-in.read(rpcId, 0, length);
+in.readFully(rpcId);
}
@Override
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java?rev=1071677r1=1071676r2=1071677view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/membership/MemberImpl.java Thu
Feb 17 16:23:44 2011
@@ -622,7 +622,7 @@ public class MemberImpl implements Membe
public void readExternal(ObjectInput in) throws IOException,
ClassNotFoundException {
int length = in.readInt();
byte[] message = new byte[length];
-in.read(message);
+in.readFully(message);
getMember(message,this);
}
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java?rev=1071677r1=1071676r2=1071677view=diff
==
---
tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
(original)
+++
tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
Thu Feb 17 16:23:44 2011
@@ -1427,7 +1427,7 @@ public abstract class AbstractReplicated
Member[] members = new Member[nodecount];
for ( int i=0; imembers.length; i++ ) {
byte[] d = new
[Tomcat Wiki] Update of Tomcat 安装/使用 by huyuchengus
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The Tomcat 安装/使用 page has been changed by huyuchengus. http://wiki.apache.org/tomcat/Tomcat%20%E5%AE%89%E8%A3%85/%E4%BD%BF%E7%94%A8 -- New page: [[http://www.ossez.com/viewthread.php?tid=48fromuid=426|安装 Tomcat]] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of Tomcat 安装/使用 by huyuchengus
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The Tomcat 安装/使用 page has been changed by huyuchengus. http://wiki.apache.org/tomcat/Tomcat%20%E5%AE%89%E8%A3%85/%E4%BD%BF%E7%94%A8?action=diffrev1=1rev2=2 -- [[http://www.ossez.com/viewthread.php?tid=48fromuid=426|安装 Tomcat]] + [[http://www.ossez.com/viewthread.php?tid=4117fromuid=426|Linux 环境下安装 Tomcat]] + + [[http://www.ossez.com/viewthread.php?tid=792fromuid=426|Tomcat i18n 对 URL 进行 UTF-8 解码]] + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of huyuchengus by huyuchengus
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The huyuchengus page has been changed by huyuchengus. http://wiki.apache.org/tomcat/huyuchengus -- New page: ##language:en == YUCHENG HU == Email: MailTo(huyuchen...@gmail.com) == OSS 计算技术 == OSS 计算技术社区的资深作者。 CategoryHomepage - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of Category:OSS Tomcat by huyuchengus
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The Category:OSS Tomcat page has been changed by huyuchengus. http://wiki.apache.org/tomcat/Category%3AOSS%20Tomcat -- New page: OSS 计算技术社区提供的中文信息 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Connection draining when upload to large
On 2/17/2011 4:41 AM, Mark Thomas wrote: I'm not particularly comfortable with this. I'm having a hard time coming up with a use case where some requests are swallowed and some are not. I think I'd prefer a per Connector or per Context attribute. I need to read the right part of the HTTP spec though since the wording there is likely to influence my views. Of course, it's fun looking for request message in the spec, but if one reads these literally, a response always follows the request line, headers and message body as defined in those headers; 5 Request A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use. Request = Request-Line ; Section 5.1 *(( general-header; Section 4.5 | request-header ; Section 5.3 | entity-header ) CRLF) ; Section 7.1 CRLF [ message-body ] ; Section 4.3 6 Response After receiving and interpreting a request message, a server responds with an HTTP response message. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1071734 - in /tomcat/trunk/modules/jdbc-pool: ./ .classpath build.properties.default sign.sh
Author: fhanik
Date: Thu Feb 17 18:16:22 2011
New Revision: 1071734
URL: http://svn.apache.org/viewvc?rev=1071734view=rev
Log:
Update version numbers
Modified:
tomcat/trunk/modules/jdbc-pool/ (props changed)
tomcat/trunk/modules/jdbc-pool/.classpath
tomcat/trunk/modules/jdbc-pool/build.properties.default
tomcat/trunk/modules/jdbc-pool/sign.sh
Propchange: tomcat/trunk/modules/jdbc-pool/
--
--- svn:ignore (original)
+++ svn:ignore Thu Feb 17 18:16:22 2011
@@ -1,3 +1,11 @@
-build.properties
-includes
-output
+?xml version=1.0 encoding=UTF-8?
+classpath
+ classpathentry kind=src path=java/
+ classpathentry kind=src path=test/
+ classpathentry kind=con
path=org.eclipse.jdt.junit.JUNIT_CONTAINER/3/
+ classpathentry kind=var
path=TOMCAT_LIBS_BASE/tomcat7-deps/dbcp/tomcat-dbcp.jar
sourcepath=/TOMCAT_LIBS_BASE/tomcat6-deps/dbcp/src/java/
+ classpathentry kind=con
path=org.eclipse.jdt.launching.JRE_CONTAINER/
+ classpathentry kind=lib path=includes/h2/bin/h2-1.2.129.jar/
+ classpathentry combineaccessrules=false kind=src
path=/tomcat-trunk/
+ classpathentry kind=output path=bin/
+/classpath
Modified: tomcat/trunk/modules/jdbc-pool/.classpath
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/.classpath?rev=1071734r1=1071733r2=1071734view=diff
==
--- tomcat/trunk/modules/jdbc-pool/.classpath (original)
+++ tomcat/trunk/modules/jdbc-pool/.classpath Thu Feb 17 18:16:22 2011
@@ -5,7 +5,7 @@
classpathentry kind=con
path=org.eclipse.jdt.junit.JUNIT_CONTAINER/3/
classpathentry kind=var
path=TOMCAT_LIBS_BASE/tomcat7-deps/dbcp/tomcat-dbcp.jar
sourcepath=/TOMCAT_LIBS_BASE/tomcat6-deps/dbcp/src/java/
classpathentry kind=con
path=org.eclipse.jdt.launching.JRE_CONTAINER/
- classpathentry combineaccessrules=false kind=src
path=/tomcat-7.0.x/
classpathentry kind=lib path=includes/h2/bin/h2-1.2.129.jar/
+ classpathentry combineaccessrules=false kind=src
path=/tomcat-trunk/
classpathentry kind=output path=bin/
/classpath
Modified: tomcat/trunk/modules/jdbc-pool/build.properties.default
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/build.properties.default?rev=1071734r1=1071733r2=1071734view=diff
==
--- tomcat/trunk/modules/jdbc-pool/build.properties.default (original)
+++ tomcat/trunk/modules/jdbc-pool/build.properties.default Thu Feb 17 18:16:22
2011
@@ -26,9 +26,9 @@
# - Vesion Control Flags -
version.major=1
-version.minor=0
-version.build=9
-version.patch=4
+version.minor=1
+version.build=0
+version.patch=0
version.suffix=
# - Default Base Path for Dependent Packages -
@@ -80,7 +80,7 @@ dbcp.home=${base.path}/commons-dbcp-1.3
dbcp.jar=${dbcp.home}/commons-dbcp-1.3.jar
dbcp.loc=http://archive.apache.org/dist/commons/dbcp/binaries/commons-dbcp-1.3.zip
-tomcat.version=6.0.29
+tomcat.version=6.0.32
tomcat.home=${base.path}/apache-tomcat-${tomcat.version}
tomcat.dbcp.jar=${tomcat.home}/lib/tomcat-dbcp.jar
tomcat.juli.jar=${tomcat.home}/bin/tomcat-juli.jar
Modified: tomcat/trunk/modules/jdbc-pool/sign.sh
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/sign.sh?rev=1071734r1=1071733r2=1071734view=diff
==
--- tomcat/trunk/modules/jdbc-pool/sign.sh (original)
+++ tomcat/trunk/modules/jdbc-pool/sign.sh Thu Feb 17 18:16:22 2011
@@ -15,7 +15,7 @@
# See the License for the specific language governing permissions and
# limitations under the License.
-VERSION=v1.0.9.4
+VERSION=v1.1.0.0
for i in $(find output/release/$VERSION -name *.zip -o -name *.tar.gz); do
echo Signing $i
echo $1|gpg --passphrase-fd 0 -a -b $i
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50802] New: Deviation from servlet3 spec concerning resource lookup from META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=50802
Summary: Deviation from servlet3 spec concerning resource
lookup from META-INF/resources
Product: Tomcat 7
Version: 7.0.8
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: sander.sonaj...@gmail.com
Created an attachment (id=26675)
-- (https://issues.apache.org/bugzilla/attachment.cgi?id=26675)
test application to reproduce. extract, deploy the war, make a query to root
URL, see the system-out for evidence of standard-deviating behavior
Hi!
I'm writing you from ZeroTurnaround and we are currently building JRebel
integration with new containers aiming to implement the servlet3 standard. I've
stumbled on a bug in your implementation that is actually at the very core of
the servlet standard and thus quite important, and actually a major issue for
our integration.
Namely, i'm copy-pasting you a fragment of the reference javadoc of the
servlet3 spec for the method ServletContext#getResourcePaths():
= SPEC START =
For example, for a web application containing:
/welcome.html
/catalog/index.html
/catalog/products.html
/catalog/offers/books.html
/catalog/offers/music.html
/customer/login.jsp
/WEB-INF/web.xml
/WEB-INF/classes/com.acme.OrderServlet.class
/WEB-INF/lib/catalog.jar!/META-INF/resources/catalog/moreOffers/books.html
getResourcePaths(/) would return {/welcome.html, /catalog/, /customer/,
/WEB-INF/}, and getResourcePaths(/catalog/) would return
{/catalog/index.html, /catalog/products.html, /catalog/offers/,
/catalog/moreOffers/}.
= SPEC END =
Now run my test-application, you'll discover immediately that Tomcat doesn't
respect that standard. getResourcesPath(/catalog) would not return
/catalog/moreOffers if there were 2 embedded jars containing web-fragments.
And even more importantly, had there been a new folder coming solely from a
jar's META-INF/resources, this wouldn't get listed with getResourcePaths(/).
Please note that these are important issues! Many frameworks rely on various
scanning techniques for recursive resource lookup, and so forth.
I've tested this thing with Tomcat 7.0.6 and 7.0.8, problems are present with
both.
(Btw, we've received information about the same problems from users of latest
glassfish version as well.. i think they are just re-using this part of tomcat
and thus getting the same problems... not sure.)
Thanks a lot if you can have a look at this!
--
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: r1071735 - /tomcat/trunk/modules/jdbc-pool/
Author: fhanik Date: Thu Feb 17 18:22:23 2011 New Revision: 1071735 URL: http://svn.apache.org/viewvc?rev=1071735view=rev Log: ignore list Modified: tomcat/trunk/modules/jdbc-pool/ (props changed) Propchange: tomcat/trunk/modules/jdbc-pool/ -- --- svn:ignore (original) +++ svn:ignore Thu Feb 17 18:22:23 2011 @@ -1,11 +1 @@ -?xml version=1.0 encoding=UTF-8? -classpath - classpathentry kind=src path=java/ - classpathentry kind=src path=test/ - classpathentry kind=con path=org.eclipse.jdt.junit.JUNIT_CONTAINER/3/ - classpathentry kind=var path=TOMCAT_LIBS_BASE/tomcat7-deps/dbcp/tomcat-dbcp.jar sourcepath=/TOMCAT_LIBS_BASE/tomcat6-deps/dbcp/src/java/ - classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/ - classpathentry kind=lib path=includes/h2/bin/h2-1.2.129.jar/ - classpathentry combineaccessrules=false kind=src path=/tomcat-trunk/ - classpathentry kind=output path=bin/ -/classpath +.classpath - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50802] Deviation from servlet3 spec concerning resource lookup from META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=50802 --- Comment #1 from Sander Sõnajalg sander.sonaj...@gmail.com 2011-02-17 13:25:14 EST --- Mm, i forgot to mention: the static resource serving itself is working okay. If you make queries to URLs /webstart/test1.txt and /webstart/test2.txt they are okay. Only the getResourcePaths() implementation is faulty. I know I'm now violating the one-bug-per-report rule and you can just ignore this if that's important or whatever, but I've also noticed that when I map my servlet to the root URL in web.xml, all the requests (to WHATEVER urls) are being made against my servlet now, making the DefaultServlet never apply, and thus making my static resources unreachable. Just mentioning.. I haven't read the spec on this, but this behavior doesn't make too much sense for me. :) -- 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 50802] Deviation from servlet3 spec concerning resource lookup from META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=50802 --- Comment #2 from Mark Thomas ma...@apache.org 2011-02-17 13:28:23 EST --- (In reply to comment #1) I know I'm now violating the one-bug-per-report rule and you can just ignore this if that's important or whatever, but I've also noticed that when I map my servlet to the root URL in web.xml, all the requests (to WHATEVER urls) are being made against my servlet now, making the DefaultServlet never apply, and thus making my static resources unreachable. Just mentioning.. I haven't read the spec on this, but this behavior doesn't make too much sense for me. :) Yep. That is as per the spec. Please use the users mailing list if you have any further questions on this and keep this issue for the original problem. -- 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: svn commit: r1071735 - /tomcat/trunk/modules/jdbc-pool/
2011/2/17 fha...@apache.org: Author: fhanik Date: Thu Feb 17 18:22:23 2011 New Revision: 1071735 URL: http://svn.apache.org/viewvc?rev=1071735view=rev Log: ignore list Modified: tomcat/trunk/modules/jdbc-pool/ (props changed) Propchange: tomcat/trunk/modules/jdbc-pool/ -- --- svn:ignore (original) +++ svn:ignore Thu Feb 17 18:22:23 2011 +.classpath What about the following ones: (were removed by r1071734) ? -build.properties -includes -output Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50803] New: ServletException.getRootCause() does not return the LoginException thrown by a JAAS login module
https://issues.apache.org/bugzilla/show_bug.cgi?id=50803 Summary: ServletException.getRootCause() does not return the LoginException thrown by a JAAS login module Product: Tomcat 7 Version: 7.0.8 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Servlet JSP API AssignedTo: dev@tomcat.apache.org ReportedBy: varga.pat...@gmail.com The javadoc of ServletException.getRootCause() at http://download.oracle.com/javaee/6/api/javax/servlet/ServletException.html#getRootCause%28%29 states that this method should return the exception that caused this servlet exception. However, when using a JAAS login module, the ServletException thrown after an unsuccessful HttpServletRequest.login(String,String) call does not contain its (root) cause, and its getCause() and getRootCause() methods always return null. This makes it impossible to get a handle to the original LoginException thrown by the login module and to present the user the specific error message contained in the LoginException. -- 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: r1071757 - /tomcat/trunk/modules/jdbc-pool/
Author: fhanik Date: Thu Feb 17 19:42:05 2011 New Revision: 1071757 URL: http://svn.apache.org/viewvc?rev=1071757view=rev Log: Update ignore list with the full set Modified: tomcat/trunk/modules/jdbc-pool/ (props changed) Propchange: tomcat/trunk/modules/jdbc-pool/ -- --- svn:ignore (original) +++ svn:ignore Thu Feb 17 19:42:05 2011 @@ -1 +1,7 @@ +build.properties +includes +output +.settings .classpath +bin + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1071735 - /tomcat/trunk/modules/jdbc-pool/
On 02/17/2011 11:50 AM, Konstantin Kolinko wrote: -build.properties -includes -output done thanks - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50803] ServletException.getRootCause() does not return the LoginException thrown by a JAAS login module
https://issues.apache.org/bugzilla/show_bug.cgi?id=50803 --- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com 2011-02-17 14:55:09 EST --- What is stack trace of that exception? Where is it thrown from? -- 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 50804] New: tomcat6 webpage link to javadocs broken
https://issues.apache.org/bugzilla/show_bug.cgi?id=50804 Summary: tomcat6 webpage link to javadocs broken Product: Tomcat 6 Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Documentation AssignedTo: dev@tomcat.apache.org ReportedBy: blacklight...@aol.com Go to: http://tomcat.apache.org/tomcat-6.0-doc/index.html Scroll down to the link: Servlet API Javadocs - The Servlet 2.5 API Javadocs. In the HTML it points to http://java.sun.com/products/servlet/2.5/docs/servlet-2_5-mr2/index.html which oracle has so kindly made auto-redirect into http://www.oracle.com/technetwork/java/javaee/servlet/index.html which isn't the java servlet 2.5 api docs at all, and has no way to navigate to them. So... now our best options are: http://download.oracle.com/docs/cd/E17802_01/products/products/servlet/2.5/docs/servlet-2_5-mr2/ or http://download.oracle.com/javaee/5/api/javax/servlet/package-summary.html (because java ee 5 has the 2.5 servlet spec) -- 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: r1071774 - in /tomcat/trunk: java/org/apache/naming/resources/ webapps/docs/
Author: markt
Date: Thu Feb 17 20:38:49 2011
New Revision: 1071774
URL: http://svn.apache.org/viewvc?rev=1071774view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50802
Ensure that ServletContext.getResourcePaths() includes static resources
packaged in JAR files in its output.
Modified:
tomcat/trunk/java/org/apache/naming/resources/BaseDirContext.java
tomcat/trunk/java/org/apache/naming/resources/FileDirContext.java
tomcat/trunk/java/org/apache/naming/resources/VirtualDirContext.java
tomcat/trunk/java/org/apache/naming/resources/WARDirContext.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/naming/resources/BaseDirContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/naming/resources/BaseDirContext.java?rev=1071774r1=1071773r2=1071774view=diff
==
--- tomcat/trunk/java/org/apache/naming/resources/BaseDirContext.java (original)
+++ tomcat/trunk/java/org/apache/naming/resources/BaseDirContext.java Thu Feb
17 20:38:49 2011
@@ -47,6 +47,8 @@ import javax.naming.directory.SearchCont
import javax.naming.directory.SearchResult;
import org.apache.naming.NameParserImpl;
+import org.apache.naming.NamingContextBindingsEnumeration;
+import org.apache.naming.NamingEntry;
import org.apache.naming.StringManager;
/**
@@ -703,25 +705,28 @@ public abstract class BaseDirContext imp
}
// Next do a standard lookup
-NamingEnumerationBinding bindings = doListBindings(name);
+ListNamingEntry bindings = doListBindings(name);
-if (bindings != null)
-return bindings;
-
// Check the alternate locations
+ListNamingEntry altBindings = null;
+
for (DirContext altDirContext : altDirContexts) {
-if (altDirContext instanceof BaseDirContext)
-bindings = ((BaseDirContext) altDirContext).doListBindings(
+if (altDirContext instanceof BaseDirContext) {
+altBindings = ((BaseDirContext) altDirContext).doListBindings(
/META-INF/resources + name);
-else {
-try {
-bindings = altDirContext.listBindings(name);
-} catch (NamingException ne) {
-// Ignore
+}
+if (altBindings != null) {
+if (bindings == null) {
+bindings = altBindings;
+} else {
+bindings.addAll(altBindings);
}
}
-if (bindings != null)
-return bindings;
+}
+
+if (bindings != null) {
+return new NamingContextBindingsEnumeration(bindings.iterator(),
+this);
}
// Really not found
@@ -1590,7 +1595,7 @@ public abstract class BaseDirContext imp
protected abstract Object doLookup(String name);
-protected abstract NamingEnumerationBinding doListBindings(String name)
+protected abstract ListNamingEntry doListBindings(String name)
throws NamingException;
protected abstract String doGetRealPath(String name);
Modified: tomcat/trunk/java/org/apache/naming/resources/FileDirContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/naming/resources/FileDirContext.java?rev=1071774r1=1071773r2=1071774view=diff
==
--- tomcat/trunk/java/org/apache/naming/resources/FileDirContext.java (original)
+++ tomcat/trunk/java/org/apache/naming/resources/FileDirContext.java Thu Feb
17 20:38:49 2011
@@ -27,8 +27,8 @@ import java.util.ArrayList;
import java.util.Arrays;
import java.util.Date;
import java.util.Hashtable;
+import java.util.List;
-import javax.naming.Binding;
import javax.naming.NameAlreadyBoundException;
import javax.naming.NameClassPair;
import javax.naming.NameNotFoundException;
@@ -42,7 +42,6 @@ import javax.naming.directory.SearchCont
import javax.naming.directory.SearchResult;
import org.apache.catalina.util.RequestUtil;
-import org.apache.naming.NamingContextBindingsEnumeration;
import org.apache.naming.NamingContextEnumeration;
import org.apache.naming.NamingEntry;
@@ -318,7 +317,7 @@ public class FileDirContext extends Base
* @exception NamingException if a naming exception is encountered
*/
@Override
-protected NamingEnumerationBinding doListBindings(String name)
+protected ListNamingEntry doListBindings(String name)
throws NamingException {
File file = file(name);
@@ -326,8 +325,7 @@ public class FileDirContext extends Base
if (file == null)
return null;
-return new NamingContextBindingsEnumeration(list(file).iterator(),
-this);
+return list(file);
}
@@ -848,9 +846,9 @@ public
DO NOT REPLY [Bug 50802] Deviation from servlet3 spec concerning resource lookup from META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=50802 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Mark Thomas ma...@apache.org 2011-02-17 15:38:56 EST --- Thanks for the test case. This issue has been fixed in trunk and will be in 7.0.9 onwards. -- 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 50803] ServletException.getRootCause() does not return the LoginException thrown by a JAAS login module
https://issues.apache.org/bugzilla/show_bug.cgi?id=50803
--- Comment #2 from Patrik Varga varga.pat...@gmail.com 2011-02-17 15:39:03
EST ---
Created an attachment (id=26676)
-- (https://issues.apache.org/bugzilla/attachment.cgi?id=26676)
stack trace and output
See attached stack trace and output when called from a JSF backing bean test
method pvarga.test.LoginBacking.login() which basically looks like this:
public String login() {
HttpServletRequest request = (HttpServletRequest)
FacesContext.getCurrentInstance().getExternalContext().getRequest();
try {
request.login(this.username, this.password);
}
catch (ServletException se) {
System.out.println(getCause: + se.getCause());
System.out.println(getRootCause: + se.getRootCause());
System.out.println(getMessage: + se.getMessage());
System.out.println(getLocalizedMessage: + se.getLocalizedMessage());
System.out.println(stack trace:);
se.printStackTrace();
}
return null;
}
As you can see the LoginException is logged in JAASRealm.authenticate() but not
propagated into the ServletException.
--
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 50803] ServletException.getRootCause() does not return the LoginException thrown by a JAAS login module
https://issues.apache.org/bugzilla/show_bug.cgi?id=50803 --- Comment #3 from Konstantin Kolinko knst.koli...@gmail.com 2011-02-17 16:07:16 EST --- stack trace: javax.servlet.ServletException: Login failed at org.apache.catalina.authenticator.AuthenticatorBase.doLogin(AuthenticatorBase.java:796) at org.apache.catalina.authenticator.AuthenticatorBase.login(AuthenticatorBase.java:785) at org.apache.catalina.connector.Request.login(Request.java:2508) at org.apache.catalina.connector.RequestFacade.login(RequestFacade.java:1066) Looking at AuthenticatorBase.java:796, the authenticator calls context.getRealm().authenticate(username, password) and that method reports unsuccessful authentication by returning null and not by throwing some exception. This cannot be solved unless interface of Realm is changed, e.g. by allowing either null or an exception to be returned. -- 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 50803] ServletException.getRootCause() does not return the LoginException thrown by a JAAS login module
https://issues.apache.org/bugzilla/show_bug.cgi?id=50803 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #4 from Mark Thomas ma...@apache.org 2011-02-17 17:09:25 EST --- The Realm interface will not be changed for security reasons. The reason for a login failure should not be propagated to the user. If it were, that would be a security vulnerability of a similar nature to CVE-2009-0580. -- 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: r1071830 - in /tomcat/tc6.0.x/trunk/webapps/docs: changelog.xml index.xml
Author: markt Date: Thu Feb 17 23:08:43 2011 New Revision: 1071830 URL: http://svn.apache.org/viewvc?rev=1071830view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50804 Update Servlet 2.5 and JSP 2.1 Javadoc links Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml tomcat/tc6.0.x/trunk/webapps/docs/index.xml Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=1071830r1=1071829r2=1071830view=diff == --- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Thu Feb 17 23:08:43 2011 @@ -57,6 +57,14 @@ /fix /changelog /subsection + subsection name=Webapps +changelog + fix +bug50804/bug: Update links for Servlet 2.5 and JSP 2.1 Javadoc. +(markt) + /fix +/changelog + /subsection /section section name=Tomcat 6.0.32 (jfclere) rtext=released 2011-02-03 subsection name=Catalina Modified: tomcat/tc6.0.x/trunk/webapps/docs/index.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/index.xml?rev=1071830r1=1071829r2=1071830view=diff == --- tomcat/tc6.0.x/trunk/webapps/docs/index.xml (original) +++ tomcat/tc6.0.x/trunk/webapps/docs/index.xml Thu Feb 17 23:08:43 2011 @@ -149,9 +149,9 @@ are responsible for installing, configur - Complete documentation and HOWTOs on the JK native webserver connector, used to interface Apache Tomcat with servers like Apache HTTPd, IIS and others./li -lia href=http://java.sun.com/products/servlet/2.5/docs/servlet-2_5-mr2/index.html; +lia href=http://download.oracle.com/docs/cd/E17802_01/products/products/servlet/2.5/docs/servlet-2_5-mr2/; strongServlet API Javadocs/strong/a - The Servlet 2.5 API Javadocs./li -lia href=http://java.sun.com/products/jsp/2.1/docs/jsp-2_1-pfd2/index.html; +lia href=http://download.oracle.com/docs/cd/E17802_01/products/products/jsp/2.1/docs/jsp-2_1-pfd2/index.html; strongJSP API Javadocs/strong/a - The JSP 2.1 API Javadocs./li /ul - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50804] tomcat6 webpage link to javadocs broken
https://issues.apache.org/bugzilla/show_bug.cgi?id=50804 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mark Thomas ma...@apache.org 2011-02-17 18:08:59 EST --- Fixed in 6.0.x and will be in 6.0.3 onwards. Thanks for the report and the suggested links. -- 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 50775] JNDIRealm fails with ServiceUnavailableException and NotContextException
https://issues.apache.org/bugzilla/show_bug.cgi?id=50775 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Mark Thomas ma...@apache.org 2011-02-17 18:57:30 EST --- It looks like the connection is timing out but the attempt to reconnect is failing. The NotContextException is really odd. That it works on Windows and AIX but not Linux points to a JVM bug, rather than a Tomcat issue. It might be possible to figure out a work around with more information although the Tomcat developers generally don't like putting workarounds for JVM bugs, OS bugs etc into the Tomcat codebase. Ideally, a reproducible test case is required. In these circumstances that looks unlikely. The best way forward would be to use the users list to help you debug. Personally, I'd run a Tomcat instance configured to allow remote debugging (suitably secured) and when the error starts happening debug my way through the Tomcat and JVM code to see if I could figure out what the problem was. I'd also have a working instance to hand so I could compare the two. -- 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 50737] Error on .war deploy - archive malformed (on recent Tomcat releases) on IBM iSeries System i
https://issues.apache.org/bugzilla/show_bug.cgi?id=50737 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #5 from Mark Thomas ma...@apache.org 2011-02-17 19:04:58 EST --- That looks like a JVM bug. The canonical path should be be using the 'real' (lower case in your case) path. -- 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 50805] New: Leak Performance issue of getConnectionAsync()
https://issues.apache.org/bugzilla/show_bug.cgi?id=50805
Summary: Leak Performance issue of getConnectionAsync()
Product: Tomcat Modules
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: jdbc-pool
AssignedTo: dev@tomcat.apache.org
ReportedBy: mashm...@gmail.com
Created an attachment (id=26677)
-- (https://issues.apache.org/bugzilla/attachment.cgi?id=26677)
patch for ConnectionPool
Leak and performance issue occurs when using getConnectionAsync().
getConnectionAsync() calls borrowConnection(int, String, String), and add
PooledConnection to the busy queue.
future.get() also calls borrowConnection(long, PooledConnection, String,
String), and same PooledConnection is added to the busy queue again.
The first connection is removed from the busy queue when returnConnection() is
called, but the second one remains as garbage.
The busy queue overflows at once because of these garbage connection.
Int this time, ConnectionPool.size is smaller than busy queue size. And new
real connection is created when getConnectionAsync() is called.
And, when the busy queue overflows, the connection is released in
ConnectionPool.returnConnection(). This causes the problem of the performance.
---
Furthermore, in most case the following codes are not executed, because
borrowConnection(int, String, String) is not returned null except as validation
failed.
149 if (idle instanceof FairBlockingQueue?) {
150 FuturePooledConnection pcf =
((FairBlockingQueuePooledConnection)idle).pollAsync();
151 return new ConnectionFuture(pcf);
152 } else if (idle instanceof MultiLockFairBlockingQueue?) {
153 FuturePooledConnection pcf =
((MultiLockFairBlockingQueuePooledConnection)idle).pollAsync();
154 return new ConnectionFuture(pcf);
155 } else {
156 throw new SQLException(Connection pool is misconfigured,
doesn't support async retrieval. Set the 'fair' property to 'true');
157 }
-
Based on above, I improved the getConnectionAsync().
Best regards.
--
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
