[Bug 54261] web-fragment.xml handling in container JARs

2012-12-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=54261

--- Comment #2 from Mark Thomas ma...@apache.org ---
The relevant section is:
quote
If a framework wants its META-INF/web-fragment.xml honored in such a way that
it augments a web application's web.xml, the framework must be bundled within
the web application's WEB-INF/lib directory. In order for any other types of
resources (e.g., class files) of the framework to be made available to a web
application, it is sufficient for the framework to be present anywhere in the
classloader delegation chain of the web application. In other words, only JAR
files bundled in a web application's WEB-INF/lib directory, but not those
higher up in the class loading delegation chain, need to be scanned for
web-fragment.xml
/quote

The wording isn't as clear as it could be but the Servlet 3.0 EG lead has
confirmed the intended behaviour is as per my description. And yes, they should
still be scanned for TLDs.

I haven't tried to understand the reasoning behind this decision. My head hurts
enough already from just trying to nail down what the intended behaviour is
meant to be. I have thought through the implications for WebSocket and there
isn't anything I am worried about at this point.

-- 
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: auto-undeploy Old Context patch

2012-12-09 Thread Josh Gooding
On Sat, Dec 8, 2012 at 9:59 PM, Konstantin Kolinko
knst.koli...@gmail.comwrote:

 2012/12/9 Josh Gooding josh.good...@gmail.com:
  Sounds good.  I grabbed the source and have it imported into Eclipse.
  If I
  can ask here:
 

 Do not top-post
 http://en.wikipedia.org/wiki/Posting_style


Oh sorry about that, I'll try to remember that in the future.


  I'm developing on a Win-x64 Environment using JDK 1.6.0_34.  I am
 following
  along with the BUILDING.txt file and have taken the default
  build.properties.default and used it to create a standard
 build.properties
  file.  I have the parameter: base.path=C:/Users/Josh/workspace/TC7 set
  where the trunk is checked out to.

 It is a bas idea. It is better to point it to some empty directory. It
 is where the libraries will be downloaded.

  I run the build.xml from my IDE and I get 15 compile errors from the
  \tomcat7-deps\dbcp\src\java\org\apache\tomcat\dbcp\dbcp\ package.  The
  firsts compiler error I get (just as an example) is:
 
  BasicDataSource is not abstract and does not override abstract method
  getParentLogger() in CommonDataSource
 
  Any clues to what would cause this?  Since I haven't gotten the project
 off
  the ground and building yet, I'm just curious if it could be my setup or
 if
  there is some other underlying issue.

 DBCP cannot be compiled with Java 7, because of new methods in JDBC
 classes that it implements.  I'd say that your Ant build is using JDK
 7 instead of that 1.6.0_34.


Seemes to be the issue(s) I was having.  Ok, I am looking at your bugzilla
log.  Thanks Konstantin for getting me all

Warmest Regards,

Josh


Re: Tomcat 8.0.0

2012-12-09 Thread Rainer Jung
On 09.12.2012 13:12, Mayur Patil wrote:
 Hi there,
 
 How to view and access tomcat version 8.0.0 dev.
 
Whenever I try to view it gives 404 error??

No idea what you tried to view (URL?). There's no 8.0 release yet. You
can checkout from svn and build it. See

http://svn.apache.org/viewvc/tomcat/trunk/BUILDING.txt?view=markup

Regards,

Rainer


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[jira] [Closed] (MTOMCAT-194) Odd error message in switching from Codehaus to Maven Tomcat6 plugin

2012-12-09 Thread *$^¨%`£

 [ 
https://issues.apache.org/jira/browse/MTOMCAT-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy (*$^¨%`£) closed MTOMCAT-194.
--

   Resolution: Fixed
Fix Version/s: 2.1

 Odd error message in switching from Codehaus to Maven Tomcat6 plugin
 

 Key: MTOMCAT-194
 URL: https://issues.apache.org/jira/browse/MTOMCAT-194
 Project: Apache Tomcat Maven Plugin
  Issue Type: Bug
  Components: tomcat6
Affects Versions: 2.0
 Environment: Ubuntu, JDK 7, CXF 2.6.x branch.
Reporter: Glen Mazza
Assignee: Olivier Lamy (*$^¨%`£)
Priority: Minor
 Fix For: 2.1


 Hi, in the CXF JAX-RS (REST) plugin, if I switch from the Codehaus Tomcat 
 plugin to the Tomcat6 plugin (not Tomcat7 because this 2.6.x branch of CXF 
 needs to be Java 5 compatible) and run mvn clean install on a project 
 generated from the archetype it fails with a strange error of Document base 
 /media/work1/opensource/testrest/target/${project.build.finalName not being 
 available.  Note there's no ending } in that error message; also my 
 generated project make no reference to a project.build.finalName anywhere.
 Exact error message w/mvn clean install:
 [INFO] Building war: 
 /media/work1/opensource/testrest/target/testrest-0.0.1-SNAPSHOT.war
 [INFO] WEB-INF/web.xml already added, skipping
 [INFO] 
 [INFO]  tomcat6-maven-plugin:2.0:run-war (start-tomcat) @ testrest 
 [INFO] 
 [INFO] --- tomcat6-maven-plugin:2.0:run-war (start-tomcat) @ testrest ---
 [INFO] Running war on http://localhost:43769/jaxrs-service
 [INFO] Creating Tomcat server configuration at 
 /media/work1/opensource/testrest/target/tomcat
 Dec 08, 2012 3:22:25 PM org.apache.catalina.startup.Embedded start
 INFO: Starting tomcat server
 Dec 08, 2012 3:22:25 PM org.apache.catalina.core.StandardEngine start
 INFO: Starting Servlet Engine: Apache Tomcat/6.0.35
 Dec 08, 2012 3:22:25 PM org.apache.catalina.core.StandardContext 
 resourcesStart
 SEVERE: Error starting static Resources
 java.lang.IllegalArgumentException: Document base 
 /media/work1/opensource/testrest/target/${project.build.finalName does not 
 exist or is not a readable directory
   at 
 org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:142)
   at 
 org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4320)
   at 
 org.apache.catalina.core.StandardContext.start(StandardContext.java:4489)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057)
   at org.apache.catalina.core.StandardHost.start(StandardHost.java:840)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057)
   at 
 org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463)
   at org.apache.catalina.startup.Embedded.start(Embedded.java:825)
   at 
 org.apache.tomcat.maven.plugin.tomcat6.AbstractRunMojo.startContainer(AbstractRunMojo.java:850)
   at 
 org.apache.tomcat.maven.plugin.tomcat6.AbstractRunMojo.execute(AbstractRunMojo.java:429)
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:601)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
   at 
 

Re: Tomcat 8.0.0

2012-12-09 Thread Mayur Patil
Sir,

This is actual URL [1] but I am getting 404 error.
 I am attaching screenshot of cached copy of Google as I am unable to
access original[1].

thanks.

[1] http://ci.apache.org/projects/tomcat/tomcat8/docs/index.html



On Sun, Dec 9, 2012 at 7:38 PM, Rainer Jung rainer.j...@kippdata.dewrote:

 On 09.12.2012 13:12, Mayur Patil wrote:
  Hi there,
 
  How to view and access tomcat version 8.0.0 dev.
 
 Whenever I try to view it gives 404 error??

 No idea what you tried to view (URL?). There's no 8.0 release yet. You
 can checkout from svn and build it. See

 http://svn.apache.org/viewvc/tomcat/trunk/BUILDING.txt?view=markup

 Regards,

 Rainer


 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org




-- 

*Yours Sincerely,
Mayur S Patil,
*Survey No 124,
MIT College of Engineering,
Paud Road,
Kothrud,
Pune-38.
Ta: Haweli,
Dist: Pune.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tomcat 8.0.0

2012-12-09 Thread Rainer Jung
On 09.12.2012 18:33, Mayur Patil wrote:
 Sir,
 
 This is actual URL [1] but I am getting 404 error. 

It works for me. But that is just a continuous integration URL unlikely
to be the right place for you.

  I am attaching screenshot of cached copy of Google as I am unable
 to access original[1].

What do you want to achieve? Did you read the BUILDING.txt document I
suggested?

Regards,

Rainer

 [1] http://ci.apache.org/projects/tomcat/tomcat8/docs/index.html  
 
 
 
On Sun, Dec 9, 2012 at 7:38 PM, Rainer Jung rainer.j...@kippdata.de
 mailto:rainer.j...@kippdata.de wrote:
 
 On 09.12.2012 13:12, Mayur Patil wrote:
  Hi there,
 
  How to view and access tomcat version 8.0.0 dev.
 
 Whenever I try to view it gives 404 error??
 
 No idea what you tried to view (URL?). There's no 8.0 release yet. You
 can checkout from svn and build it. See
 
 http://svn.apache.org/viewvc/tomcat/trunk/BUILDING.txt?view=markup
 
 Regards,
 
 Rainer

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Tomcat 8.0.0

2012-12-09 Thread Mayur Patil
Sir,

 Your URL is pretty good that is really helpful to me.

   I want to look inside tomcat 8.0.0 dev to study its new implementations.

Cheers
Mayur.

On Mon, Dec 10, 2012 at 12:35 AM, Rainer Jung rainer.j...@kippdata.dewrote:

 On 09.12.2012 18:33, Mayur Patil wrote:
  Sir,
 
  This is actual URL [1] but I am getting 404 error.

 It works for me. But that is just a continuous integration URL unlikely
 to be the right place for you.

   I am attaching screenshot of cached copy of Google as I am unable
  to access original[1].

 What do you want to achieve? Did you read the BUILDING.txt document I
 suggested?

 Regards,

 Rainer

  [1] http://ci.apache.org/projects/tomcat/tomcat8/docs/index.html
 
 
 
 On Sun, Dec 9, 2012 at 7:38 PM, Rainer Jung rainer.j...@kippdata.de
  mailto:rainer.j...@kippdata.de wrote:
 
  On 09.12.2012 13:12, Mayur Patil wrote:
   Hi there,
  
   How to view and access tomcat version 8.0.0 dev.
  
  Whenever I try to view it gives 404 error??
 
  No idea what you tried to view (URL?). There's no 8.0 release yet.
 You
  can checkout from svn and build it. See
 
  http://svn.apache.org/viewvc/tomcat/trunk/BUILDING.txt?view=markup
 
  Regards,
 
  Rainer

 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org




-- 

*Yours Sincerely,
Mayur S Patil,
*Survey No 124,
MIT College of Engineering,
Paud Road,
Kothrud,
Pune-38.
Ta: Haweli,
Dist: Pune.


[Bug 54261] web-fragment.xml handling in container JARs

2012-12-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=54261

--- Comment #3 from Konstantin Kolinko knst.koli...@gmail.com ---
(In reply to comment #2)
 The relevant section is:
 quote
 If a framework wants its META-INF/web-fragment.xml honored in such a way
 that it augments a web application's web.xml, (...)

OK, this explains web fragments.
It should also imply that they
- are NOT scanned for @WebServlet/@WebFilter/@WebListener

based on a) support for metadata-complete attribute in web-fragmrnt.xml, b) 8.1
mentions WEB-INF/lib and WEB-INF/classes only
quote from=8.1
In a web application, classes using annotations will have their annotations
processed
only if they are located in the WEB-INF/classes directory, or if they are
packaged
in a jar file located in WEB-INF/lib within the application.
/quote


Regarding static resources see ch.4.6 that mentions WEB-INF/lib only, thus they
are NOT scanned,

quote from=4.6
The getResource and getResourceAsStream methods take a String with a leading
“/” as an argument that gives the path of the resource relative to the root of
the
context or relative to the META-INF/resources directory of a JAR file inside
the
web application’s WEB-INF/lib directory
/quote

The resources mentioned in the fragment of 8.2.1 that Mark quoted, I think
are referring to class and property files available through classloader, and
are not talking about static resources.


I think we can straighten this for Tomcat 8 (with its better support for
resources),
but for Tomcat 7 I am a bit afraid to change things.


I think that a reason behind disallowing web fragments at container level could
be
a) to lessen surprise for web applications that are moved between different
environments.
b) it simplifies requirements for declaration of web fragment ordering
c) it simplifies requirements for containers implementing this new feature
d) if a web fragment is in the container, it will be injected into all webapps
indiscriminately. Some of them may not expect this. It might even lead to some
security problems. Well, a SCI can inject the same servlets/filters/listeners
as a web fragment, but usually programmers are more accurate.

If we do change things for Tomcat 7, I think at most we can disallow
web-fragments coming from the parent (common) classloader, based on security
concerns from d). I think whatever is injected into specific web application
(via a DirContext (like used by Eclipse IDE - see bug 51741) or via
VirtualWebappLoader in its context.xml) is under control of a specific web
application and should be allowed.

-- 
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 54262] An empty absolute-ordering / should turn off all web-fragments

2012-12-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=54262

--- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com ---
Created attachment 29736
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=29736action=edit
resources1.jar

Confirming.

Steps to reproduce with 7.0.34:
1. Download attached resources1.jar and put it into
webapps/examples/WEB-INF/lib

The file is based on test/webapp-3.0-fragments/WEB-INF/lib/resources.jar from
Tomcat sources. I
a) removed all resources except resourceA.jsp and
b) declared an instance of HelloWorldServlet in web-fragment.xml.

2. Edit webapps/examples/WEB-INF/web.xml:
a) change metadata-complete attribute s/true/false/
b) add absolute-ordering /

3. Start Tomcat.
4. Actual result: The following two URLs work:
[1] http://localhost:8080/examples/resourceA.jsp
[2] http://localhost:8080/examples/resources1/HelloWorldExample

Expected result: [2] should return 404 as web-fragment.xml should be ignored
and the servlet mapping declared there should be ignored.

quote from=Servet Spec 3.0 Rev a - page #67 (89/230)
1.d. (..) If the
 absolute-ordering element does not contain an others/ element,
 any web-fragment not specifically mentioned within name / elements
 MUST be ignored. (...)
/quote

Regarding [1], I do not see any specific reference that such exclusion affects
static resources in META-INF/resources. Thus I think that the expected
behaviour of [1] is to display resourcesA.jsp page. 7.0.34 behaves correctly
here.

-- 
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: r1417194 - in /tomcat/trunk/java/org/apache/tomcat/util/buf: ByteChunk.java CharChunk.java

2012-12-09 Thread Konstantin Kolinko
2012/12/8 Caldarale, Charles R chuck.caldar...@unisys.com:
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Subject: Re: svn commit: r1417194 - in 
 /tomcat/trunk/java/org/apache/tomcat/util/buf: ByteChunk.java CharChunk.java

 On 12/4/12 4:21 PM, ma...@apache.org wrote:
  +private int hashCode=0;
  +// did we compute the hashcode ?
  +private boolean hasHashCode = false;

 Should hashCode and hasHashCode be volatile?

 Yes, to insure program order is followed; otherwise there's no guarantee that 
 hashCode and hasHashCode are written in the required sequence.

1) I would prefer a single volatile field rather than dealing with two
volatile ones.

E.g. make sure that hash() never returns 0 and use that as a flag.

If it is a single field, there is no need to make it volatile,
likewise the buff/start/end fields are not volatile.

2) I see no need for the public hash() method here. The MessageBytes
class can be changed to call hashCode().

 In fact, there seems to be much more code in there than necessary. Why not:

  +public int hashCode() {
  +if (hasHashCode) {
  +return hashCode;
  +}
  +hashCode = hash();
  +hasHashCode = true;
  +return hashCode;

 Or:

 public int hashCode() {
 if (!hasHashCode) {
 hashCode = hash();
 hasHashCode = true;
 }
 return hashCode;
 }


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 54260] JSP unloading - NullPointerException when using .tag files

2012-12-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=54260

--- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com ---
Confirming: I am able to reproduce this issue in 7.0.34 with the provided
recipe.

Once the problem occurs, the same exception starts to be printed every 10
seconds.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: [VOTE] Release Apache Tomcat 7.0.34

2012-12-09 Thread Konstantin Kolinko
2012/12/6 Mark Thomas ma...@apache.org:
 The proposed Apache Tomcat 7.0.34 release is now available for voting.

 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.34/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-113/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_34/

 The proposed 7.0.34 release is:
 [ ] Broken - do not release
 [x] Stable - go ahead and release as 7.0.34 Stable


I run the testsuite with JDK 6u37, BIOxNIOxAPR (tomcat-native 1.1.24)
on WinXP 32-bit.

All tests succeeded except one occasional failure in
org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.BIO

Testcase: testTimerThreadLeak took 2,515 sec
FAILED
null
junit.framework.AssertionFailedError: null
at 
org.apache.catalina.loader.TestWebappClassLoaderExecutorMemoryLeak.testTimerThreadLeak(TestWebappClassLoaderExecutorMemoryLeak.java:72)

The failing line is
Assert.assertTrue(executorServlet.tpe.isTerminated());

This a failure is not new and is not an issue.

Best regards,
Konstantin Kolinko

-
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

2012-12-09 Thread Gump
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 234 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: 24 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
-
[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
Downloading: 
http://localhost:8192/maven2/org/easymock/easymock/3.0/easymock-3.0.jar
111K downloaded  (easymock-3.0.jar)
[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