svn commit: r1345846 - in /tomcat/trunk/java/org/apache: catalina/deploy/NamingResources.java tomcat/util/net/AbstractEndpoint.java
Author: kkolinko
Date: Mon Jun 4 07:24:02 2012
New Revision: 1345846
URL: http://svn.apache.org/viewvc?rev=1345846&view=rev
Log:
Code formatting (indents). No functional change.
Modified:
tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java
tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
Modified: tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java?rev=1345846&r1=1345845&r2=1345846&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java (original)
+++ tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java Mon Jun
4 07:24:02 2012
@@ -401,7 +401,8 @@ public class NamingResources extends Lif
throw new IllegalArgumentException(sm.getString(
"namingResources.resourceTypeFail", resource.getName(),
resource.getType()));
-}entries.add(resource.getName());
+}
+entries.add(resource.getName());
}
synchronized (resourceEnvRefs) {
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java?rev=1345846&r1=1345845&r2=1345846&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java Mon Jun
4 07:24:02 2012
@@ -163,10 +163,11 @@ public abstract class AbstractEndpoint {
LimitLatch latch = this.connectionLimitLatch;
if (latch != null) {
// Update the latch that enforces this
-if (maxCon == -1)
+if (maxCon == -1) {
releaseConnectionLatch();
-else
-latch.setLimit(maxCon);
+} else {
+latch.setLimit(maxCon);
+}
} else if (maxCon > 0) {
initializeConnectionLatch();
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1345848 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/deploy/NamingResources.java java/org/apache/tomcat/util/net/AbstractEndpoint.java
Author: kkolinko
Date: Mon Jun 4 07:27:46 2012
New Revision: 1345848
URL: http://svn.apache.org/viewvc?rev=1345848&view=rev
Log:
Merged revision 1345846 from tomcat/trunk:
Code formatting (indents). No functional change.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1345846
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java?rev=1345848&r1=1345847&r2=1345848&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
Mon Jun 4 07:27:46 2012
@@ -400,7 +400,8 @@ public class NamingResources extends Lif
throw new IllegalArgumentException(sm.getString(
"namingResources.resourceTypeFail", resource.getName(),
resource.getType()));
-}entries.add(resource.getName());
+}
+entries.add(resource.getName());
}
synchronized (resourceEnvRefs) {
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java?rev=1345848&r1=1345847&r2=1345848&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
Mon Jun 4 07:27:46 2012
@@ -163,10 +163,11 @@ public abstract class AbstractEndpoint {
LimitLatch latch = this.connectionLimitLatch;
if (latch != null) {
// Update the latch that enforces this
-if (maxCon == -1)
+if (maxCon == -1) {
releaseConnectionLatch();
-else
-latch.setLimit(maxCon);
+} else {
+latch.setLimit(maxCon);
+}
} else if (maxCon > 0) {
initializeConnectionLatch();
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 38774] try using keyStorePassword property if set
https://issues.apache.org/bugzilla/show_bug.cgi?id=38774 --- Comment #4 from Konstantin Kolinko --- (In reply to comment #3) If you do care, you should open a new bug report and provide enough details to reproduce the issue. Commenting on a 6-year old issue is wrong. A lot has changed. Do not forget to mention the exact Tomcat version. Your comment does not match current Tomcat code, so I make no sense out of it. -- 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: r1335700 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/catalina/startup/ webapps/docs/
On 04/06/2012 07:55, Konstantin Kolinko wrote:
> 2012/5/8 :
>> Author: markt
>> Date: Tue May 8 19:07:09 2012
>> New Revision: 1335700
>>
>> URL: http://svn.apache.org/viewvc?rev=1335700&view=rev
>> Log:
>> It appears that pausing requests for a Context during reload was relying on
>> the mapper not being cleaned up correctly. The Lifecycle refactoring cleaned
>> up the mapper registrations and broke the handling of paused requests. This
>> commit restores that functionality and extends it. The key changes are:
>> - Contexts are no longer from the mapper if they are stopped while they are
>> paused
>> - The CoyoteAdapter pauses for 1s if a request is mapped to a paused Context
>> and then tries to re-map it. This replaces the reloading handling in the
>> StandardContextValve
>> - The reload handling has been removed from the StandardContextValve
>> - Editing a watched resource now triggers a reload (that pauses requests
>> received during the reload) rather than a stop/start which will return 404s
>> for requests received while the context is stopping and starting
>>
>> As with previous iterations of this feature it is impossible to completely
>> eliminate the chances of a 404 without a fair amount of locking that would
>> slow things down unnecessarily in production.
>>
>> Modified:
>>tomcat/tc7.0.x/trunk/ (props changed)
>>tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
>>
>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/MapperListener.java
>>tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
>>
>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContextValve.java
>>tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/HostConfig.java
>>tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
>>
>> Propchange: tomcat/tc7.0.x/trunk/
>> --
>> Merged /tomcat/trunk:r1335692
>>
>
>> ---
>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
>> (original)
>> +++
>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
>> Tue May 8 19:07:09 2012
>> @@ -719,7 +719,19 @@ public class CoyoteAdapter implements Ad
>> }
>> }
>> }
>> -
>> +if (!mapRequired && request.getContext().getPaused()) {
>> +// Found a matching context but it is paused. Mapping data
>> will
>> +// be wrong since some Wrappers may not be registered at
>> this
>> +// point.
>> +try {
>> +Thread.sleep(1000);
>> +} catch (InterruptedException e) {
>> +// Should never happen
>> +}
>> +// Reset mapping
>> +request.getMappingData().recycle();
>> +mapRequired = true;
>
> I think it also needs "version = null"; here.
> The version variable is modified in the mapping loop.
I don't believe this is the case. The correct version has already been
identified and won't change on the next run through the loop. It is only
the wrapper mapping that might change (as during a pause old Wrappers
are unregistered and new Wrappers registered. By setting the version to
null you force the version to be re-identified and this is not
necessary. It just repeats what has already been done with the same result.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1344253 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/coyote/ajp/AjpAprProcessor.java webapps/docs/changelog.xml
On 04/06/2012 07:41, Konstantin Kolinko wrote:
> 2012/5/30 :
>> Author: markt
>> Date: Wed May 30 13:35:55 2012
>> New Revision: 1344253
>>
>> URL: http://svn.apache.org/viewvc?rev=1344253&view=rev
>> Log:
>> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53119
>> Make sure the buffer is cleared on any error to prevent any possible
>> overflow if it is written to again before the connection is closed.
>> I can't reproduce the error with the provided test case but based on code
>> inspection this should fix it.
>>
>> Modified:
>>tomcat/tc7.0.x/trunk/ (props changed)
>>tomcat/tc7.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
>>tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
>>
>> Propchange: tomcat/tc7.0.x/trunk/
>> --
>> Merged /tomcat/trunk:r1344250
>>
>> Modified:
>> tomcat/tc7.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
>> URL:
>> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java?rev=1344253&r1=1344252&r2=1344253&view=diff
>> ==
>> --- tomcat/tc7.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
>> (original)
>> +++ tomcat/tc7.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java Wed
>> May 30 13:35:55 2012
>> @@ -288,6 +288,9 @@ public class AjpAprProcessor extends Abs
>>
>> if (outputBuffer.position() > 0) {
>> if ((socketRef != 0) && Socket.sendbb(socketRef, 0,
>> outputBuffer.position()) < 0) {
>> +// There are no re-tries so clear the buffer to prevent a
>> +// possible overflow if the buffer is used again. BZ53119.
>> +outputBuffer.clear();
>> throw new
>> IOException(sm.getString("ajpprocessor.failedsend"));
>> }
>> outputBuffer.clear();
>>
>
> Looks good. Backport to 6.0?
I haven't looked at the 6.0.x code to see if the exact same code path is
possible but a back port wouldn't do any harm in this case and is
probably quicker than working out if the issue can occur.
> AjpNioProcessor#output(byte[], int, int) seems to have the same issue.
I'm not sure. The OP that saw the error with APR/native could not
recreate it with NIO or BIO. That said, looking at the code there are
certainly a few ways the write buffer can't be cleared. The worst case
is an error message in the logs so I a not too concerned at this point.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1335700 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/catalina/startup/ webapps/docs/
2012/6/4 Mark Thomas :
> On 04/06/2012 07:55, Konstantin Kolinko wrote:
>> 2012/5/8 :
>>> Author: markt
>>> Date: Tue May 8 19:07:09 2012
>>> New Revision: 1335700
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1335700&view=rev
>>> Log:
>>> It appears that pausing requests for a Context during reload was relying on
>>> the mapper not being cleaned up correctly. The Lifecycle refactoring
>>> cleaned up the mapper registrations and broke the handling of paused
>>> requests. This commit restores that functionality and extends it. The key
>>> changes are:
>>> - Contexts are no longer from the mapper if they are stopped while they are
>>> paused
>>> - The CoyoteAdapter pauses for 1s if a request is mapped to a paused
>>> Context and then tries to re-map it. This replaces the reloading handling
>>> in the StandardContextValve
>>> - The reload handling has been removed from the StandardContextValve
>>> - Editing a watched resource now triggers a reload (that pauses requests
>>> received during the reload) rather than a stop/start which will return 404s
>>> for requests received while the context is stopping and starting
>>>
>>> As with previous iterations of this feature it is impossible to completely
>>> eliminate the chances of a 404 without a fair amount of locking that would
>>> slow things down unnecessarily in production.
>>>
>>> Modified:
>>> tomcat/tc7.0.x/trunk/ (props changed)
>>>
>>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
>>>
>>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/MapperListener.java
>>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
>>>
>>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContextValve.java
>>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/HostConfig.java
>>> tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
>>>
>>> Propchange: tomcat/tc7.0.x/trunk/
>>> --
>>> Merged /tomcat/trunk:r1335692
>>>
>>
>>> ---
>>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
>>> (original)
>>> +++
>>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
>>> Tue May 8 19:07:09 2012
>>> @@ -719,7 +719,19 @@ public class CoyoteAdapter implements Ad
>>> }
>>> }
>>> }
>>> -
>>> + if (!mapRequired && request.getContext().getPaused()) {
>>> + // Found a matching context but it is paused. Mapping data
>>> will
>>> + // be wrong since some Wrappers may not be registered at
>>> this
>>> + // point.
>>> + try {
>>> + Thread.sleep(1000);
>>> + } catch (InterruptedException e) {
>>> + // Should never happen
>>> + }
>>> + // Reset mapping
>>> + request.getMappingData().recycle();
>>> + mapRequired = true;
>>
>> I think it also needs "version = null"; here.
>> The version variable is modified in the mapping loop.
>
> I don't believe this is the case. The correct version has already been
> identified and won't change on the next run through the loop. It is only
> the wrapper mapping that might change (as during a pause old Wrappers
> are unregistered and new Wrappers registered. By setting the version to
> null you force the version to be re-identified and this is not
> necessary. It just repeats what has already been done with the same result.
OK.
(I was wondering that you are clearing mappingData there but are not
restarting from scratch. Looking closely, version mapping already does
exactly the same, (version = ctxt.getWebappVersion(); followed by
clearing the mapping).
Maybe something can change during the wait and complete remapping will
be needed. The wait of 1s is short, but the actual wait might be
longer, because there is no upper limit on the count of iterations of
that loop.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 52723] An incomplete fix for the resource leak bugs in StandardManager.java
https://issues.apache.org/bugzilla/show_bug.cgi?id=52723 --- Comment #5 from liangg...@sei.pku.edu.cn --- Hi, Konstantin, can you explain more about your new comment (Comment 4)? Does the BufferedOutputStream temp object need to be closed in this code piece? -- 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
[GUMP@vmgump]: Project tomcat-tc7.0.x-test (in module tomcat-7.0.x) 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-tc7.0.x-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-tc7.0.x-test : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property tomcat-dbcp-src.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-tc7.0.x-dbcp 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-7.0.x/output/build/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-test.html Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-test (Type: Build) Work ended in a state of : Failed Elapsed: 22 mins 40 secs Command Line: /usr/lib/jvm/java-6-openjdk/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-04062012.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-04062012-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-04062012-native-src.tar.gz -Dexamples.sources.skip=true -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-7.0.x/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-04062012.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-src.jar -Dtest.accesslog=true -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x -Dcommons-dbcp.home=/ srv/gump/public/workspace/commons-dbcp-1.x -Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-04062012.jar test [Working Directory: /srv/gump/public/workspace/tomcat-7.0.x] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-7.0.x/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-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-7.0.x/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/servlet-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/outp ut/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-util.jar:/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-04062012.jar:/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-04062012.jar:/srv/gump/ public/workspace/junit/dist/junit-04062012.jar - [junit] at org.junit.internal.runners.statements.InvokeMetho
[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 14 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 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 tomcat-trunk-dbcp exists, no need to add for property tomcat-dbcp-src.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-dbcp 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: 22 mins 30 secs Command Line: /usr/lib/jvm/java-6-openjdk/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-04062012.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-04062012-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-04062012-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-04062012.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-src.jar -Dtest.accesslog=true -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x -Dcommons-dbcp.home=/ srv/gump/public/workspace/commons-dbcp-1.x -Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-04062012.jar test [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-6-openjdk/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-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/servlet-api.jar:/srv/gump/public/workspace/tomcat-trunk/outp ut/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/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.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-trunk/output/build/lib/tomcat-util.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/packages/eclipse/plugins/org .eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-04062012.jar:/srv/gump/public/workspac
RE: svn commit: r1345848 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/deploy/NamingResources.java java/org/apache/tomcat/util/net/AbstractEndpoint.java
Ok, this is back to code discipline. At some point, we'd have to expect that
more users will adopt v7 in production (I'm still seeing 80%+ being on v6), at
that point, commits like this do nothing except pollute the diffs.
Servlet 3.1 has released a draft, where I'd expect that trunk is headed. There
is no reason for v7 to continue to be an exact mirror of trunk, especially from
a formatting point of view.
While this makes the code prettier, it makes it a lot harder to trace
regressions.
I'd suggest we start treating this as a stable branch, stable in my perception
is that it's a branch that I use to support production environments, and that I
can use to trace regressions and fixes.
Let me give an example, in my job, I primarily work in support. In the last two
weeks we've had some serious production regressions on v7, and tracing it down
was a lot harder than it usually is as the v7 branch still is fairly volatile
in development, even though we're already at 7.0.27.
A commit that doesn't change functionality but changes formatting, adds more
lines to each diff I review when I trace back changes.
I would assume that the tomcat dev community in some shape or form must feel
the same sense of "supporting" our users when we look through the user
community's bug reports, and trace down the bugs.
For that reason, I'd like us to be more conscious about our commits on v7 and
start looking at v7 as bug fixes and stabilization as the primary drivers for
commits. Beautification of code in v7 doesn't make fixing it later easier, it
makes it harder. And beautification's primary goal is simpler to read, use and
maintain. But it only works if the original code was that way.
If we want to make code formatting a 'requirement', let's discuss that, and
adjust the build scripts accordingly. Now it's a manual process. I'd suggest
that formatting requirements would be started on a new thread, and started with
trunk.
Best
Filip
> -Original Message-
> From: kkoli...@apache.org [mailto:kkoli...@apache.org]
> Sent: Monday, June 04, 2012 1:28 AM
> To: dev@tomcat.apache.org
> Subject: svn commit: r1345848 - in /tomcat/tc7.0.x/trunk: ./
> java/org/apache/catalina/deploy/NamingResources.java
> java/org/apache/tomcat/util/net/AbstractEndpoint.java
>
> Author: kkolinko
> Date: Mon Jun 4 07:27:46 2012
> New Revision: 1345848
>
> URL: http://svn.apache.org/viewvc?rev=1345848&view=rev
> Log:
> Merged revision 1345846 from tomcat/trunk:
> Code formatting (indents). No functional change.
>
> Modified:
> tomcat/tc7.0.x/trunk/ (props changed)
>
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.jav
> a
>
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.ja
> va
>
> Propchange: tomcat/tc7.0.x/trunk/
>
> --
> Merged /tomcat/trunk:r1345846
>
> Modified:
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.jav
> a
> URL:
> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catali
> na/deploy/NamingResources.java?rev=1345848&r1=1345847&r2=1345848&view=di
> ff
>
> ==
> ---
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.jav
> a (original)
> +++
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.jav
> a Mon Jun 4 07:27:46 2012
> @@ -400,7 +400,8 @@ public class NamingResources extends Lif
> throw new IllegalArgumentException(sm.getString(
> "namingResources.resourceTypeFail",
> resource.getName(),
> resource.getType()));
> -}entries.add(resource.getName());
> +}
> +entries.add(resource.getName());
> }
>
> synchronized (resourceEnvRefs) {
>
> Modified:
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.ja
> va
> URL:
> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat
> /util/net/AbstractEndpoint.java?rev=1345848&r1=1345847&r2=1345848&view=d
> iff
>
> ==
> ---
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.ja
> va (original)
> +++
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.ja
> va Mon Jun 4 07:27:46 2012
> @@ -163,10 +163,11 @@ public abstract class AbstractEndpoint {
> LimitLatch latch = this.connectionLimitLatch;
> if (latch != null) {
> // Update the latch that enforces this
> -if (maxCon == -1)
> +if (maxCon == -1) {
> releaseConnectionLatch();
> -else
> -latch.setLimit(maxCon);
> +} else {
> +latch.setLimit(maxCon);
> +}
> } else if (maxCon > 0) {
> initializeCo
Re: svn commit: r1345848 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/deploy/NamingResources.java java/org/apache/tomcat/util/net/AbstractEndpoint.java
On 04/06/2012 17:05, Filip Hanik (mailing lists) wrote: > > Ok, this is back to code discipline. At some point, we'd have to > expect that more users will adopt v7 in production (I'm still seeing > 80%+ being on v6), at that point, commits like this do nothing except > pollute the diffs. It depends which diffs you are looking at. If you are checking trunk against 7.0.x to check that the back-port of a fix hasn't been missed then having trunk and 7.0.x as closely aligned as possible is helpful. If you are checking the changes in 7.0.x then formatting changes don't help. It all depends on your point of view. I would also add that consistently formatted code is easier to read and less likely to be misread. > Servlet 3.1 has released a draft, where I'd expect that trunk is > headed. There is no reason for v7 to continue to be an exact mirror > of trunk, especially from a formatting point of view. That work hasn't started in Tomcat yet so at the moment there is no driver for them to diverge. That will probably change over the next few months. > While this makes the code prettier, it makes it a lot harder to trace > regressions. Not just prettier (see above) but I agree regarding regressions. > I'd suggest we start treating this as a stable branch, stable in my > perception is that it's a branch that I use to support production > environments, and that I can use to trace regressions and fixes. The obvious change would be to move 7.0.x to RTC rather than CTR. That inevitably slows down the pace of development. We as a community need to decide if that is what we want to do. If you want to propose that, I suggest you start a new thread on that specific topic. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Created] (MTOMCAT-159) WAR dependencies extracted every run
Robert Hollencamp created MTOMCAT-159: - Summary: WAR dependencies extracted every run Key: MTOMCAT-159 URL: https://issues.apache.org/jira/browse/MTOMCAT-159 Project: Apache Tomcat Maven Plugin Issue Type: Improvement Components: commons-lib Affects Versions: 2.0 Reporter: Robert Hollencamp Assignee: Olivier Lamy (*$^¨%`£) Priority: Minor If there is a WAR dependency, it is extracted to target/apache-tomcat-maven-plugin/ARTIFACT_NAME. This directory is deleted and re-created every invocation of the plugin, meaning that all WAR dependencies are re-extracted every run. Do not delete these extracted directories. Instead check the last modified timestamp of the directory against the last modified timestamp of the WAR dependency, and re-extract only if the WAR is newer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Updated] (MTOMCAT-159) WAR dependencies extracted every run
[ https://issues.apache.org/jira/browse/MTOMCAT-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Hollencamp updated MTOMCAT-159: -- Attachment: MTOMCAT-159-1.diff implementation > WAR dependencies extracted every run > > > Key: MTOMCAT-159 > URL: https://issues.apache.org/jira/browse/MTOMCAT-159 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement > Components: commons-lib >Affects Versions: 2.0 >Reporter: Robert Hollencamp >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > Attachments: MTOMCAT-159-1.diff > > > If there is a WAR dependency, it is extracted to > target/apache-tomcat-maven-plugin/ARTIFACT_NAME. This directory is deleted > and re-created every invocation of the plugin, meaning that all WAR > dependencies are re-extracted every run. > Do not delete these extracted directories. Instead check the last modified > timestamp of the directory against the last modified timestamp of the WAR > dependency, and re-extract only if the WAR is newer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53356] New: Mapping a servlet to the application's context root results in IAE
https://issues.apache.org/bugzilla/show_bug.cgi?id=53356
Priority: P2
Bug ID: 53356
Assignee: dev@tomcat.apache.org
Summary: Mapping a servlet to the application's context root
results in IAE
Severity: normal
Classification: Unclassified
OS: All
Reporter: violet...@apache.org
Hardware: All
Status: NEW
Version: 7.0.27
Component: Catalina
Product: Tomcat 7
Created attachment 28881
--> https://issues.apache.org/bugzilla/attachment.cgi?id=28881&action=edit
test web app
Hi,
I have an application and I want to map my servlet to the application's context
root, but I do not want to override the "/" mapping for the "default" servlet.
It is specified in the Servlet spec that there is a "special" url mapping that
can be used for such purposes and it is an empty string ("").
I tried several approaches to specify this via web.xml and annotation,
unfortunately all of them results in IAE:
Caused by: java.lang.IllegalArgumentException: Invalid in
servlet mapping
at
org.apache.catalina.core.StandardContext.addServletMapping(StandardContext.java:3208)
at
org.apache.catalina.core.StandardContext.addServletMapping(StandardContext.java:3183)
at org.apache.catalina.deploy.WebXml.configureContext(WebXml.java:1302)
at
org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1305)
at
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:855)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:346)
The issue was started as mail thread in the users list -
http://marc.info/?t=13388347063&r=1&w=2
Can you please provide this feature?
Thanks in advance
Regards
Violeta
PP: test application is attached.
--
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: r1345848 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/deploy/NamingResources.java java/org/apache/tomcat/util/net/AbstractEndpoint.java
> -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Monday, June 04, 2012 12:41 PM > To: Tomcat Developers List > Subject: Re: svn commit: r1345848 - in /tomcat/tc7.0.x/trunk: ./ > java/org/apache/catalina/deploy/NamingResources.java > java/org/apache/tomcat/util/net/AbstractEndpoint.java > > On 04/06/2012 17:05, Filip Hanik (mailing lists) wrote: > > > > Ok, this is back to code discipline. At some point, we'd have to > > expect that more users will adopt v7 in production (I'm still seeing > > 80%+ being on v6), at that point, commits like this do nothing except > > pollute the diffs. > > It depends which diffs you are looking at. If you are checking trunk > against 7.0.x to check that the back-port of a fix hasn't been missed > then having trunk and 7.0.x as closely aligned as possible is helpful. > If you are checking the changes in 7.0.x then formatting changes don't > help. It all depends on your point of view. I would also add that > consistently formatted code is easier to read and less likely to be > misread. [Filip Hanik] That's my point exactly. I believe we did a great job with stabilizing Apache Tomcat 6, and keeping it stable. I don't think we are doing as good of a job with Apache Tomcat 7. I think we can do better. So it's really what is the goal, if the goal to back port patches from trunk, then sure. Format both branches. That goal however has a flaw, it doesn't treat 7.0.x as a production grade branch, but a development branch. > > > Servlet 3.1 has released a draft, where I'd expect that trunk is > > headed. There is no reason for v7 to continue to be an exact mirror > > of trunk, especially from a formatting point of view. > > That work hasn't started in Tomcat yet so at the moment there is no > driver for them to diverge. That will probably change over the next few > months. [Filip Hanik] Should change fairly shortly since the draft is out. > > > While this makes the code prettier, it makes it a lot harder to trace > > regressions. > > Not just prettier (see above) but I agree regarding regressions. > > > I'd suggest we start treating this as a stable branch, stable in my > > perception is that it's a branch that I use to support production > > environments, and that I can use to trace regressions and fixes. > > The obvious change would be to move 7.0.x to RTC rather than CTR. That > inevitably slows down the pace of development. We as a community need to > decide if that is what we want to do. If you want to propose that, I > suggest you start a new thread on that specific topic. [Filip Hanik] Doesn't have to be one extreme to another. All it takes a bit more discipline and an aligned goal with the 7.0.x branch. Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1346107 - /tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java
Author: markt
Date: Mon Jun 4 19:38:00 2012
New Revision: 1346107
URL: http://svn.apache.org/viewvc?rev=1346107&view=rev
Log:
Rework fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=5
Modified:
tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java
Modified: tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java?rev=1346107&r1=1346106&r2=1346107&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java (original)
+++ tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java Mon Jun
4 19:38:00 2012
@@ -1143,24 +1143,20 @@ public class NamingResources extends Lif
}
}
-Class injectionClass = getInjectionTargetType(context, resource);
-if (injectionClass == null) {
+Class compatibleClass =
+getCompatibleType(context, resource, typeClass);
+if (compatibleClass == null) {
// Indicates that a compatible type could not be identified that
// worked for all injection targets
return false;
}
-if (typeClass == null) {
-// Only injectionTarget defined - use it
-resource.setType(injectionClass.getCanonicalName());
-return true;
-} else {
-return injectionClass.isAssignableFrom(typeClass);
-}
+resource.setType(compatibleClass.getCanonicalName());
+return true;
}
-private Class getInjectionTargetType(Context context,
-ResourceBase resource) {
+private Class getCompatibleType(Context context,
+ResourceBase resource, Class typeClass) {
Class result = null;
@@ -1186,17 +1182,28 @@ public class NamingResources extends Lif
}
targetType = convertPrimitiveType(targetType);
-// Figure out the common type - if there is one
-if (result == null) {
-result = targetType;
-} else if (targetType.isAssignableFrom(result)) {
-// NO-OP - This will work
-} else if (result.isAssignableFrom(targetType)) {
-// Need to use more specific type
-result = targetType;
+if (typeClass == null) {
+// Need to find a common type amongst the injection targets
+if (result == null) {
+result = targetType;
+} else if (targetType.isAssignableFrom(result)) {
+// NO-OP - This will work
+} else if (result.isAssignableFrom(targetType)) {
+// Need to use more specific type
+result = targetType;
+} else {
+// Incompatible types
+return null;
+}
} else {
-// Incompatible types
-return null;
+// Each injection target needs to be consistent with the
defined
+// type
+if (targetType.isAssignableFrom(typeClass)) {
+result = typeClass;
+} else {
+// Incompatible types
+return null;
+}
}
}
return result;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1346109 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/deploy/NamingResources.java
Author: markt
Date: Mon Jun 4 19:40:06 2012
New Revision: 1346109
URL: http://svn.apache.org/viewvc?rev=1346109&view=rev
Log:
Rework fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=5
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1346107
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java?rev=1346109&r1=1346108&r2=1346109&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
Mon Jun 4 19:40:06 2012
@@ -1153,24 +1153,20 @@ public class NamingResources extends Lif
}
}
-Class injectionClass = getInjectionTargetType(context, resource);
-if (injectionClass == null) {
+Class compatibleClass =
+getCompatibleType(context, resource, typeClass);
+if (compatibleClass == null) {
// Indicates that a compatible type could not be identified that
// worked for all injection targets
return false;
}
-if (typeClass == null) {
-// Only injectionTarget defined - use it
-resource.setType(injectionClass.getCanonicalName());
-return true;
-} else {
-return injectionClass.isAssignableFrom(typeClass);
-}
+resource.setType(compatibleClass.getCanonicalName());
+return true;
}
-private Class getInjectionTargetType(Context context,
-ResourceBase resource) {
+private Class getCompatibleType(Context context,
+ResourceBase resource, Class typeClass) {
Class result = null;
@@ -1196,17 +1192,28 @@ public class NamingResources extends Lif
}
targetType = convertPrimitiveType(targetType);
-// Figure out the common type - if there is one
-if (result == null) {
-result = targetType;
-} else if (targetType.isAssignableFrom(result)) {
-// NO-OP - This will work
-} else if (result.isAssignableFrom(targetType)) {
-// Need to use more specific type
-result = targetType;
+if (typeClass == null) {
+// Need to find a common type amongst the injection targets
+if (result == null) {
+result = targetType;
+} else if (targetType.isAssignableFrom(result)) {
+// NO-OP - This will work
+} else if (result.isAssignableFrom(targetType)) {
+// Need to use more specific type
+result = targetType;
+} else {
+// Incompatible types
+return null;
+}
} else {
-// Incompatible types
-return null;
+// Each injection target needs to be consistent with the
defined
+// type
+if (targetType.isAssignableFrom(typeClass)) {
+result = typeClass;
+} else {
+// Incompatible types
+return null;
+}
}
}
return result;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1345580 - in /tomcat/trunk/java/org/apache/catalina/deploy: LocalStrings.properties NamingResources.java
On 03/06/2012 23:58, Mark Thomas wrote: > Konstantin Kolinko wrote: >> Does something guarantee that there is always common type among >> injection targets? >> >> Can there be two disjoint interfaces A and B, which are both >> implemented by a resource, so assignment to A or B should succeed, >> but getInjectionTargetType() will result in a failure? > > Potentially, yes. That case needs to be handled too but in my view > only if a type is defined in web.xml. I don't think it is reasonable > to find a suitable type if injection targets define disparate > interfaces with no concrete type in web.xml. Fixed. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53337] IllegalStateException when trying to render a JSP after startAsync
https://issues.apache.org/bugzilla/show_bug.cgi?id=53337 --- Comment #7 from rstoyanc...@yahoo.com --- Thanks for the suggestions, Mark. In the discussion on the servlet-spec user list, even wider implications were mentioned including avoiding reliance on the requestURI or even the session from an async thread. It's quite a surprise that none of it is mentioned in the spec. -- 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 7 code policy (was: Re: svn commit: r1345848)
2012/6/4 Filip Hanik (mailing lists) :
>
> Ok, this is back to code discipline. At some point, we'd have to expect that
> more users will adopt v7 in production (I'm still seeing 80%+ being on v6),
> at that point, commits like this do nothing except pollute the diffs.
>
There were two fixes in r1345848:
1. Filip, I have nothing against your code style of missing '{' for a
simple statement after an if, but in this case it was worsened by the
fact that the "else" branch was not indented at all. It is rather
confusing.
That is why I had to fix it.
2. The same with NamingResources change.
Both changes are to facilitate further code review. Code formatting
can be different, but it should not be confusing. This commit was to
eliminate confusion, not to make it pretty.
If you approach to regressions is to review diffs (if I understand you
correctly), then mine is to review current code. Confusing code does
not help it.
Reviewing commits and fixing minor issues is normal practice. With 6.0
I usually address them in my vote, so the final commit is clearer, but
the overall change is the same. Your issue is not with code
formatting.
>
> Let me give an example, in my job, I primarily work in support. In the last
> two weeks we've had some serious production regressions on v7, and tracing it
> down was a lot harder than it usually is as the v7 branch still is fairly
> volatile in development, even though we're already at 7.0.27.
In my view, the only way to reliably prevent regressions is to write
more tests, and to test regularly in CI manner.
If it were possible to write an automated test for your issue (I do
not know how hard to reproduce the problem was), there exists such
tool as bisect ("svn-bisect") that allows you to locate "bad" revision
in several iterations.
> For that reason, I'd like us to be more conscious about our commits on v7 and
> start looking at v7 as bug fixes and stabilization as the primary drivers for
> commits.
Stabilization usually means that we stop fixing bugs in "stable"
version besides easy ones and allow them in trunk only. It is not what
I want for 7.0 now.
There is no expected date for Tomcat 8, and if the date is too far
(e.g. further than 9 months) it would be too late for most problems
that users are reporting.
As an example:
Should we abstain from porting "infinite timeouts support" to 7.0? It
seems a bit risky (I do not know connectors so good to review it
properly), but it is important for those experimenting with new web
socket api.
Should we postpone web sockets for a year (saying that current support
is broken, or is limited to some specific connector)?It will
prevent ones from testing and evaluating the feature, and we might
well lose a year- without proper testing of the feature.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in ASF Buildbot on tomcat-7-trunk
The Buildbot has detected a restored build on builder tomcat-7-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-7-trunk/builds/623 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1346109 Blamelist: markt Build succeeded! sincerely, -The Buildbot
[Bug 53356] Mapping a servlet to the application's context root results in IAE
https://issues.apache.org/bugzilla/show_bug.cgi?id=53356 --- Comment #1 from Mark Thomas --- Not fixed yet but as an aside you'll need to use not "" -- 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: Tomcat 7 code policy (was: Re: svn commit: r1345848)
2012/6/5 Konstantin Kolinko : >> >> For that reason, I'd like us to be more conscious about our commits on v7 >> and start looking at v7 as bug fixes and stabilization as the primary >> drivers for commits. > > Stabilization usually means that we stop fixing bugs in "stable" > version besides easy ones and allow them in trunk only. It is not what > I want for 7.0 now. > > There is no expected date for Tomcat 8, and if the date is too far > (e.g. further than 9 months) it would be too late for most problems > that users are reporting. > What do people think about introducing a STATUS file in 7.0, but not yet switching to full RTC policy? I mean let the author decide and propose his change for review if he deems it is too risky to commit immediately, or is worth reviewing. E.g. if a) the change is too complex, b) touches many components, c) touches core pieces of Tomcat. I do not think 7.0 will benefit from slow RTC of Tomcat 6, but there are some patches that are worth a review, and having a formal STATUS file approach is better that random discussions on dev@. One notable benefit of the STATUS file is that the change is proposed when it is ready for review. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1345580 - in /tomcat/trunk/java/org/apache/catalina/deploy: LocalStrings.properties NamingResources.java
2012/6/4 Mark Thomas : > On 03/06/2012 23:58, Mark Thomas wrote: > >> Konstantin Kolinko wrote: > >>> Does something guarantee that there is always common type among >>> injection targets? >>> >>> Can there be two disjoint interfaces A and B, which are both >>> implemented by a resource, so assignment to A or B should succeed, >>> but getInjectionTargetType() will result in a failure? >> >> Potentially, yes. That case needs to be handled too but in my view >> only if a type is defined in web.xml. I don't think it is reasonable >> to find a suitable type if injection targets define disparate >> interfaces with no concrete type in web.xml. > > Fixed. > Thanks. Looks good. Re: http://svn.apache.org/viewvc?rev=1346109&view=rev There are two things that are unusual to my taste, but they do not affect the outcome. Just noting. It is not an objection. 1) Behaviour of getCompatibleType(..) when resource.getInjectionTargets() is empty. It always returns null. This concern does not matter though - It is never called with empty getInjectionTargets() as that is checked before the call. 2) Assignment resource.setType(compatibleClass.getCanonicalName()); If typeClass != null it looks strange to change the value. This concern does not matter though - In that case the new value is the same as the old one. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 52723] An incomplete fix for the resource leak bugs in StandardManager.java
https://issues.apache.org/bugzilla/show_bug.cgi?id=52723 --- Comment #6 from Konstantin Kolinko --- (In reply to comment #5) 1. BufferedOutputStream does not deserve closing, because it is in memory only. No native resources are leaking. - ObjectOutputStream would never need to be closed. If an IOException happens oos will be null as assignment never happens. - The only one that really has to be closed is FileOutputStream. - The only situation when FileOutputStream is not-null and needs to be closed is when its constructor succeeded, but constructors of other streams failed. 2. The only one of other constructors that can (in theory) fail with IOException is ObjectOutputStream. It completes with IOException iff call to ObjectOutputStream#writeStreamHeader() throws an IOException. My Comment 4 was caused by this point "2.". Actually, looking further, the writeStreamHeader() method writes 4 bytes. As those 4 bytes are cached in BufferedOutputStream, an IOException cannot really happen there. So sorry for the noise. It is not worth for 6.0. -- 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 53359] New: Request for or as element inside
https://issues.apache.org/bugzilla/show_bug.cgi?id=53359 Priority: P2 Bug ID: 53359 Assignee: dev@tomcat.apache.org Summary: Request for or as element inside Severity: enhancement Classification: Unclassified Reporter: esmond.p...@bigpond.com Hardware: PC Status: NEW Version: 7.0.27 Component: Catalina Product: Tomcat 7 I have a large and growing number of requirements for aliases, and the existing (new for Tomcat 7) aliases= attribute is unwieldy for me. The line is already 289 characters long ;-( It would be a lot more convenient if aliases could be specified individually via a repeatable nested entry, something like: ... as opposed to current: -- 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: r1341370 - in /tomcat/tc7.0.x/trunk: java/org/apache/catalina/startup/ContextConfig.java webapps/docs/changelog.xml
2012/5/28 Keiichi Fujino : > Thanks for the review. > I fixed it. > > I implemented the calculation method of host's default config path to > Host(StanderdHost). > just like a Host#getAppBaseFile(). > This fix is applied only to trunk. > > If there is a different implementation idea, feel free to re-fix. > Re: r1343153, r1343155 Looks good. Thank you. Best regards, Konstantin Kolinko > 2012/5/25 Konstantin Kolinko : >> 2012/5/22 : >>> Author: kfujino >>> Date: Tue May 22 09:27:00 2012 >>> New Revision: 1341370 >>> >>> URL: http://svn.apache.org/viewvc?rev=1341370&view=rev >>> Log: >>> Enable host's xmlBase attribute in ContextConfig. >>> >>> Modified: >>> tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java >>> tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml >>> >>>(...) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-tc7.0.x-test (in module tomcat-7.0.x) 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-tc7.0.x-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-tc7.0.x-test : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property tomcat-dbcp-src.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-tc7.0.x-dbcp 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-7.0.x/output/build/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-test.html Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-test (Type: Build) Work ended in a state of : Failed Elapsed: 22 mins 42 secs Command Line: /usr/lib/jvm/java-6-openjdk/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-05062012.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-05062012-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-05062012-native-src.tar.gz -Dexamples.sources.skip=true -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-7.0.x/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-05062012.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-src.jar -Dtest.accesslog=true -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x -Dcommons-dbcp.home=/ srv/gump/public/workspace/commons-dbcp-1.x -Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-05062012.jar test [Working Directory: /srv/gump/public/workspace/tomcat-7.0.x] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-7.0.x/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-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-7.0.x/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/servlet-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/outp ut/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-util.jar:/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-05062012.jar:/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-05062012.jar:/srv/gump/ public/workspace/junit/dist/junit-05062012.jar - [junit] at org.junit.r
[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 15 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 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 tomcat-trunk-dbcp exists, no need to add for property tomcat-dbcp-src.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-dbcp 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: 22 mins 54 secs Command Line: /usr/lib/jvm/java-6-openjdk/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-05062012.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-05062012-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-05062012-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-05062012.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-src.jar -Dtest.accesslog=true -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x -Dcommons-dbcp.home=/ srv/gump/public/workspace/commons-dbcp-1.x -Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-05062012.jar test [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-6-openjdk/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-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/servlet-api.jar:/srv/gump/public/workspace/tomcat-trunk/outp ut/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/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.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-trunk/output/build/lib/tomcat-util.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/packages/eclipse/plugins/org .eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-05062012.jar:/srv/gump/public/workspac
