[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 85 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: 21 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] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[debug] execute contextualize
[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 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
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 14 resources
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 96 source files to
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/src/main/java/org/apache/taglibs/standard/tag/common/sql/DataSourceWrapper.java:[38,7]
error: DataSourceWrapper is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[INFO] 1 error
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/src/main/java/org/apache/taglibs/standard/tag/common/sql/DataSourceWrapper.java:[38,7]
error: DataSourceWrapper is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO] ---
svn commit: r1387937 - /tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
Author: markt
Date: Thu Sep 20 09:55:04 2012
New Revision: 1387937
URL: http://svn.apache.org/viewvc?rev=1387937&view=rev
Log:
Correct fix for BZ 53843 that triggered a TCK failure
Modified:
tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
Modified: tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java?rev=1387937&r1=1387936&r2=1387937&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java Thu Sep 20
09:55:04 2012
@@ -101,7 +101,7 @@ public class AsyncStateMachine {
DISPATCHED(false, false, false),
STARTING(true, true, false),
STARTED(true, true, false),
-MUST_COMPLETE(true, true, false),
+MUST_COMPLETE(true, false, false),
COMPLETING(true, false, false),
TIMING_OUT(true, false, false),
MUST_DISPATCH(true, true, true),
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1387938 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/coyote/AsyncStateMachine.java webapps/docs/changelog.xml
Author: markt
Date: Thu Sep 20 09:56:06 2012
New Revision: 1387938
URL: http://svn.apache.org/viewvc?rev=1387938&view=rev
Log:
Correct fix for BZ 53843 that triggered a TCK failure
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/coyote/AsyncStateMachine.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1387937
Modified: tomcat/tc7.0.x/trunk/java/org/apache/coyote/AsyncStateMachine.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/coyote/AsyncStateMachine.java?rev=1387938&r1=1387937&r2=1387938&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/coyote/AsyncStateMachine.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/coyote/AsyncStateMachine.java Thu Sep
20 09:56:06 2012
@@ -96,7 +96,7 @@ public class AsyncStateMachine {
DISPATCHED(false, false, false),
STARTING(true, true, false),
STARTED(true, true, false),
-MUST_COMPLETE(true, true, false),
+MUST_COMPLETE(true, false, false),
COMPLETING(true, false, false),
TIMING_OUT(true, false, false),
MUST_DISPATCH(true, true, true),
Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1387938&r1=1387937&r2=1387938&view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Thu Sep 20 09:56:06 2012
@@ -76,9 +76,9 @@
53843: request.isAsyncStarted() must continue
to
-return true until the dispatch/complete actually happens (which at the
-earliest isn't until the thread where startAsync() was
-called returns to the container). (markt)
+return true until the dispatch actually happens (which at the earliest
+isn't until the thread where startAsync() was called
+returns to the container). (markt)
53863: Ensure the the implicit servlets (JSP and default)
are
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53843] isAsyncStarted may return false in thread that started async processing
https://issues.apache.org/bugzilla/show_bug.cgi?id=53843 --- Comment #2 from Mark Thomas --- Actually, complete() is different (the TCK fails if we treat it the same way). As soon as complete() is called , isAsyncStarted() must return false. -- 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: r1387959 - in /tomcat/sandbox/trunk-resources: ./ java/org/apache/catalina/tribes/group/interceptors/ java/org/apache/coyote/ java/org/apache/tomcat/util/collections/ java/org/apache/tomca
Author: markt
Date: Thu Sep 20 10:46:53 2012
New Revision: 1387959
URL: http://svn.apache.org/viewvc?rev=1387959&view=rev
Log:
Sync with trunk
Modified:
tomcat/sandbox/trunk-resources/ (props changed)
tomcat/sandbox/trunk-resources/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
tomcat/sandbox/trunk-resources/java/org/apache/coyote/AsyncStateMachine.java
tomcat/sandbox/trunk-resources/java/org/apache/tomcat/util/collections/
(props changed)
tomcat/sandbox/trunk-resources/java/org/apache/tomcat/util/digester/CallMethodRule.java
tomcat/sandbox/trunk-resources/java/org/apache/tomcat/util/digester/CallParamRule.java
tomcat/sandbox/trunk-resources/res/findbugs/filter-false-positives.xml
tomcat/sandbox/trunk-resources/webapps/docs/config/cluster-interceptor.xml
Propchange: tomcat/sandbox/trunk-resources/
--
Merged /tomcat/trunk:r1386495-1387958
Modified:
tomcat/sandbox/trunk-resources/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/trunk-resources/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java?rev=1387959&r1=1387958&r2=1387959&view=diff
==
---
tomcat/sandbox/trunk-resources/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
(original)
+++
tomcat/sandbox/trunk-resources/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
Thu Sep 20 10:46:53 2012
@@ -65,7 +65,7 @@ public class TcpPingInterceptor extends
public synchronized void start(int svc) throws ChannelException {
super.start(svc);
running = true;
-if ( thread == null ) {
+if ( thread == null && useThread) {
thread = new PingThread();
thread.setDaemon(true);
thread.setName("TcpPingInterceptor.PingThread-"+cnt.addAndGet(1));
@@ -87,8 +87,10 @@ public class TcpPingInterceptor extends
@Override
public void stop(int svc) throws ChannelException {
running = false;
-if ( thread != null ) thread.interrupt();
-thread = null;
+if ( thread != null ) {
+thread.interrupt();
+thread = null;
+}
super.stop(svc);
}
Modified:
tomcat/sandbox/trunk-resources/java/org/apache/coyote/AsyncStateMachine.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/trunk-resources/java/org/apache/coyote/AsyncStateMachine.java?rev=1387959&r1=1387958&r2=1387959&view=diff
==
---
tomcat/sandbox/trunk-resources/java/org/apache/coyote/AsyncStateMachine.java
(original)
+++
tomcat/sandbox/trunk-resources/java/org/apache/coyote/AsyncStateMachine.java
Thu Sep 20 10:46:53 2012
@@ -101,7 +101,7 @@ public class AsyncStateMachine {
DISPATCHED(false, false, false),
STARTING(true, true, false),
STARTED(true, true, false),
-MUST_COMPLETE(true, true, false),
+MUST_COMPLETE(true, false, false),
COMPLETING(true, false, false),
TIMING_OUT(true, false, false),
MUST_DISPATCH(true, true, true),
Propchange:
tomcat/sandbox/trunk-resources/java/org/apache/tomcat/util/collections/
('bugtraq:append' removed)
Propchange:
tomcat/sandbox/trunk-resources/java/org/apache/tomcat/util/collections/
('bugtraq:label' removed)
Propchange:
tomcat/sandbox/trunk-resources/java/org/apache/tomcat/util/collections/
('bugtraq:message' removed)
Propchange:
tomcat/sandbox/trunk-resources/java/org/apache/tomcat/util/collections/
('bugtraq:url' removed)
Modified:
tomcat/sandbox/trunk-resources/java/org/apache/tomcat/util/digester/CallMethodRule.java
URL:
http://svn.apache.org/viewvc/tomcat/sandbox/trunk-resources/java/org/apache/tomcat/util/digester/CallMethodRule.java?rev=1387959&r1=1387958&r2=1387959&view=diff
==
---
tomcat/sandbox/trunk-resources/java/org/apache/tomcat/util/digester/CallMethodRule.java
(original)
+++
tomcat/sandbox/trunk-resources/java/org/apache/tomcat/util/digester/CallMethodRule.java
Thu Sep 20 10:46:53 2012
@@ -108,7 +108,7 @@ public class CallMethodRule extends Rule
this.paramTypes[i] = String.class;
}
}
-
+this.paramClassNames = null;
}
/**
@@ -193,8 +193,9 @@ public class CallMethodRule extends Rule
if (paramTypes == null) {
this.paramTypes = new Class[paramCount];
for (int i = 0; i < this.paramTypes.length; i++) {
-this.paramTypes[i] = "abc".getClass();
+this.paramTypes[i] = String.class;
}
+this.paramClassNames = null;
} else {
Re: Resources - Remaining TODOs
On 18/09/2012 14:55, Mark Thomas wrote: > On 09/09/2012 19:23, Mark Thomas wrote: >> This thread is for tracking the remaining TODO items. >> >> An initial brain dump of to do items: >> >> 1. Run Tomcat 7 TCKs >>a) To check they pass (minus the API tests which will fail) JSP TCK passes. Servlet TCK passes. >>b) to compare the performance > New implementation now appears slightly slower since additional checks > were added. Need to profile new code and check for hotspots. Still to do. >> 2. Add the ability to configure the new resources via context.xml / >>server.xml and document them. Done. >> 3. Complete all TODOs in the code. > Complete, bar one which depends on the caching decision. No change. >> 4. Remove the old resources implementation and associated supporting >>infrastructure (including tests). > Not started. No change. > 5. Review API with a view to custom resource implementations. Is it > simple to add a custom WebResourceRoot and/or WebResource? Done, a few changes were required. > 6. Review use of paths within the API. The aim is to reduce the need to > append '/' in various places if it is missing by better defining what > the API expects in terms of paths. To do. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Resources - Performance (caching)
On 09/09/2012 19:51, Mark Thomas wrote: > On 09/09/2012 19:44, Mark Thomas wrote: >> This is part of issue b) in Konstantin's comments in TOMCAT-NEXT.txt >> >> The current DirContext implementation supports caching in most but not >> all circumstances. It would be possible to insert a cache into the >> StandardRoot implementation but I am not convinced it is necessary. The >> read-cache built into most HDDs may be sufficient. Before starting a >> cache implementation, I would like to see some performance test cases >> that demonstrate that the DirContext implementation with caching is >> significantly faster than the new implementation without caching. > > I would add that if even if the new implementation without caching > performs roughly the same as the old implementation with caching but > adding caching makes the new implementation even faster than that would > also convince me of the need to add caching although not with the same > priority. And that is why we do performance testing rather than making assumptions about what we think the performance will be. A simple JMeter test requesting the same static file over and over again shows that the original DirContext implementation is around 5 times faster than the new Resources implementation. I think the do we need caching question has just been answered firmly "Yes!" Using YourKit, I can see where problems are. I can improve the new implementation to only 3 times slower with some very simple caching within a single request but for improvement beyond that we will need caching of resources across requests that includes caching of content. I plan to look at this next. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Resources - Performance (caching)
2012/9/20 Mark Thomas : > On 09/09/2012 19:51, Mark Thomas wrote: >> On 09/09/2012 19:44, Mark Thomas wrote: >>> This is part of issue b) in Konstantin's comments in TOMCAT-NEXT.txt >>> >>> The current DirContext implementation supports caching in most but not >>> all circumstances. It would be possible to insert a cache into the >>> StandardRoot implementation but I am not convinced it is necessary. The >>> read-cache built into most HDDs may be sufficient. Before starting a >>> cache implementation, I would like to see some performance test cases >>> that demonstrate that the DirContext implementation with caching is >>> significantly faster than the new implementation without caching. >> >> I would add that if even if the new implementation without caching >> performs roughly the same as the old implementation with caching but >> adding caching makes the new implementation even faster than that would >> also convince me of the need to add caching although not with the same >> priority. > > And that is why we do performance testing rather than making assumptions > about what we think the performance will be. > > A simple JMeter test requesting the same static file over and over again > shows that the original DirContext implementation is around 5 times > faster than the new Resources implementation. > > I think the do we need caching question has just been answered firmly "Yes!" > > Using YourKit, I can see where problems are. I can improve the new > implementation to only 3 times slower with some very simple caching > within a single request but for improvement beyond that we will need > caching of resources across requests that includes caching of content. > > I plan to look at this next. > Hi, Mark! I suspect the slowest scenario will be when a file is served from a META-INF/resources directory of a jar file. I wonder what the numbers will be and whether there is already some caching to prevent re-opening the jar file on each access. There is a related issue in WebappClassLoader that I filed here: https://issues.apache.org/bugzilla/show_bug.cgi?id=52448 I think I'll have time for more detailed review on this weekend. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 5.5.36
Jim, On 7/25/12 7:25 AM, Jim Jagielski wrote: > > On Jul 24, 2012, at 12:17 PM, Mark Thomas wrote: > >> On 24/07/2012 14:40, Jim Jagielski wrote: >>> Any interest in seeing a 5.5.36 release in the near future? >> >> We should to tie up the remaining loose ends before 5.5.x is EOL. No >> great rush at the moment though. >> > > Yeah, that's my plan. Any update on this? There hasn't been a release in 9 months, and we're about to officially mothball TC 5.5. I dunno if it's worth throwing the stragglers a bone, but officially supporting 5.5 through now seems like we should release what we've got: there are definitely some patches that are outstanding and not yet released. Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Resources - Performance (caching)
Konstantin Kolinko wrote: >2012/9/20 Mark Thomas : >> A simple JMeter test requesting the same static file over and over >again >> shows that the original DirContext implementation is around 5 times >> faster than the new Resources implementation. >> >> I think the do we need caching question has just been answered firmly >"Yes!" >> >> Using YourKit, I can see where problems are. I can improve the new >> implementation to only 3 times slower with some very simple caching >> within a single request but for improvement beyond that we will need >> caching of resources across requests that includes caching of >content. >> >> I plan to look at this next. >> > >Hi, Mark! > >I suspect the slowest scenario will be when a file is served from a >META-INF/resources directory of a jar file. Maybe. The main issues with simple static resource were lots of reads of the last modified time followed by reading the content. The factors that make that slow may be different for JARs. I expect JARs will have different but equally significant issues. I agree JARs are likely to be worse but I haven't tested them yet. >I wonder what the numbers will be and whether there is already some >caching to prevent re-opening the jar file on each access. Exactly. >There is a related issue in WebappClassLoader that I filed here: >https://issues.apache.org/bugzilla/show_bug.cgi?id=52448 I'll be interested to see what sort of difference that makes. >I think I'll have time for more detailed review on this weekend. Excellent. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
