Re: [VOTE] Release Apache Tomcat 7.0.35
2013/1/11 Mark Thomas : > The proposed Apache Tomcat 7.0.35 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.35/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-123/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_35/ > It was reported on the users list that tomcat-embed-jasper.pom references wrong version of ecj. http://markmail.org/message/tpv35gf3mq7btkyk I corrected this in http://svn.apache.org/viewvc?view=revision&revision=1431922 I have not added it to the changelog yet, and maybe we need a better fix to substitute that number at build time. I would be OK if this were fixed by re-uploading files to maven without regenerating the binaries. Otherwise I'd better wait for 7.0.36: it should not be far away, and current version should still be able to run with older ECJ. The testing goes fine thus far. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1431946 - in /tomcat/tc6.0.x/trunk: STATUS.txt java/org/apache/catalina/core/ApplicationFilterConfig.java java/org/apache/catalina/core/StandardWrapper.java webapps/docs/changelog.xml
Author: kkolinko
Date: Fri Jan 11 09:23:06 2013
New Revision: 1431946
URL: http://svn.apache.org/viewvc?rev=1431946&view=rev
Log:
Fix leak of servlet instances when running with SecurityManager:
a) In case when Servlet.init() or destroy() fail.
b) In case of a SingleThreadModel servlet. (fix wrong argument)
Includes the same fix for filter instances when running with SecurityManager
and an Error is thrown by destroy().
It is based on r1429186 and partly on r1428993.
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationFilterConfig.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardWrapper.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1431946&r1=1431945&r2=1431946&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Jan 11 09:23:06 2013
@@ -94,14 +94,6 @@ PATCHES PROPOSED TO BACKPORT:
+1: kkolinko, markt
-1:
-* Fix memory leak of servlet instances when running with a
- SecurityManager and either init() or destroy() methods fail
- or the servlet is a SingleThreadModel one.
- It is based on r1429186
-
http://people.apache.org/~kkolinko/patches/2013-01-05_tc6_SecurityUtil_remove.patch
- +1: kkolinko, schultz, markt
- -1:
-
* Improve method cache handling in SecurityUtil class.
Add caching for Comet methods and simplify cache lookup code.
It is backport of r728776 (BZ 46304) and r1429360
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationFilterConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationFilterConfig.java?rev=1431946&r1=1431945&r2=1431946&view=diff
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationFilterConfig.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationFilterConfig.java
Fri Jan 11 09:23:06 2013
@@ -351,8 +351,9 @@ public final class ApplicationFilterConf
SecurityUtil.doAsPrivilege("destroy", filter);
} catch(java.lang.Exception ex){
context.getLogger().error("ApplicationFilterConfig.doAsPrivilege", ex);
+} finally {
+SecurityUtil.remove(filter);
}
-SecurityUtil.remove(filter);
} else {
filter.destroy();
}
@@ -401,8 +402,9 @@ public final class ApplicationFilterConf
SecurityUtil.doAsPrivilege("destroy", filter);
} catch(java.lang.Exception ex){
context.getLogger().error("ApplicationFilterConfig.doAsPrivilege", ex);
+} finally {
+SecurityUtil.remove(filter);
}
-SecurityUtil.remove(filter);
} else {
filter.destroy();
}
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardWrapper.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardWrapper.java?rev=1431946&r1=1431945&r2=1431946&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardWrapper.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardWrapper.java Fri
Jan 11 09:23:06 2013
@@ -1195,13 +1195,20 @@ public class StandardWrapper
servlet);
if( Globals.IS_SECURITY_ENABLED) {
-
-Object[] args = new Object[]{((ServletConfig)facade)};
-SecurityUtil.doAsPrivilege("init",
- servlet,
- classType,
- args);
-args = null;
+boolean success = false;
+try {
+Object[] args = new Object[]{ facade };
+SecurityUtil.doAsPrivilege("init",
+ servlet,
+ classType,
+ args);
+success = true;
+} finally {
+if (!success) {
+// destroy() will not be called, thus clear the
reference now
+SecurityUtil.remove(servlet);
+}
+}
} else {
serv
svn commit: r1431990 - /tomcat/trunk/test/org/apache/el/util/Tester.java
Author: rjung
Date: Fri Jan 11 11:08:17 2013
New Revision: 1431990
URL: http://svn.apache.org/viewvc?rev=1431990&view=rev
Log:
Remove svn:executable property from Tester.java.
Modified:
tomcat/trunk/test/org/apache/el/util/Tester.java (props changed)
Propchange: tomcat/trunk/test/org/apache/el/util/Tester.java
('svn:executable' removed)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1431991 - in /tomcat/tc7.0.x/trunk: ./ test/org/apache/el/util/Tester.java
Author: rjung
Date: Fri Jan 11 11:09:13 2013
New Revision: 1431991
URL: http://svn.apache.org/viewvc?rev=1431991&view=rev
Log:
Remove svn:executable property from Tester.java.
Backport of r1431990 from trunk.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/test/org/apache/el/util/Tester.java (props changed)
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1431990
Propchange: tomcat/tc7.0.x/trunk/test/org/apache/el/util/Tester.java
('svn:executable' removed)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-101) Add the ability to deploy to a Tomcat instance on the filesystem rather than via HTTP
[ https://issues.apache.org/jira/browse/MTOMCAT-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551057#comment-13551057 ] Glen Mazza commented on MTOMCAT-101: What's wrong with using HTTP? It's not that hard to configure: http://www.jroller.com/gmazza/entry/web_service_tutorial#maventomcat, and is the proper, Tomcat-defined way to deploy a webapp remotely that takes into account permissions and whatever lifecycle steps Tomcat needs to do to deploy/undeploy/redeploy a web application. I think what you're asking for should be done via the Maven Antrun plugin, if you're still inclined to go that route. But to provide a formal method for copying files to Tomcat's remote directory would be like endorsing that method of deployment as well as needlessly duplicating the Antrun plugin, things nobody should be doing and also something that can also raise many other JIRAs of subsequent problems that occur with this alternative route. > Add the ability to deploy to a Tomcat instance on the filesystem rather than > via HTTP > - > > Key: MTOMCAT-101 > URL: https://issues.apache.org/jira/browse/MTOMCAT-101 > Project: Apache Tomcat Maven Plugin > Issue Type: New Feature > Components: tomcat6, tomcat7 >Reporter: Steve Swinsburg >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: 2.1 > > > It would be great to have the ability to deploy a webapp to Tomcat without > using HTTP and the Tomcat Manager, by simply doing a filesystem copy of the > built war file to the location specified. > We currently use an ant profile to do this, but want to replace this with a > proper plugin. > We will be looking at contributing this feature in the near future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Commented] (MTOMCAT-195) Plugin uploads WAR file twice
[
https://issues.apache.org/jira/browse/MTOMCAT-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551065#comment-13551065
]
Glen Mazza commented on MTOMCAT-195:
Are you sure that's the case, looking at your output, I'm reading that the
first line displays while it is uploading (which can potentially take a long
time), while the second line is output *after* loading is complete. (Notice
the different -ing and -ed ending). I don't think there's a problem here.
[INFO] Deploying war to http://myserver.eu/pra-mobile-server
Uploading:
http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
Uploaded:
http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true (12678
KB at 49.3 KB/sec)
Uploading:
http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
Uploaded:
http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
> Plugin uploads WAR file twice
> -
>
> Key: MTOMCAT-195
> URL: https://issues.apache.org/jira/browse/MTOMCAT-195
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
> Components: tomcat6
>Affects Versions: 2.0
> Environment: Win7/64, Maven 3.0.4
>Reporter: George Smith
>Assignee: Olivier Lamy (*$^¨%`£)
>
> When I deploy my WAR using maven, the target war (exact the same one) is
> being uploaded to the server twice. Can someone explain that?
> I am using this on my module:
> {code}clean install org.apache.tomcat.maven:tomcat6-maven-plugin:2.0:redeploy
> {code}
> From the Log file
> {code =xml}
> [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ mobile-server ---
> [INFO] Packaging webapp
> [INFO] Assembling webapp [mobile-server] in
> [C:\develope\mobile\mobile-server\target\mobile-server]
> [INFO] Processing war project
> [INFO] Copying webapp resources
> [C:\develope\mobile\mobile-server\src\main\webapp]
> [INFO] Webapp assembled in [241 msecs]
> [INFO] Building war: C:\develope\mobile\mobile-server\target\mobile-server.war
> [INFO]
> [INFO] <<< tomcat6-maven-plugin:2.0:redeploy (default-cli) @ mobile-server <<<
> [INFO]
> [INFO] --- tomcat6-maven-plugin:2.0:redeploy (default-cli) @ mobile-server
> ---
> [INFO] Deploying war to http://myserver.eu/pra-mobile-server
> Uploading:
> http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
> Uploaded:
> http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
> (12678 KB at 49.3 KB/sec)
> Uploading:
> http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
> Uploaded:
> http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
> {code}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
>
> eu.company.prj.pramobile
> mobile-parent
> ../mobile-parent/pom.xml
> 1.0-SNAPSHOT
>
> mobile-server
> war
> mobile server
>
> 1.1.2
>
>
>
> com.springsource.repository.libs-milestone
> SpringSource Enterprise Bundle Repository - libs
> http://repo.springsource.org/libs-milestone/
>
>
>
>
> ${project.groupId}
> mobile-test
> ${project.version}
> test
>
>
> ${project.groupId}
> mobile-common
> ${project.version}
>
>
>
> org.springframework
> spring-asm
> ${version.spring}
>
>
> org.springframework
> spring-aop
> ${version.spring}
>
>
> org.springframework.security
> spring-security-config
> ${version.spring}
>
>
> org.springframework
> spring-web
> ${version.spring}
>
>
> org.springframework
> spring-oxm
> ${version.spring}
>
>
> org.springframework
> spring-webmvc
> ${version.spring}
>
>
> org.springframework.security
> spring-security-web
> ${version.spring}
>
>
> commons-codec
> commons-codec
> 1.7
>
>
> javax.servlet
> jsp-api
> 2.0
> provided
>
>
> commons-io
> commons-io
> 2.4
>
>
> commons-fileupload
> commons-fileupload
> 1.2.2
>
>
> javax.servlet
> servlet-api
> 2.5
> provided
>
>
> javax.servlet
> jstl
> 1.1.2
> provided
>
>
> taglibs
> standard
> 1.1.2
> provided
>
>
> commons-httpclient
> commons-httpclient
> 3.1
>
>
[jira] [Commented] (MTOMCAT-190) Client Certificate settings for connector
[
https://issues.apache.org/jira/browse/MTOMCAT-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551072#comment-13551072
]
Glen Mazza commented on MTOMCAT-190:
Might be a lot of work to put that capability into the embedded Tomcat.
Tomcat7:run is primarily for hot deployment of webapps while you tweak your
JSP's, CSS, javascripts, etc. If you're deploying in production on a
standalone Tomcat, Tomcat-specific testing such as certificate login tests
should probably be against a standalone Tomcat anyway.
> Client Certificate settings for connector
> -
>
> Key: MTOMCAT-190
> URL: https://issues.apache.org/jira/browse/MTOMCAT-190
> Project: Apache Tomcat Maven Plugin
> Issue Type: Improvement
> Components: tomcat7
>Affects Versions: 2.0
>Reporter: Marcel Silberhorn
>Assignee: Olivier Lamy (*$^¨%`£)
> Labels: connector
> Fix For: 2.1
>
>
> currently there seems to be no way to configure SSL connector settings like
> clientAuth what make it useless for certain certificate login tests and I
> always need a second, manually installed instance of Tomcat for this but I'm
> not able to just run {{tomcat7:run}}
> So it would be great so see some clientCert options in an upcoming version!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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
Re: [VOTE] Release Apache Tomcat 7.0.35
On 11.01.2013 00:40, Mark Thomas wrote: > The proposed Apache Tomcat 7.0.35 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.35/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-123/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_35/ > > The proposed 7.0.35 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 7.0.35 Stable +1 to release. Details: - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src completely consistent with svn tag Except for executable bits on Tester.java in svn. Not critical, already fixed for next release. - builds fine - new warning in test/org/apache/catalina/core/TestStandardContextResources.java: uses unchecked or unsafe operations - build result looks consistent with binaries - no checkstyle complaints - some Javadoc warnings (only in jdbc-pool, not a regression) - Unit tests - no error or failures - some warnings (see below), one new warning type concerning NPE in CoyoteAdapter when calling access log - JMX MBean-Comparison OK - OpenFileDescriptorCount down from 61 to 57 Build and tests were done using Java 1.6.0_37. OS was Solaris 10 Sparc, tcnative was 1.1.24 based on APR 1.4.6 and OpenSSL 1.0.1c (plus two patches). Unit test warnings (except for tribes and the access log exceptions all of those look like 7.0.33 and before): - Exception while attempting to add an entry to the access log in org.apache.catalina.connector.CoyoteAdapter log while running org.apache.el.TestELInJsp and org.apache.jasper.compiler.TestParser. The exception stack in both cases was: java.lang.NullPointerException at org.apache.catalina.connector.CoyoteAdapter.log(CoyoteAdapter.java:511) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1033) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1680) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Line 511 in CoyoteAdapter is connector.getService().getContainer().logAccess(...); - org.apache.catalina.deploy.TestWebXmlOrdering - BIO, NIO and APR: [main] org.apache.catalina.deploy.WebXml.orderWebFragments Used a wrong fragment name z at web.xml absolute-ordering tag! - org.apache.tomcat.util.net.TestCustomSsl - BIO twice "Exception getting SSL attributes" in org.apache.coyote.http11.Http11Processor actionInternal exception is: javax.net.ssl.SSLProtocolException: handshake alert: no_certificate - NIO twice "WARNING: Exception re-negotiating SSL connection" in org.apache.coyote.http11.Http11NioProcessor actionInternal - tribes: several warnings, roughly same as before Unit test SEVERE messages: 225 total (+7), about 35 unique messages Most of those are of type "Servlet.service() for servlet ... threw exception" (134 times). 3 less not stopped threads errors, some deltas in tribes errors, 3 times each of the new messages WebXml.mergeLifecycleCallback The [Post Construct Methods] with name [a] was defined inconsistently in multiple fragments including fragment with name [null] located at [null] and WebXml.mergeLifecycleCallback The [Pre Destroy Methods] with name [b] was defined inconsistently in multiple fragments including fragment with name [null] located at [null] and twice the new Error processing request with reason an NPE: java.lang.NullPointerException at org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:129) at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174) at org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:163) at org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer(InternalNioOutputBuffer.java:242) at org.apache.coyote.http11.InternalNioOutputBuffer.endRequest(InternalNioOutputBuffer.java:121) at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:749) at org.apache.coyote.Response.action(Response.java:173) at org.apache.coyote.Response.finish(Response.java:279) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:293) at org.apache.catalina.connector.Response.finishResponse(Response.java:513) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:434) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) at org
[jira] [Commented] (MTOMCAT-196) Add the possiblilty to search warRunDepencies and extraDependcies throug the dependencyManagement
[
https://issues.apache.org/jira/browse/MTOMCAT-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551084#comment-13551084
]
Glen Mazza commented on MTOMCAT-196:
You can still define properties in parent POMs of course:
3.2 , then use
${my.lib.version}.
I believe Guillaume is referring to the exec-war and exec-war-only goals, as
those seem to be the only two with those options. I don't know what the
difference is between warRunDependency and extraDependency (the docs don't
define the former:
http://tomcat.apache.org/maven-plugin-2.1-SNAPSHOT/tomcat7-maven-plugin/exec-war-mojo.html.)
Also, I'm not sure what types of dependencies would need to be placed in the
Tomcat root classloader and not just with the web application itself (i.e.,
can't Guillaume just declare these as normal within the WAR so
the version numbers can be taken care of that way?) Although this suggestion
does have merit, arguably it may not be worth the effort if it is so rarely
used and can be used instead, further, as a drawback it might
cause more people to incorrectly over-use this functionality instead of
properly defining the with the WAR itself.
> Add the possiblilty to search warRunDepencies and extraDependcies throug the
> dependencyManagement
> -
>
> Key: MTOMCAT-196
> URL: https://issues.apache.org/jira/browse/MTOMCAT-196
> Project: Apache Tomcat Maven Plugin
> Issue Type: Improvement
> Components: tomcat7
>Affects Versions: 2.0
>Reporter: Guillaume Soing
>Assignee: Olivier Lamy (*$^¨%`£)
> Labels: features
>
> It wiil be nice to do not specify the version of the warRunDepency and
> extraDependency, it will be easier to handle war version during the release
> process.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Commented] (MTOMCAT-187) Scan resources executing run goal
[ https://issues.apache.org/jira/browse/MTOMCAT-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551089#comment-13551089 ] Glen Mazza commented on MTOMCAT-187: Arne's solution may work, but the apparent issue (which needs confirmation still) is that backgroundProcessorDelay isn't working. > Scan resources executing run goal > - > > Key: MTOMCAT-187 > URL: https://issues.apache.org/jira/browse/MTOMCAT-187 > Project: Apache Tomcat Maven Plugin > Issue Type: Question > Components: tomcat7 >Affects Versions: 2.0-beta-1 >Reporter: Sergio Fernández >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > Labels: maven > Fix For: 2.1 > > > I tried to find this detail at the documentation, but sorry but I didn't. > The question is: does the plugin has any way to force the goal tomcat7:run to > scan (and updated when are modified) resources? Something equivalent to > scanIntervalSeconds in the maven jetty plugin. > Thanks in advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Commented] (MTOMCAT-189) additionalClassesDirs parameter handling expanded to include run and run-war goals
[ https://issues.apache.org/jira/browse/MTOMCAT-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551102#comment-13551102 ] Glen Mazza commented on MTOMCAT-189: Nick, to avoid duplication of functionality, would it be possible (and sufficiently convenient) to rely on the META-INF/context.xml file for this configuration? Both the run and run-war goals will read this file if available. It has configuration capabilities for a Loader object (http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Nested_Components) also a "virtual webapp" (http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Virtual_webapp) both of which allow classpath modification. Also, I'm not sure if your intended patch is to allow you to just to set classpath directories (where the "single configuration file holding any environment-specific configuration data" you mention above already exists on the user's local machine) or send along additional dependencies (i.e., store that config file in the project and make sure it's sent to embedded Tomcat when it runs the patch)--which is your intention here? Also, you appear to have forgotten to attach the patch...do you still have it? Thanks! > additionalClassesDirs parameter handling expanded to include run and run-war > goals > -- > > Key: MTOMCAT-189 > URL: https://issues.apache.org/jira/browse/MTOMCAT-189 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Nick Lloyd >Priority: Minor > Fix For: 2.1 > > > I contributed the original patch to add the functionality to add additional > directories to the classpath for the run goal. This patch expands on that, > adding the functionality to both run and run-war goals in the tomcat6 and > tomcat7 plugin artifacts. > Please review and incorporate as you see fit. My organization is using this > internally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Commented] (MTOMCAT-183) java.lang.NoSuchMethodError: javax.xml.stream.XMLInputFactory.newFactory() error for 2.1-SNAPSHOT and 2.0-RELEASE
[ https://issues.apache.org/jira/browse/MTOMCAT-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551103#comment-13551103 ] Glen Mazza commented on MTOMCAT-183: I'm not sure what version you're using that is causing this error, you say it's OK with 2.0-SNAPSHOT, but when you write at the top "when run tomcat7:run", *which* version of tomcat7:run are you running (2.0? 2.1-SNAPSHOT?) that is causing this error? The text seems to say you're using 2.1-SNAPSHOT, but I don't know if the version you're using is 2.1-SNAPSHOT or another version erroneously calling the 2.1-SNAPSHOT version. I was running both tomcat7:run and :run-war yesterday w/2.1-SNAPSHOT (which has had several changes since last October) with no problem. I use JDK 7 though. I'm guessing the problem might be with your JDK (a JBoss user had a similar problem: https://community.jboss.org/thread/154156?_sscc=t). Could you try again with 2.1-SNAPSHOT and confirm it's still happening with you? > java.lang.NoSuchMethodError: javax.xml.stream.XMLInputFactory.newFactory() > error for 2.1-SNAPSHOT and 2.0-RELEASE > -- > > Key: MTOMCAT-183 > URL: https://issues.apache.org/jira/browse/MTOMCAT-183 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat7 >Affects Versions: 2.0 > Environment: os: win7-64x jdk: jdk1.6.0_12 maven:apache-maven-3.0.4 >Reporter: ZHANG Frank >Assignee: Olivier Lamy (*$^¨%`£) > Labels: maven > Fix For: 2.1 > > Original Estimate: 12h > Remaining Estimate: 12h > > when run tomcat7:run, errors as follow: > ... > urls[45] = > file:/C:/Users/Administrator/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar > urls[46] = > file:/C:/Users/Administrator/.m2/repository/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar > Number of foreign imports: 1 > import: Entry[import from realm ClassRealm[maven.api, parent: null]] > - > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > Caused by: org.apache.maven.plugin.PluginContainerException: An API > incompatibility was encountered while executing > org.apache.tomcat.maven:tomcat7-maven-plugin:2.1-SNAPSHOT:run: > java.lang.NoSuchMethodError: > javax.xml.stream.XMLInputFactory.newFactory()Ljavax/xml/stream/XMLInputFactory; > - > realm =plugin>org.apache.tomcat.maven:tomcat7-maven-plugin:2.1-SNAPSHOT > strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy > urls[0] = > file:/C:/Users/Administrator/.m2/repository/org/apache/tomcat/maven/tomcat7-maven-plugin/2.1-SNAPSHOT/tomcat7-maven-plugin-2.1-SNAPSHOT.jar > urls[1] = > file:/C:/Users/Administrator/.m2/repository/org/apache/tomcat/embed/tomcat-embed-core/7.0.32/tomcat-embed-core-7.0.32.jar > urls[2] = > file:/C:/Users/Administrator/.m2/repository/org/apache/tomcat/tomcat-util/7.0.32/tomcat-util-7.0.32.jar > ... > urls[45] = > file:/C:/Users/Administrator/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar > urls[46] = > file:/C:/Users/Administrator/.m2/repository/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar > Number of foreign imports: 1 > import: Entry[import from realm ClassRealm[maven.api, parent: null]] > - > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) > ... 20 more > Caused by: java.lang.NoSuchMethodError: > javax.xml.stream.XMLInputFactory.newFactory()Ljavax/xml/stream/XMLInputFactory; > at > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.parseContextFile(AbstractRunMojo.java:589) > at > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.createContext(AbstractRunMojo.java:539) > at > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.startContainer(AbstractRunMojo.java:929) > at > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.execute(AbstractRunMojo.java:478) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > ... 20 more > [ERROR] > and when using tomcat7-maven-plugin 2.0-SNAPSHOT version. it's ok. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more info
[jira] [Commented] (MTOMCAT-73) deploy-only goal with exliplicit contextFile-Param set leads to FileNotFoundException
[
https://issues.apache.org/jira/browse/MTOMCAT-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551113#comment-13551113
]
Glen Mazza commented on MTOMCAT-73:
---
That's the old Codehaus plugin ('course, this JIRA is from 2010 so that's
understandable.) A patch was provided yesterday to MTOMCAT-119 (a somewhat
related matter) with the Apache Maven Tomcat 7 plugin, and as I understand it
worked already with the tomcat6 plugin. Providing you place the context file
where it should be, i.e., src/main/webapp/META-INF/context.xml
(http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context),
you shouldn't need to configure this property at all.
Offhand, your use of double-slashes:
//META-INF/tomcat//context.xml, seems strange, I'm
not accustomed to that, I don't know if that's a Windows thing or something
else.
Please upgrade to the Apache Tomcat plugins and try again:
http://tomcat.apache.org/maven-plugin-2.1-SNAPSHOT/tomcat7-maven-plugin/index.html
> deploy-only goal with exliplicit contextFile-Param set leads to
> FileNotFoundException
> -
>
> Key: MTOMCAT-73
> URL: https://issues.apache.org/jira/browse/MTOMCAT-73
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: Maven (client): Windows XP (32bit)
> Server: Linux (Suse)
> Tomcat: 6.0.26
>Reporter: Niels Kausche
>
> Deploying a context.xml as contextFile-Parameter leads to a
> FileNotFoundException either on the client (maven command line) or on the
> server (catalina.out).
> Always with the same filename. Ist the given context.xml-File transferred to
> the server or just the file name?
> Hier is my Plugin-Configuration:
>
> org.codehaus.mojo
> tomcat-maven-plugin
> 1.1
>
>
> /
> context
> //META-INF/tomcat//context.xml
>
>
> I am using the task to deploy to our development, test, or production server
> using different jndi configurations in different context.xml files.
> Here the server stack trace (catalina.out):
> (you see, it is the original local file name from the build server. And it is
> correct.)
> java.io.FileNotFoundException:
> /C:/Entwicklung/projekte-rivotool/dr.servicecockpit.rivo.web/target/dr.servicecockpit.rivo.web-1.2.19/META-INF/tomcat/etest/
> ccontext.xml (No such file or directory)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(FileInputStream.java:106)
> at
> org.apache.catalina.manager.ManagerServlet.copyInternal(ManagerServlet.java:1671)
> at
> org.apache.catalina.manager.ManagerServlet.copy(ManagerServlet.java:1632)
> at
> org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:836)
> at
> org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:351)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:558)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
> at
> org.apache.coyote.http11.Http11ProtocolHttp11ConnectionHandler.process(Http11Protocol.java:588)
> at
> org.apache.tomcat.util.net.JIoEndpointWorker.run(JIoEndpoint.java:489)
> at java.lang.Thread.run(Thread.java:619)
> Exception in thread "net.sf.ehcache.CacheManager@647fc8b2"
> java.lang.NullPointerException
> at
> org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:204)
> at
> net.sf.ehcache.util.UpdateChecker.checkForUpdate(UpdateChecker.java:62)
> at net.sf.ehcache.util.UpdateChecker.run(UpdateChecker.java:50)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, ple
[jira] [Commented] (MTOMCAT-178) additionalClasspathDirs doesn't seem to be used
[
https://issues.apache.org/jira/browse/MTOMCAT-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551122#comment-13551122
]
Glen Mazza commented on MTOMCAT-178:
According to this JIRA it's not yet implemented with the Tomcat 7 plugin:
https://issues.apache.org/jira/browse/MTOMCAT-189. But I don't think you need
additionalClasspathDirs for what you're configuring -- I would suggest
"warSourceDirectory"
(http://tomcat.apache.org/maven-plugin-2.1-SNAPSHOT/tomcat7-maven-plugin/run-mojo.html)
if you want to reroute from src/main/webapp (put there by default to allow for
real-time updating of css/jsp/javascript files) to the more authoritative
target/webappname/ folder, which should have all the dependencies being defined
in your pom.
Also, AFAIK additionalClasspathDirs is intended to be for additional classpaths
for dependencies not declared in your WAR (or, probably in your case, in JARs
declared as dependencies in your pom.xml), it's not meant as an overriding
feature ("hey, ignore my foo.jar I put in the WAR and use this one instead!").
It should be rarely needed. Also, it doesn't have a concept of
inheritance/precedence, you're at Tomcat's mercy of whatever it wants to do if
you declare the same dependency in multiple places.
> additionalClasspathDirs doesn't seem to be used
> ---
>
> Key: MTOMCAT-178
> URL: https://issues.apache.org/jira/browse/MTOMCAT-178
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
> Components: tomcat7
>Affects Versions: 2.0
> Environment: Maven 3.0.3 / Linux / OpenJDK 7
>Reporter: Craig
>Assignee: Olivier Lamy (*$^¨%`£)
>
> Using the plugin like this:
>
> org.apache.tomcat.maven
> tomcat7-maven-plugin
> 2.0
>
>
>
> ${project.build.directory}/../../../mits-common-parent/common-ui/src/main/resource$
>
> ${project.build.directory}/../src/main/webapp
>
>
>
> I run Tomcat like this:
> mvn tomcat7:run
> The application starts and runs fine. But, when the classloader loads a
> resource that is in one of the additionalClasspathDir entries, it loads it
> from the .war, not from the additionalClasspathDir location. Nothing I do
> seems to make Tomcat use the additionalClasspathDir entries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Commented] (MTOMCAT-178) additionalClasspathDirs doesn't seem to be used
[
https://issues.apache.org/jira/browse/MTOMCAT-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551127#comment-13551127
]
Glen Mazza commented on MTOMCAT-178:
Oops, nm, we do have additionalClasspathDirs already in tomcat 7 plugin
(http://tomcat.apache.org/maven-plugin-2.1-SNAPSHOT/tomcat7-maven-plugin/run-mojo.html).
MTOMCAT-189 is over "additionalClassesDirs" (unsure if that's the same thing.)
> additionalClasspathDirs doesn't seem to be used
> ---
>
> Key: MTOMCAT-178
> URL: https://issues.apache.org/jira/browse/MTOMCAT-178
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
> Components: tomcat7
>Affects Versions: 2.0
> Environment: Maven 3.0.3 / Linux / OpenJDK 7
>Reporter: Craig
>Assignee: Olivier Lamy (*$^¨%`£)
>
> Using the plugin like this:
>
> org.apache.tomcat.maven
> tomcat7-maven-plugin
> 2.0
>
>
>
> ${project.build.directory}/../../../mits-common-parent/common-ui/src/main/resource$
>
> ${project.build.directory}/../src/main/webapp
>
>
>
> I run Tomcat like this:
> mvn tomcat7:run
> The application starts and runs fine. But, when the classloader loads a
> resource that is in one of the additionalClasspathDir entries, it loads it
> from the .war, not from the additionalClasspathDir location. Nothing I do
> seems to make Tomcat use the additionalClasspathDir entries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Commented] (MTOMCAT-159) WAR dependencies extracted every run
[ https://issues.apache.org/jira/browse/MTOMCAT-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551131#comment-13551131 ] Glen Mazza commented on MTOMCAT-159: What are the tomcat7 (tomcat6) goals that cause this deletion/extraction to occur? Just about all of them? > 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 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
svn commit: r1432054 - in /tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run: AbstractRunMojo.java AbstractRunWarMojo.java
Author: olamy
Date: Fri Jan 11 13:59:27 2013
New Revision: 1432054
URL: http://svn.apache.org/viewvc?rev=1432054&view=rev
Log:
[MTOMCAT-119] tomcat7:run-war fails because it expects META-INF\context.xml
Submitted by Glen Mazza
Modified:
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunMojo.java
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunWarMojo.java
Modified:
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunMojo.java
URL:
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunMojo.java?rev=1432054&r1=1432053&r2=1432054&view=diff
==
---
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunMojo.java
(original)
+++
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunMojo.java
Fri Jan 11 13:59:27 2013
@@ -344,6 +344,16 @@ public abstract class AbstractRunMojo
protected File contextFile;
/**
+ * The default context file to check for if contextFile not configured.
+ * If no contextFile configured and the below default not present, no
+ * contextFile will be sent to Tomcat, resulting in the latter's default
+ * context configuration being used instead.
+ */
+@Parameter( defaultValue =
"${project.build.directory}/${project.build.finalName}/META-INF/context.xml",
+readonly = true )
+private File defaultContextFile;
+
+/**
* The protocol to run the Tomcat server on.
* By default it's HTTP/1.1.
*
@@ -532,12 +542,21 @@ public abstract class AbstractRunMojo
String baseDir = getDocBase().getAbsolutePath();
-File overridedContextFile = getContextFile();
+File overriddenContextFile = getContextFile();
+
+StandardContext standardContext = null;
-if ( overridedContextFile != null && overridedContextFile.exists() )
+if ( overriddenContextFile != null && overriddenContextFile.exists() )
{
-StandardContext standardContext = parseContextFile(
overridedContextFile );
+standardContext = parseContextFile( overriddenContextFile );
+}
+else if (defaultContextFile.exists())
+{
+standardContext = parseContextFile( defaultContextFile );
+}
+if (standardContext != null)
+{
if ( standardContext.getPath() != null )
{
contextPath = standardContext.getPath();
@@ -566,11 +585,18 @@ public abstract class AbstractRunMojo
context.setLoader( loader );
-if ( overridedContextFile != null )
+if ( overriddenContextFile != null )
{
-context.setConfigFile( overridedContextFile.toURI().toURL() );
+// here, send file to Tomcat for it to complain if missing
+context.setConfigFile( overriddenContextFile.toURI().toURL() );
+}
+else if (defaultContextFile.exists())
+{
+// here, only sending default file if it indeed exists
+// otherwise Tomcat will create a default context
+ context.setConfigFile( defaultContextFile.toURI().toURL() );
}
-
+
if ( classLoaderClass != null )
{
loader.setLoaderClass( classLoaderClass );
Modified:
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunWarMojo.java
URL:
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunWarMojo.java?rev=1432054&r1=1432053&r2=1432054&view=diff
==
---
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunWarMojo.java
(original)
+++
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractRunWarMojo.java
Fri Jan 11 13:59:27 2013
@@ -39,15 +39,9 @@ public abstract class AbstractRunWarMojo
/**
* The path of the exploded WAR directory to run.
*/
-@Parameter( defaultValue =
"${project.build.directory}/${project.build.finalName}", required = true )
+@Parameter( property = "maven.tomcat.warDirectory", defaultValue =
"${project.build.directory}/${project.build.finalName}", required = true )
private File warDirectory;
-/**
- * The path of the Tomcat context XML file.
- */
-@Parameter( defaultValue =
"${project.build.directory}/${project.build.final
[jira] [Closed] (MTOMCAT-119) tomcat7:run-war fails because it expects META-INF\context.xml
[
https://issues.apache.org/jira/browse/MTOMCAT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) closed MTOMCAT-119.
--
Resolution: Fixed
fixed http://svn.apache.org/r1432054
Thanks !
> tomcat7:run-war fails because it expects META-INF\context.xml
> -
>
> Key: MTOMCAT-119
> URL: https://issues.apache.org/jira/browse/MTOMCAT-119
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
> Components: tomcat7
>Affects Versions: 2.0-beta-1
>Reporter: Antelink
>Assignee: Olivier Lamy (*$^¨%`£)
> Fix For: 2.1
>
> Attachments: MTOMCAT119.patch, web_service_tutorial.zip
>
>
> run-war and run-war-only goals fail on tomcat7 plugin, looking for the file
> =META-INF\context.xml=
> How to reproduce:
> * Use the archetype to create a project
> mvn archetype:generate -DarchetypeGroupId=org.apache.tomcat.maven
> -DarchetypeArtifactId=tomcat-maven-archetype -DarchetypeVersion=2.0-beta-1
> * Build it
> * cd basic-webapp
> * mvn org.apache.tomcat.maven:tomcat6-maven-plugin:run-war
> => works fine
> * mvn org.apache.tomcat.maven:tomcat7-maven-plugin:run
> => works fine
> * mvn org.apache.tomcat.maven:tomcat7-maven-plugin:run-war
> -> kaboom
> {code}
> [INFO] --- tomcat7-maven-plugin:2.0-beta-1:run-war (default-cli) @
> basic-webapp ---
> [INFO] Running war on http://localhost:9090/
> [INFO] Using existing Tomcat server configuration at
> C:\Users\SAMUEL~1.LAN\AppData\Local\Temp\com.antelink.toto\basic-webapp\target\tomcat
> févr. 16, 2012 6:56:24 PM org.apache.coyote.AbstractProtocol init
> Infos: Initializing ProtocolHandler ["http-bio-9090"]
> févr. 16, 2012 6:56:24 PM org.apache.catalina.core.StandardService
> startInternal
> Infos: Starting service Tomcat
> févr. 16, 2012 6:56:24 PM org.apache.catalina.core.StandardEngine
> startInternal
> Infos: Starting Servlet Engine: Apache Tomcat/7.0.25
> févr. 16, 2012 6:56:24 PM org.apache.catalina.startup.ContextConfig
> processContextConfig
> Grave: Missing context.xml:
> file:/C:/Users/SAMUEL~1.LAN/AppData/Local/Temp/com.antelink.toto/basic-webapp/target/basic-webapp-1.0-SNAPSHOT/META-INF/context.xml
> java.io.FileNotFoundException:
> C:\Users\SAMUEL~1.LAN\AppData\Local\Temp\com.antelink.toto\basic-webapp\target\basic-webapp-1.0-SNAPSHOT\META-INF\context.xml
> (Le fichier spécifié est introuvable)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(FileInputStream.java:138)
> at java.io.FileInputStream.(FileInputStream.java:97)
> at
> sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:90)
> at
> sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:188)
> at java.net.URL.openStream(URL.java:1035)
> at
> org.apache.catalina.startup.ContextConfig.processContextConfig(ContextConfig.java:565)
> at
> org.apache.catalina.startup.ContextConfig.contextConfig(ContextConfig.java:546)
> at
> org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:784)
> at
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:318)
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
> at
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:401)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-189) additionalClassesDirs parameter handling expanded to include run and run-war goals
[ https://issues.apache.org/jira/browse/MTOMCAT-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Lloyd updated MTOMCAT-189: --- Attachment: tomcat-run_runWar.patch > additionalClassesDirs parameter handling expanded to include run and run-war > goals > -- > > Key: MTOMCAT-189 > URL: https://issues.apache.org/jira/browse/MTOMCAT-189 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Nick Lloyd >Priority: Minor > Fix For: 2.1 > > Attachments: tomcat-run_runWar.patch > > > I contributed the original patch to add the functionality to add additional > directories to the classpath for the run goal. This patch expands on that, > adding the functionality to both run and run-war goals in the tomcat6 and > tomcat7 plugin artifacts. > Please review and incorporate as you see fit. My organization is using this > internally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Commented] (MTOMCAT-189) additionalClassesDirs parameter handling expanded to include run and run-war goals
[ https://issues.apache.org/jira/browse/MTOMCAT-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551152#comment-13551152 ] Nick Lloyd commented on MTOMCAT-189: Glen: I was not aware of the configuration options available in the META-INF/context.xml file (VirtualWebappLoader in particular would appear to be ideal for the current needs of my project). That will be sufficiently convenient and thank you for pointing that out! The former rather than the latter, basically to add arbitrary directories to the classpath as if one were doing the same using a custom setenv.sh script. Attached the patch... go figure I left that part out! > additionalClassesDirs parameter handling expanded to include run and run-war > goals > -- > > Key: MTOMCAT-189 > URL: https://issues.apache.org/jira/browse/MTOMCAT-189 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Nick Lloyd >Priority: Minor > Fix For: 2.1 > > Attachments: tomcat-run_runWar.patch > > > I contributed the original patch to add the functionality to add additional > directories to the classpath for the run goal. This patch expands on that, > adding the functionality to both run and run-war goals in the tomcat6 and > tomcat7 plugin artifacts. > Please review and incorporate as you see fit. My organization is using this > internally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Closed] (MTOMCAT-105) creating executable war failed
[ https://issues.apache.org/jira/browse/MTOMCAT-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) closed MTOMCAT-105. -- Resolution: Incomplete please provide more infos. > creating executable war failed > -- > > Key: MTOMCAT-105 > URL: https://issues.apache.org/jira/browse/MTOMCAT-105 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat7 >Affects Versions: 2.0-beta-1 > Environment: C:\Users\albert\workspace\BasicSetup>mvn --version > Apache Maven 3.0.3 (r1075438; 2011-03-01 00:31:09+0700) > Maven home: C:\Users\albert\Desktop\myapps\apache-maven-3.0.3\bin\.. > Java version: 1.7.0, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.7.0\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "x86", family: "windows" >Reporter: albert kam >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Critical > Labels: exec-war > Fix For: moreinfo > > Attachments: BasicSetup.zip > > Original Estimate: 0.05h > Remaining Estimate: 0.05h > > Just today on November 3rd, i tried out the tomcat7 maven plugin to try out > the executable war. > Following the configuration from the > http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/executable-war-jar.html, > here's the output of my tomcat7:exec-war-only -X : > ... lot of lines removed ... > org.codehaus.plexus:plexus-archiver:jar:2.0.1:compile, > junit:junit:jar:4.9:compile, org.hamcrest:hamcrest-core:jar:1.1:compile, > org.codehaus.plexus:plexus-io:jar:2.0.1:compile] > [DEBUG] (f) project = MavenProject: > kam.albert.study:BasicSetup:0.0.1-SNAPSHOT @ > C:\Users\albert\workspace\BasicSetup\pom.xml > [DEBUG] (f) projectArtifact = kam.albert.study:BasicSetup:war:0.0.1-SNAPSHOT > [DEBUG] (f) remoteRepos = [ id: jvnet-nexus-releases > url: https://maven.java.net/content/repositories/releases/ >layout: default > snapshots: [enabled => true, update => daily] > releases: [enabled => true, update => daily] > ,id: central > url: http://repo1.maven.org/maven2 >layout: default > snapshots: [enabled => false, update => daily] > releases: [enabled => true, update => daily] > ] > [DEBUG] (f) serverXml = > C:\Users\albert\workspace\BasicSetup\src\main\tomcatconf\server.xml > [DEBUG] (f) tomcatConfigurationFilesDirectory = > C:\Users\albert\workspace\BasicSetup\src\main\tomcatconf > [DEBUG] -- end configuration -- > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 0.827s > [INFO] Finished at: Thu Nov 03 13:06:40 ICT 2011 > [INFO] Final Memory: 6M/15M > [INFO] > > [ERROR] Failed to execute goal > org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT:exec-war-only > (default-cli) on project BasicSetup: Execution default-cli of goal > org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT:exec-war-only > failed. NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT:exec-war-only > (default-cli) on project BasicSetup: Execution default-cli of goal > org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT:exec-war-only > failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) > 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:319) > 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(Deleg
[jira] [Closed] (MTOMCAT-168) Nullpointer exception in run mojo
[ https://issues.apache.org/jira/browse/MTOMCAT-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) closed MTOMCAT-168. -- Resolution: Incomplete please provide more infos. > Nullpointer exception in run mojo > - > > Key: MTOMCAT-168 > URL: https://issues.apache.org/jira/browse/MTOMCAT-168 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat7 >Affects Versions: 2.0-beta-1 > Environment: windows mingw >Reporter: Jiri Peinlich >Assignee: Olivier Lamy (*$^¨%`£) > > when using enpty aditionalClasspathDir tag in the the plugin settings and > running the mvn tomcat7:run mojo I got the following nullpointer exception. > I am currently learning how the whole plugin works. I got the initial plugin > configuration from here: > http://tomcat.apache.org/maven-plugin-2/run-mojo-features.html > I removed parts that are not applicable for my project but i kept the empty > additionalClasspathDir as in the example: > > > > When removing this section i did not get the exception anymore > Null Pointer exception: > [ERROR] Failed to execute goal > org.apache.tomcat.maven:tomcat7-maven-plugin:2.0- > beta-1:run (default-cli) on project ITA: Execution default-cli of goal > org.apach > e.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run failed. > NullPointerException > -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal o > rg.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run (default-cli) on > proj > ect ITA: Execution default-cli of goal > org.apache.tomcat.maven:tomcat7-maven-plu > gin:2.0-beta-1:run failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor > .java:225) > 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.buildProje > ct(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje > ct(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu > ild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl > eStarter.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(DelegatingMethodAcces > sorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun > cher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav > a:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La > uncher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java: > 352) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > default-c > li of goal org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run failed. > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default > BuildPluginManager.java:110) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor > .java:209) > ... 19 more > Caused by: java.lang.NullPointerException > at > org.apache.tomcat.maven.plugin.tomcat7.run.RunMojo.createWebappLoader > (RunMojo.java:268) > at > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.createCont > ext(AbstractRunMojo.java:415) > at > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.startConta > iner(AbstractRunMojo.java:719) > at > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.execute(Ab > stractRunMojo.java:353) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default > BuildPluginManager.java:101) > ... 20 more > [ERROR] > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > rea > d the following articles: > [ERROR] [Help 1] > http
[jira] [Closed] (MTOMCAT-152) Tomcat6 run works but Tomcat7 run fails with JDBC driver error
[ https://issues.apache.org/jira/browse/MTOMCAT-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) closed MTOMCAT-152. -- Resolution: Incomplete please provide more info. > Tomcat6 run works but Tomcat7 run fails with JDBC driver error > -- > > Key: MTOMCAT-152 > URL: https://issues.apache.org/jira/browse/MTOMCAT-152 > Project: Apache Tomcat Maven Plugin > Issue Type: Question > Components: tomcat7 >Affects Versions: 2.0 > Environment: Unix/Linux A J2EE webapp >Reporter: Jackie Gleason >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > Labels: newbie > > When I run tomcat7:run it fails but tomcat6 works fine more info here > http://stackoverflow.com/questions/10586457/tomcat7run-fails-to-bring-in-jdbc-class-using-jndi-tomcat6run-works -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Closed] (MTOMCAT-195) Plugin uploads WAR file twice
[
https://issues.apache.org/jira/browse/MTOMCAT-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) closed MTOMCAT-195.
--
Resolution: Cannot Reproduce
> Plugin uploads WAR file twice
> -
>
> Key: MTOMCAT-195
> URL: https://issues.apache.org/jira/browse/MTOMCAT-195
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
> Components: tomcat6
>Affects Versions: 2.0
> Environment: Win7/64, Maven 3.0.4
>Reporter: George Smith
>Assignee: Olivier Lamy (*$^¨%`£)
>
> When I deploy my WAR using maven, the target war (exact the same one) is
> being uploaded to the server twice. Can someone explain that?
> I am using this on my module:
> {code}clean install org.apache.tomcat.maven:tomcat6-maven-plugin:2.0:redeploy
> {code}
> From the Log file
> {code =xml}
> [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ mobile-server ---
> [INFO] Packaging webapp
> [INFO] Assembling webapp [mobile-server] in
> [C:\develope\mobile\mobile-server\target\mobile-server]
> [INFO] Processing war project
> [INFO] Copying webapp resources
> [C:\develope\mobile\mobile-server\src\main\webapp]
> [INFO] Webapp assembled in [241 msecs]
> [INFO] Building war: C:\develope\mobile\mobile-server\target\mobile-server.war
> [INFO]
> [INFO] <<< tomcat6-maven-plugin:2.0:redeploy (default-cli) @ mobile-server <<<
> [INFO]
> [INFO] --- tomcat6-maven-plugin:2.0:redeploy (default-cli) @ mobile-server
> ---
> [INFO] Deploying war to http://myserver.eu/pra-mobile-server
> Uploading:
> http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
> Uploaded:
> http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
> (12678 KB at 49.3 KB/sec)
> Uploading:
> http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
> Uploaded:
> http://myserver.eu/manager-test/deploy?path=%2Fmobile-server&update=true
> {code}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
>
> eu.company.prj.pramobile
> mobile-parent
> ../mobile-parent/pom.xml
> 1.0-SNAPSHOT
>
> mobile-server
> war
> mobile server
>
> 1.1.2
>
>
>
> com.springsource.repository.libs-milestone
> SpringSource Enterprise Bundle Repository - libs
> http://repo.springsource.org/libs-milestone/
>
>
>
>
> ${project.groupId}
> mobile-test
> ${project.version}
> test
>
>
> ${project.groupId}
> mobile-common
> ${project.version}
>
>
>
> org.springframework
> spring-asm
> ${version.spring}
>
>
> org.springframework
> spring-aop
> ${version.spring}
>
>
> org.springframework.security
> spring-security-config
> ${version.spring}
>
>
> org.springframework
> spring-web
> ${version.spring}
>
>
> org.springframework
> spring-oxm
> ${version.spring}
>
>
> org.springframework
> spring-webmvc
> ${version.spring}
>
>
> org.springframework.security
> spring-security-web
> ${version.spring}
>
>
> commons-codec
> commons-codec
> 1.7
>
>
> javax.servlet
> jsp-api
> 2.0
> provided
>
>
> commons-io
> commons-io
> 2.4
>
>
> commons-fileupload
> commons-fileupload
> 1.2.2
>
>
> javax.servlet
> servlet-api
> 2.5
> provided
>
>
> javax.servlet
> jstl
> 1.1.2
> provided
>
>
> taglibs
> standard
> 1.1.2
> provided
>
>
> commons-httpclient
> commons-httpclient
> 3.1
>
>
> net.sf.ehcache
> ehcache
> 1.6.1
>
>
> org.springmodules
> spring-modules-cache
> 0.8a
>
>
>
> org.springframework
> spring
>
>
> gigaspaces
> gigaspaces-ce
>
>
> jini
> jsk-lib
>
>
> jini
> jsk-platform
>
>
> jini
> mahalo
>
>
> jini
> reggie
>
>
> jini
> start
>
>
svn commit: r1432092 - in /tomcat/sandbox/rewrite: patch trunk/rewrite.xml
Author: remm Date: Fri Jan 11 15:30:04 2013 New Revision: 1432092 URL: http://svn.apache.org/viewvc?rev=1432092&view=rev Log: - Drop the patch (now integrated). - Add the docs page, based a lot on the mod_rewrite docs. Added: tomcat/sandbox/rewrite/trunk/rewrite.xml (with props) Removed: tomcat/sandbox/rewrite/patch Added: tomcat/sandbox/rewrite/trunk/rewrite.xml URL: http://svn.apache.org/viewvc/tomcat/sandbox/rewrite/trunk/rewrite.xml?rev=1432092&view=auto == Binary file - no diff available. Propchange: tomcat/sandbox/rewrite/trunk/rewrite.xml -- svn:mime-type = application/xml - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Closed] (MTOMCAT-107) restore a simple tomcat plugin with version scheme in for operations non dependent on the tomcat version
[ https://issues.apache.org/jira/browse/MTOMCAT-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) closed MTOMCAT-107. -- Resolution: Not A Problem > restore a simple tomcat plugin with version scheme in for operations non > dependent on the tomcat version > > > Key: MTOMCAT-107 > URL: https://issues.apache.org/jira/browse/MTOMCAT-107 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement > Components: commons-lib >Reporter: Olivier Lamy (*$^¨%`£) >Assignee: Olivier Lamy (*$^¨%`£) > > some remote operations (deploy/undeploy etc...) doesn't depend on the tomcat > api. > so having back a tomcat mojo can ease here instead of having tomcat6:deploy > or tomcat7:deploy having a simple tomcat:deploy (the deploy url will be > adjust by the user) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Closed] (MTOMCAT-14) Support multiple web resources as per maven-war-plugin
[ https://issues.apache.org/jira/browse/MTOMCAT-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) closed MTOMCAT-14. - Resolution: Not A Problem you can set the resources folder from src/main/webapp to target/webapp and you'll have all the official resources collected by maven-war-plugin > Support multiple web resources as per maven-war-plugin > -- > > Key: MTOMCAT-14 > URL: https://issues.apache.org/jira/browse/MTOMCAT-14 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement >Reporter: Mark Hobson >Assignee: Mark Hobson >Priority: Minor > > The mojos need to support multiple web resource directories as per the > maven-war-plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Closed] (MTOMCAT-73) deploy-only goal with exliplicit contextFile-Param set leads to FileNotFoundException
[ https://issues.apache.org/jira/browse/MTOMCAT-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) closed MTOMCAT-73. - Resolution: Cannot Reproduce > deploy-only goal with exliplicit contextFile-Param set leads to > FileNotFoundException > - > > Key: MTOMCAT-73 > URL: https://issues.apache.org/jira/browse/MTOMCAT-73 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug >Affects Versions: 1.1 > Environment: Maven (client): Windows XP (32bit) > Server: Linux (Suse) > Tomcat: 6.0.26 >Reporter: Niels Kausche > > Deploying a context.xml as contextFile-Parameter leads to a > FileNotFoundException either on the client (maven command line) or on the > server (catalina.out). > Always with the same filename. Ist the given context.xml-File transferred to > the server or just the file name? > Hier is my Plugin-Configuration: > > org.codehaus.mojo > tomcat-maven-plugin > 1.1 > > > / > context > //META-INF/tomcat//context.xml > > > I am using the task to deploy to our development, test, or production server > using different jndi configurations in different context.xml files. > Here the server stack trace (catalina.out): > (you see, it is the original local file name from the build server. And it is > correct.) > java.io.FileNotFoundException: > /C:/Entwicklung/projekte-rivotool/dr.servicecockpit.rivo.web/target/dr.servicecockpit.rivo.web-1.2.19/META-INF/tomcat/etest/ > ccontext.xml (No such file or directory) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:106) > at > org.apache.catalina.manager.ManagerServlet.copyInternal(ManagerServlet.java:1671) > at > org.apache.catalina.manager.ManagerServlet.copy(ManagerServlet.java:1632) > at > org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:836) > at > org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:351) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:558) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852) > at > org.apache.coyote.http11.Http11ProtocolHttp11ConnectionHandler.process(Http11Protocol.java:588) > at > org.apache.tomcat.util.net.JIoEndpointWorker.run(JIoEndpoint.java:489) > at java.lang.Thread.run(Thread.java:619) > Exception in thread "net.sf.ehcache.CacheManager@647fc8b2" > java.lang.NullPointerException > at > org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:204) > at > net.sf.ehcache.util.UpdateChecker.checkForUpdate(UpdateChecker.java:62) > at net.sf.ehcache.util.UpdateChecker.run(UpdateChecker.java:50) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Closed] (MTOMCAT-59) catalina.properties and catalina.policy are ignored
[
https://issues.apache.org/jira/browse/MTOMCAT-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) closed MTOMCAT-59.
-
Resolution: Not A Problem
> catalina.properties and catalina.policy are ignored
> ---
>
> Key: MTOMCAT-59
> URL: https://issues.apache.org/jira/browse/MTOMCAT-59
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: Maven 2.2.1, Tomcat 6.0.20
>Reporter: Torben Knerr
> Labels: tocheck
>
> Any configuration that is done in {{catalina.properties}} or
> {{catalina.policy}} is not considered when Tomcat is started via the
> tomcat-maven-plugin. I have tried to pass the system property
> {{-Dcatalina.config=/path/to/catalina.properties}}, but it is actually never
> read in the plugin code.
> The reason seems to be that in {{AbstractRunMojo.java}} the Tomcat container
> is created using
> {code}
> ...
> container = new Catalina();
> ...
> {code}
> When starting Tomcat manually using {{catalina.bat/sh}}, the container is
> started via
> {{[Bootstrap.java|http://www.docjar.com/html/api/org/apache/catalina/startup/Bootstrap.java.html]}}
> which -- in addition to creating a new Catalina instance -- reads and
> processes the two above mentioned files. In our special case we are relying
> on the {{shared.loader=/path/to/shared/libs/*.jar}} configuration in
> {{catalina.properties}}.
> Is this a known/intended issue? Is this something that we can hope for a fix
> in a future version?
> Cheers and kind regards,
> Torben
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Closed] (MTOMCAT-47) Goal "exploded" does deploys before undeploy is finished
[
https://issues.apache.org/jira/browse/MTOMCAT-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) closed MTOMCAT-47.
-
Resolution: Not A Problem
must not be a problem with recent version.
> Goal "exploded" does deploys before undeploy is finished
>
>
> Key: MTOMCAT-47
> URL: https://issues.apache.org/jira/browse/MTOMCAT-47
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
>Affects Versions: 1.0-beta-1
> Environment: Apache Maven 3.0-alpha-4 (r835944; 2009-11-13
> 19:06:31+0100)
> Java version: 1.6.0_17
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows"
>Reporter: Mark Michaelis
>
> For integration tests we want to deploy an exploded webapp into tomcat. But
> this fails if we deployed the webapp in a previous run as the deployment
> seems to start before the undeployment is actually done.
> This is the code snippet we use for deployment. Mind the "update=true" which
> should do the undeployment:
> {code:xml}
>
> org.codehaus.mojo
> tomcat-maven-plugin
> 1.0-beta-1
>
>
> deploy
>
> exploded
>
> compile
>
> http://localhost:8001/manager
> some
> someother
> /webapp
> /
> true
>
>
>
>
> {code}
> From the log:
> {noformat}
> [INFO] --- tomcat-maven-plugin:1.0-beta-1:exploded (deploy) @
> tomcat-deployment ---
> [DEBUG] Created new class realm
> plugin>org.codehaus.mojo:tomcat-maven-plugin:1.0-beta-1
> [DEBUG] Populating plugin realm for
> org.codehaus.mojo:tomcat-maven-plugin:1.0-beta-1
> [DEBUG] Included:
> org.codehaus.mojo:tomcat-maven-plugin:maven-plugin:1.0-beta-1
> [DEBUG] Excluded: org.apache.maven:maven-plugin-api:jar:2.0
> [DEBUG] Excluded: org.apache.maven:maven-artifact-manager:jar:2.0
> [DEBUG] Excluded: org.apache.maven:maven-repository-metadata:jar:2.0
> [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:1.0.4
> [DEBUG] Excluded: org.apache.maven:maven-artifact:jar:2.0
> [DEBUG] Excluded:
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8
> [DEBUG] Excluded: classworlds:classworlds:jar:1.1-alpha-2
> [DEBUG] Excluded: org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
> [DEBUG] Included: commons-codec:commons-codec:jar:1.3
> [DEBUG] Included: org.apache.tomcat:catalina:jar:6.0.16
> [DEBUG] Included: org.apache.tomcat:servlet-api:jar:6.0.16
> [DEBUG] Included: org.apache.tomcat:juli:jar:6.0.16
> [DEBUG] Included: org.apache.tomcat:annotations-api:jar:6.0.16
> [DEBUG] Included: org.apache.tomcat:catalina-ha:jar:6.0.16
> [DEBUG] Included: org.apache.tomcat:coyote:jar:6.0.16
> [DEBUG] Included: org.apache.tomcat:tribes:jar:6.0.16
> [DEBUG] Included: org.apache.tomcat:el-api:jar:6.0.16
> [DEBUG] Included: org.apache.tomcat:jasper:jar:6.0.16
> [DEBUG] Included: org.apache.tomcat:jsp-api:jar:6.0.16
> [DEBUG] Included: org.apache.tomcat:jasper-jdt:jar:6.0.16
> [DEBUG] Included: org.apache.tomcat:jasper-el:jar:6.0.16
> [DEBUG] Included: org.apache.tomcat:dbcp:jar:6.0.16
> [DEBUG] Configuring mojo
> 'org.codehaus.mojo:tomcat-maven-plugin:1.0-beta-1:exploded' with basic
> configurator -->
> [DEBUG] (f) charset = ISO-8859-1
> [DEBUG] (f) contextFile = ...\META-INF\context.xml
> [DEBUG] (f) mode = war
> [DEBUG] (f) packaging = war
> [DEBUG] (f) password = ...
> [DEBUG] (f) path = /editor
> [DEBUG] (f) update = true
> [DEBUG] (f) url = http://localhost:8001/manager
> [DEBUG] (f) username = ...
> [DEBUG] (f) version = 1.0-beta-1
> [DEBUG] (f) warDirectory = ...\webapp
> [DEBUG] -- end configuration --
> [INFO] Deploying war to http://localhost:8001/editor
> [DEBUG] No server specified for authentication - using defaults
> [INFO] OK - Undeployed application at context path /editor
> [INFO] FAIL - Application already exists at path /editor
> {noformat}
> Thus the deployment fails because undeployment is still incomplete.
> *Workarounds:*
> * Manually clean before doing the deployment.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Closed] (MTOMCAT-9) Read WarFile configuration from warName of maven-war-plugin
[ https://issues.apache.org/jira/browse/MTOMCAT-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy (*$^¨%`£) closed MTOMCAT-9. Resolution: Not A Problem done with recent version > Read WarFile configuration from warName of maven-war-plugin > --- > > Key: MTOMCAT-9 > URL: https://issues.apache.org/jira/browse/MTOMCAT-9 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement >Reporter: Matteo TURRA > > To bulid war file maven-war-plugin is used. > Configurations of this plugin contains information about the war filename in > the WarFile parameter, Tomcat plugin could read this parameter by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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 54406] NIO and BIO connectors handle unsupported SSL ciphers and sslEnabledProtocols differently
https://issues.apache.org/bugzilla/show_bug.cgi?id=54406 --- Comment #1 from Christopher Schultz --- +1 There was a post to the users' list recently where a user attempted to configure JSSE using OpenSSL-style cipher names. The result was evidently that the Connector used the default list of ciphers. I assert that this is a security problem. -- 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: Rewrite functionality for 8
Hi Remy, On 09.01.2013 16:04, Remy Maucherat wrote: > Hi, > > I ported a valve providing mod_rewrite functionality (most of it) for > Tomcat "8", and committed it in the sandbox. This could be easily placed > in the main repository, where it would provide an additional item in the > "new features" department for this major release. > > I have a documentation page for it that could be included. The basics is > that it uses a rewrite.properties that has the same contents as the > configuration for mod_rewrite. The rewrite.properties is placed in the > host config folder if the valve is declared in a Host, or in WEB-INF in > the webapp if declared in a Context. > > The main differences with mod_rewrite are: > - (the big one) no proxy flag > - no SSL attributes > - less file related flags available > - allows virtual host rewriting using a host flag (it replaces the host > header instead of the URL and maps again) > Point 2 and 3 are probably relatively easy to fix, while obviously a > proxy is a more involving endeavor. > > There are rewrite solutions out there already, but this one does not use > complex tricks (because it can simply start over request processing > instead of doing more complex request dispatching, which also impacts > the Servlet state), and is mod_rewrite compatible. > > Comments ? Is it nice or useless ? I only had a look at the code and didn't play with it yet. I'm positively impressed how complete w.r.t. mod_rewrite compatibility it looks and personally I think it is nice and useful. One question that came to my mind and which I did not yet try to find the answer myself is the merging behavior of the rules if the valve is configured at host and context level. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Rewrite functionality for 8
On Fri, 2013-01-11 at 18:34 +0100, Rainer Jung wrote: > I only had a look at the code and didn't play with it yet. I'm > positively impressed how complete w.r.t. mod_rewrite compatibility it > looks and personally I think it is nice and useful. Thanks ! > One question that came to my mind and which I did not yet try to find > the answer myself is the merging behavior of the rules if the valve is > configured at host and context level. I didn't really think about this scenario. There's no direct interaction between the two valves. For the current implementation, if the valve in the context has its config file in /WEB-INF/rewrite.properties, it will use that. If not, it will try to use conf/Catalina/localhost/rewrite.properties (the valve defined on the host will only look there). But there's no rule inheritance or something like it. The two rewrite valves will do their processing only once (the valve has a thread local boolean to avoid rewriting more than once per request). If both valves do a rewrite, here's the processing (assuming the mapping of the host and context doesn't change, since the request is pretty much allowed to bounce between hosts and contexts as long as rewriting occurs in each host or context): adapter (mapping 1) -> rewrite in host -> adapter (mapping 2) -> rewrite in context -> adapter (mapping 3) -> webapp Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1432092 - in /tomcat/sandbox/rewrite: patch trunk/rewrite.xml
2013/1/11 : > Author: remm > Date: Fri Jan 11 15:30:04 2013 > New Revision: 1432092 > > URL: http://svn.apache.org/viewvc?rev=1432092&view=rev > Log: > - Drop the patch (now integrated). > - Add the docs page, based a lot on the mod_rewrite docs. > > Added: > tomcat/sandbox/rewrite/trunk/rewrite.xml (with props) > Removed: > tomcat/sandbox/rewrite/patch > > Added: tomcat/sandbox/rewrite/trunk/rewrite.xml > URL: > http://svn.apache.org/viewvc/tomcat/sandbox/rewrite/trunk/rewrite.xml?rev=1432092&view=auto > == > Binary file - no diff available. > The above is because of the mime type. The correct mime type here should be "text/xml", as it is a human-readable file, not a data one. > Propchange: tomcat/sandbox/rewrite/trunk/rewrite.xml > -- > svn:mime-type = application/xml - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1431444 - in /tomcat/trunk/java/org/apache/catalina/connector: CoyoteAdapter.java Request.java
2013/1/10 Mark Thomas :
> On 10/01/2013 15:45, r...@apache.org wrote:
>> Author: remm
>> Date: Thu Jan 10 15:45:47 2013
>> New Revision: 1431444
>>
>> URL: http://svn.apache.org/viewvc?rev=1431444&view=rev
>
>
>
>> +// The URL is chars or String, and has been sent using an
>> in-memory
>> +// protocol handler, we have to assume the URL has been properly
>> +// decoded already
>> +decodedURI.toChars();
>> +// Remove any path parameters
>> +CharChunk uriCC = decodedURI.getCharChunk();
>> +int semicolon = uriCC.indexOf(';');
>> +if (semicolon > 0) {
>> +decodedURI.setChars
>> +(uriCC.getBuffer(), uriCC.getStart(), semicolon);
>> +}
>
> The code is based on the assumption that path parameters will only ever
> appear at the end of the URL. While that is the typically case, it is
> not guaranteed to be the case.
>
> While I would prefer to see correct path parameter parsing, as a minimum
> there needs to be a something along the lines of a TODO comment at that
> point in the code to highlight the short-cut that is being taken.
>
About the updated comment:
> -// Remove any path parameters
> +// Remove all path parameters; any needed path parameter should
> be set
> +// using the request object rather than passing it in the URL
If we do not expect path parameters to be passed here, I would better
throw new IllegalArgumentException() rather than silently changing the
data.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-189) additionalClassesDirs parameter handling expanded to include run and run-war goals
[ https://issues.apache.org/jira/browse/MTOMCAT-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551530#comment-13551530 ] Glen Mazza commented on MTOMCAT-189: Great to hear, if we can get people to do things the "official" Tomcat way (VirtualWebappLoader) it's fewer moving parts on the plugin's end as well as keeps the pressure & JIRA requests on the Tomcat team (where it needs to be :) to make sure their context.xml handles everything people need to do, as well as handles it easily/efficiently. > additionalClassesDirs parameter handling expanded to include run and run-war > goals > -- > > Key: MTOMCAT-189 > URL: https://issues.apache.org/jira/browse/MTOMCAT-189 > Project: Apache Tomcat Maven Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Nick Lloyd >Priority: Minor > Fix For: 2.1 > > Attachments: tomcat-run_runWar.patch > > > I contributed the original patch to add the functionality to add additional > directories to the classpath for the run goal. This patch expands on that, > adding the functionality to both run and run-war goals in the tomcat6 and > tomcat7 plugin artifacts. > Please review and incorporate as you see fit. My organization is using this > internally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
svn commit: r1432298 - /tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
Author: markt
Date: Fri Jan 11 21:45:06 2013
New Revision: 1432298
URL: http://svn.apache.org/viewvc?rev=1432298&view=rev
Log:
Remove unnecessary method call.
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?rev=1432298&r1=1432297&r2=1432298&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java Fri Jan
11 21:45:06 2013
@@ -560,7 +560,6 @@ public class Http11NioProcessor extends
if (socket==null || socket.getSocket().getAttachment(false)==null)
{
return;
}
-NioEndpoint.KeyAttachment attach =
(NioEndpoint.KeyAttachment)socket.getSocket().getAttachment(false);
RequestInfo rp = request.getRequestProcessor();
if (rp.getStage() != org.apache.coyote.Constants.STAGE_SERVICE) {
// Close event for this processor triggered by request
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1432355 - in /tomcat/tc6.0.x/trunk: ./ STATUS.txt bin/setclasspath.sh
Author: schultz Date: Sat Jan 12 01:37:43 2013 New Revision: 1432355 URL: http://svn.apache.org/viewvc?rev=1432355&view=rev Log: Back-port trunk:r1430567: Use java_home if exists to determine JAVA_HOME on Mac OS X. Modified: tomcat/tc6.0.x/trunk/ (props changed) tomcat/tc6.0.x/trunk/STATUS.txt tomcat/tc6.0.x/trunk/bin/setclasspath.sh Propchange: tomcat/tc6.0.x/trunk/ -- Merged /tomcat/trunk:r1430567 Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1432355&r1=1432354&r2=1432355&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Sat Jan 12 01:37:43 2013 @@ -108,13 +108,6 @@ PATCHES PROPOSED TO BACKPORT: +1: markt, kkolinko, schultz -1: -* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54390 - Use /usr/libexec/java_home to determine JAVA_HOME on Mac OS X - Back-port r1430567: http://svn.apache.org/viewvc?view=revision&revision=r1430567 - Also adaptation of r1430599 for changelog.xml update. - +1: schultz, kkolinko, markt - -1: - * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54382 Avoid NPE with an empty SSI directive http://svn.apache.org/viewvc?view=revision&revision=1430553 Modified: tomcat/tc6.0.x/trunk/bin/setclasspath.sh URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/bin/setclasspath.sh?rev=1432355&r1=1432354&r2=1432355&view=diff == --- tomcat/tc6.0.x/trunk/bin/setclasspath.sh (original) +++ tomcat/tc6.0.x/trunk/bin/setclasspath.sh Sat Jan 12 01:37:43 2013 @@ -23,9 +23,12 @@ # Make sure prerequisite environment variables are set if [ -z "$JAVA_HOME" -a -z "$JRE_HOME" ]; then - # Bugzilla 37284 (reviewed). if $darwin; then -if [ -d "/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home" ]; then +# Bugzilla 54390 +if [ -x '/usr/libexec/java_home' ] ; then + export JAVA_HOME=`/usr/libexec/java_home` +# Bugzilla 37284 (reviewed). +elif [ -d "/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home" ]; then export JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home" fi else - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54390] Use 'java_home' on Mac OS X to auto-detect JAVA_HOME
https://issues.apache.org/bugzilla/show_bug.cgi?id=54390 --- Comment #10 from Christopher Schultz --- Fixed in Tomcat 6.0.x. Will be in 6.0.37. -- 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: r1432356 - /tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Author: schultz Date: Sat Jan 12 01:40:43 2013 New Revision: 1432356 URL: http://svn.apache.org/viewvc?rev=1432356&view=rev Log: Updated changelog to include fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=54390 : Use java_home on Mac OS X. Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=1432356&r1=1432355&r2=1432356&view=diff == --- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Sat Jan 12 01:40:43 2013 @@ -91,6 +91,10 @@ configuration if someone wants to move the output directory elsewhere (e.g. out of the source tree). (kkolinko) + +54390: Use 'java_home' on Mac OS X to auto-detect JAVA_HOME. +(schultz) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
