Tomcat7-maven-plugin: Failed to initialize end point associated with ProtocolHandler
Hello @all, we were using tomcat-maven-plugin which uses Tomcat 6 until last week to run our API written in Java and to test around with it. This worked very well for ages and we got used to it but now we decided to switch to tomcat7-maven-plugin. We used the Jersey Java Framework to build our API. When we wanted to "redeploy" we stopped the running "mvn tomcat:run" process in our console and started it again after pulling the new code via git. After a while the API grew bigger and it took a lot of time to prepare the start of the API (caching, etc) - up to 10min. So we decided to start up the new version of the API in a separate console window (we use byobu on our server) and define in our contextInitialized()-Method right before it returns a special command to the Linux system to kill the old API process. After the old API was killed the contextInitialized()-Method returned and the new version of the API started at the desired port. Now after the switch to tomcat7 this procedure doesn't work any more. The problem is, that the tomcat7 get hold of the desired port very early: [INFO] --- tomcat7-maven-plugin:2.2:run (default-cli) @ core --- [INFO] Running war on http://localhost:8686/ [INFO] Creating Tomcat server configuration at /opt/dev/target/tomcat [INFO] create webapp with contextPath: Feb 03, 2016 2:50:14 PM org.apache.coyote.AbstractProtocol init INFORMATION: Initializing ProtocolHandler ["http-bio-8686"] Feb 03, 2016 2:50:14 PM org.apache.coyote.AbstractProtocol init SCHWERWIEGEND: Failed to initialize end point associated with ProtocolHandler ["http-bio-8686"] java.net.BindException: Die Adresse wird bereits verwendet :8686 at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:407) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:623) So my question is right now: why is Tomcat 6 grabbing the port very late, after contextInitialized() is done, and Tomcat 7 is doing this so early? Is there a configuration method to let Tomcat 7 start the port after contextInitialized() is done? Thank you for your help, best Simon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin using standardjarscanner instead of webappclassloader
It turns out I was mis-understanding the problem here by just looking at
the logging output. The StandardJarScanner is always run before the
WebAppClassLoader, but only logs if it detects errors. I've just
rephrased the question to make it clearer what my problem is and sent out
a separate e-mail about it.
On 2/4/15, 8:13 PM, Alexander Johnson alexjohn...@expedia.com wrote:
Original question here:
http://stackoverflow.com/questions/28181602/whats-the-difference-between-w
ebappclassloader-and-standardjarscanner
I'm able to run my team's webapp on my local machine using the
tomcat7-maven-plugin. Unfortunately when I attempt to do the same on the
build server it breaks. This is a blocking issue for our team, but none
of us are able to figure it out. Nobody on Stack Overflow has been able
to help either.
Here is the tomcat7-maven-plugin configuration in our project:
profiles
!-- Version 2.2 of the Tomcat7 plugin does not support skip (version
2.3
purportedly will). As an alternative, we will only include the
Tomcat7 plugin
and its goals in this profile which is activated by our own
parameter. Once
skip is supported we can delete this profile and move the
plugin/executions
to the main plugin category for this pom file. --
profile
idstart-tomcat-for-integration-tests/id
activation
property
name!${skipTomcat}/name
/property
/activation
build
plugins
!-- We use this plugin to launch Tomcat and locally host the
pages
we just built so that we can run integration tests against
them. Note that
configuration for this plugin is stored inside the project
itself under
src/test/resources/com/MyCompany/MyOrg/MyProject/ui/automation/tomcat7/con
f
and does not require additional installation or
configuration of the actual
Tomcat application. This is done to minimize configuration
efforts and avoid
interfering with normal Tomcat operations. --
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version2.2/version
configuration
ajpPort8009/ajpPort
backgroundProcessorDelay2/backgroundProcessorDelay
classLoaderClassorg.apache.catalina.loader.WebappClassLoader/classLoade
rClass
configurationDir${basedir}/src/test/resources/com/MyCompany/MyOrg/MyProj
ect/ui/automation/tomcat7/configurationDir
contextFile${basedir}/src/test/resources/com/MyCompany/MyOrg/MyProject/u
i/automation/tomcat7/conf/context.xml/contextFile
contextReloadablefalse/contextReloadable
forkfalse/fork
hostNamelocalhost/hostName
httpsPort8443/httpsPort
ignorePackagingfalse/ignorePackaging
jarScanAllDirectoriestrue/jarScanAllDirectories
addWarDependenciesInClassloadertrue/addWarDependenciesInClassloader
path/contentmain/path
port8080/port
serverXml${basedir}/src/test/resources/com/MyCompany/MyOrg/MyProject/ui/
automation/tomcat7/conf/server.xml/serverXml
!-- NOTE: 'skip' will not be implemented for Tomcat7
plugin until
the 2.3 release. This is a placeholder. --
skip${skipTomcat}/skip
tomcatUsers${basedir}/src/test/resources/com/MyCompany/MyOrg/MyProject/u
i/automation/tomcat7/conf/tomcat-users.xml/tomcatUsers
tomcatWebXml${basedir}/src/test/resources/com/MyCompany/MyOrg/MyProject/
ui/automation/tomcat7/conf/web.xml/tomcatWebXml
useNamingtrue/useNaming
useTestClasspathtrue/useTestClasspath
updatetrue/update
warDirectory${original.build.directory}/${original.build.finalName}/war
Directory
/configuration
dependencies
dependency
groupIdorg.apache.tomcat.embed/groupId
artifactIdtomcat-embed-core/artifactId
version${tomcat.version}/version
/dependency
dependency
groupIdorg.apache.tomcat/groupId
artifactIdtomcat-util/artifactId
version${tomcat.version}/version
/dependency
dependency
groupIdorg.apache.tomcat/groupId
artifactIdtomcat-coyote/artifactId
version${tomcat.version}/version
/dependency
dependency
groupIdorg.apache.tomcat/groupId
artifactIdtomcat-api/artifactId
version${tomcat.version}/version
/dependency
tomcat7-maven-plugin using standardjarscanner instead of webappclassloader
Original question here:
http://stackoverflow.com/questions/28181602/whats-the-difference-between-webappclassloader-and-standardjarscanner
I'm able to run my team's webapp on my local machine using the
tomcat7-maven-plugin. Unfortunately when I attempt to do the same on the build
server it breaks. This is a blocking issue for our team, but none of us are
able to figure it out. Nobody on Stack Overflow has been able to help either.
Here is the tomcat7-maven-plugin configuration in our project:
profiles
!-- Version 2.2 of the Tomcat7 plugin does not support skip (version 2.3
purportedly will). As an alternative, we will only include the Tomcat7
plugin
and its goals in this profile which is activated by our own parameter.
Once
skip is supported we can delete this profile and move the
plugin/executions
to the main plugin category for this pom file. --
profile
idstart-tomcat-for-integration-tests/id
activation
property
name!${skipTomcat}/name
/property
/activation
build
plugins
!-- We use this plugin to launch Tomcat and locally host the pages
we just built so that we can run integration tests against them.
Note that
configuration for this plugin is stored inside the project
itself under
src/test/resources/com/MyCompany/MyOrg/MyProject/ui/automation/tomcat7/conf
and does not require additional installation or configuration of
the actual
Tomcat application. This is done to minimize configuration
efforts and avoid
interfering with normal Tomcat operations. --
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version2.2/version
configuration
ajpPort8009/ajpPort
backgroundProcessorDelay2/backgroundProcessorDelay
classLoaderClassorg.apache.catalina.loader.WebappClassLoader/classLoaderClass
configurationDir${basedir}/src/test/resources/com/MyCompany/MyOrg/MyProject/ui/automation/tomcat7/configurationDir
contextFile${basedir}/src/test/resources/com/MyCompany/MyOrg/MyProject/ui/automation/tomcat7/conf/context.xml/contextFile
contextReloadablefalse/contextReloadable
forkfalse/fork
hostNamelocalhost/hostName
httpsPort8443/httpsPort
ignorePackagingfalse/ignorePackaging
jarScanAllDirectoriestrue/jarScanAllDirectories
addWarDependenciesInClassloadertrue/addWarDependenciesInClassloader
path/contentmain/path
port8080/port
serverXml${basedir}/src/test/resources/com/MyCompany/MyOrg/MyProject/ui/automation/tomcat7/conf/server.xml/serverXml
!-- NOTE: 'skip' will not be implemented for Tomcat7 plugin
until
the 2.3 release. This is a placeholder. --
skip${skipTomcat}/skip
tomcatUsers${basedir}/src/test/resources/com/MyCompany/MyOrg/MyProject/ui/automation/tomcat7/conf/tomcat-users.xml/tomcatUsers
tomcatWebXml${basedir}/src/test/resources/com/MyCompany/MyOrg/MyProject/ui/automation/tomcat7/conf/web.xml/tomcatWebXml
useNamingtrue/useNaming
useTestClasspathtrue/useTestClasspath
updatetrue/update
warDirectory${original.build.directory}/${original.build.finalName}/warDirectory
/configuration
dependencies
dependency
groupIdorg.apache.tomcat.embed/groupId
artifactIdtomcat-embed-core/artifactId
version${tomcat.version}/version
/dependency
dependency
groupIdorg.apache.tomcat/groupId
artifactIdtomcat-util/artifactId
version${tomcat.version}/version
/dependency
dependency
groupIdorg.apache.tomcat/groupId
artifactIdtomcat-coyote/artifactId
version${tomcat.version}/version
/dependency
dependency
groupIdorg.apache.tomcat/groupId
artifactIdtomcat-api/artifactId
version${tomcat.version}/version
/dependency
dependency
groupIdorg.apache.tomcat/groupId
artifactIdtomcat-jdbc/artifactId
version${tomcat.version}/version
/dependency
dependency
groupIdorg.apache.tomcat/groupId
artifactIdtomcat-dbcp/artifactId
version
Re: tomcat7-maven-plugin and mail
The war itself deploys to a Tomcat instance on a testing machine just fine - that Tomcat includes the javamail and activation in it's installation hence they are declared as provided in our project's POM. This boils down to not knowing if the extra dependencies within the maven plugin are actually deployed and deployed prior to booting the war archive. On 2 December 2014 at 19:11, Chris Gamache cgama...@gmail.com wrote: Unless you're doing something unconventional, it shouldn't be painful. We may getting off-topic, but if you would like to post your project pom and any parents, I'll take a peek and see if there's anything that leaps out at me. My gut says your build is omitting dependencies that Maven expects to be in the classpath but they aren't in your Tomcat environment. When you unpack your war, do you see all the jarfiles you expect in WEB-INF/libs? Look for missing jars or multiple versions of the same dependencies (that's a dog that has bitten me many times). If the jars aren't there they would have to be in the Java runtime classpath or in Tomcat's global classpath, yes? You mentioned integration testing... Your war works with other servlet containers? Perhaps there is a dependency that the other containers provide as a standard that tomcat does not. On Tue, Dec 2, 2014 at 4:52 AM, James Green james.mk.gr...@gmail.com wrote: What you wrote as a set of suggestions was my original attempt. Then I read (possibly spuriously) that Tomcat ignored either mailx or activation when shipped inside a WAR, and that if both Tomcat (via it's lib/) and the WAR contained either of those then the duplicate JAR would result in an error. So as a result I spotted someone on SO suggesting the above for the maven-war-plugin. However that does not work either. I am aware of the transitive dependencies thing, I was minded anyway to mark those two as provided and ship them to Tomcat via Puppet. I am however still unable to integration test against Tomcat as it cannot find the class. This appears to be far more painful than expected :( James On 1 December 2014 at 18:05, Chris Gamache cgama...@gmail.com wrote: A few things you might take a look at. I don't think the Tomcat plugin requires javax.mail or activation by itself. That part of the plugin definition probably isn't doing what you intended it to do. I think you might want to remove the extraDependencies section. By including project ... dependencies dependency groupIdorg.apache.commons/groupId artifactIdcommons-email/artifactId versionyour_version_here/version /dependency /dependencies /project You'll get javax.mail as a transitive dependency. The Maven WAR plugin is smart enough to include your dependencies and their transitive dependencies in your war file. Even though you're looking up the mail Session using JNDI, I still think you'll be needing the commons email as a compiled dependency unless you've put it in the classpath yourself. If you have put it in the classpath, using provided scope will not include transitive dependencies, of which there are several for commons-email. If that's the route you want to go, you'll need to download and put commons-email's dependencies in the classpath along with commons-email. IMO and FWIW, self-managing dependencies like this complicates your project deployment scheme. The size overhead of including your project's dependencies in the each war is so worth it when Maven can handle making sure the dependency artifacts are where they need to be. On Mon, Dec 1, 2014 at 8:17 AM, James Green james.mk.gr...@gmail.com wrote: Is there a way of getting this to work? We have a Maven project that depends on Apache's commons-email. We use JNDI to look up a mail Session. We use the following in our POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration failOnMissingWebXmlfalse/failOnMissingWebXml /configuration /plugin plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.2/version configuration contextFiletomcat/context.xml/contextFile port9000/port path/foo/path forktrue/fork extraDependencies extraDependency groupIdjavax.mail/groupId artifactIdmail/artifactId version1.4/version /extraDependency
Re: tomcat7-maven-plugin and mail
What you wrote as a set of suggestions was my original attempt. Then I read (possibly spuriously) that Tomcat ignored either mailx or activation when shipped inside a WAR, and that if both Tomcat (via it's lib/) and the WAR contained either of those then the duplicate JAR would result in an error. So as a result I spotted someone on SO suggesting the above for the maven-war-plugin. However that does not work either. I am aware of the transitive dependencies thing, I was minded anyway to mark those two as provided and ship them to Tomcat via Puppet. I am however still unable to integration test against Tomcat as it cannot find the class. This appears to be far more painful than expected :( James On 1 December 2014 at 18:05, Chris Gamache cgama...@gmail.com wrote: A few things you might take a look at. I don't think the Tomcat plugin requires javax.mail or activation by itself. That part of the plugin definition probably isn't doing what you intended it to do. I think you might want to remove the extraDependencies section. By including project ... dependencies dependency groupIdorg.apache.commons/groupId artifactIdcommons-email/artifactId versionyour_version_here/version /dependency /dependencies /project You'll get javax.mail as a transitive dependency. The Maven WAR plugin is smart enough to include your dependencies and their transitive dependencies in your war file. Even though you're looking up the mail Session using JNDI, I still think you'll be needing the commons email as a compiled dependency unless you've put it in the classpath yourself. If you have put it in the classpath, using provided scope will not include transitive dependencies, of which there are several for commons-email. If that's the route you want to go, you'll need to download and put commons-email's dependencies in the classpath along with commons-email. IMO and FWIW, self-managing dependencies like this complicates your project deployment scheme. The size overhead of including your project's dependencies in the each war is so worth it when Maven can handle making sure the dependency artifacts are where they need to be. On Mon, Dec 1, 2014 at 8:17 AM, James Green james.mk.gr...@gmail.com wrote: Is there a way of getting this to work? We have a Maven project that depends on Apache's commons-email. We use JNDI to look up a mail Session. We use the following in our POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration failOnMissingWebXmlfalse/failOnMissingWebXml /configuration /plugin plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.2/version configuration contextFiletomcat/context.xml/contextFile port9000/port path/foo/path forktrue/fork extraDependencies extraDependency groupIdjavax.mail/groupId artifactIdmail/artifactId version1.4/version /extraDependency extraDependency groupIdjavax.activation/groupId artifactIdactivation/artifactId version1.1.1/version /extraDependency /extraDependencies /configuration executions execution idstart/id goals goalrun-war-only/goal /goals phasepre-integration-test/phase /execution execution idshutdown/id goals goalshutdown/goal /goals phasepost-integration-test/phase /execution /executions /plugin Deployment fails with the following: java.lang.ClassNotFoundException: javax.mail.Session I have both mail and activation listed in the POM's dependencies with a scope of provided. Is further magic required? Thanks, James
Re: tomcat7-maven-plugin and mail
Unless you're doing something unconventional, it shouldn't be painful. We may getting off-topic, but if you would like to post your project pom and any parents, I'll take a peek and see if there's anything that leaps out at me. My gut says your build is omitting dependencies that Maven expects to be in the classpath but they aren't in your Tomcat environment. When you unpack your war, do you see all the jarfiles you expect in WEB-INF/libs? Look for missing jars or multiple versions of the same dependencies (that's a dog that has bitten me many times). If the jars aren't there they would have to be in the Java runtime classpath or in Tomcat's global classpath, yes? You mentioned integration testing... Your war works with other servlet containers? Perhaps there is a dependency that the other containers provide as a standard that tomcat does not. On Tue, Dec 2, 2014 at 4:52 AM, James Green james.mk.gr...@gmail.com wrote: What you wrote as a set of suggestions was my original attempt. Then I read (possibly spuriously) that Tomcat ignored either mailx or activation when shipped inside a WAR, and that if both Tomcat (via it's lib/) and the WAR contained either of those then the duplicate JAR would result in an error. So as a result I spotted someone on SO suggesting the above for the maven-war-plugin. However that does not work either. I am aware of the transitive dependencies thing, I was minded anyway to mark those two as provided and ship them to Tomcat via Puppet. I am however still unable to integration test against Tomcat as it cannot find the class. This appears to be far more painful than expected :( James On 1 December 2014 at 18:05, Chris Gamache cgama...@gmail.com wrote: A few things you might take a look at. I don't think the Tomcat plugin requires javax.mail or activation by itself. That part of the plugin definition probably isn't doing what you intended it to do. I think you might want to remove the extraDependencies section. By including project ... dependencies dependency groupIdorg.apache.commons/groupId artifactIdcommons-email/artifactId versionyour_version_here/version /dependency /dependencies /project You'll get javax.mail as a transitive dependency. The Maven WAR plugin is smart enough to include your dependencies and their transitive dependencies in your war file. Even though you're looking up the mail Session using JNDI, I still think you'll be needing the commons email as a compiled dependency unless you've put it in the classpath yourself. If you have put it in the classpath, using provided scope will not include transitive dependencies, of which there are several for commons-email. If that's the route you want to go, you'll need to download and put commons-email's dependencies in the classpath along with commons-email. IMO and FWIW, self-managing dependencies like this complicates your project deployment scheme. The size overhead of including your project's dependencies in the each war is so worth it when Maven can handle making sure the dependency artifacts are where they need to be. On Mon, Dec 1, 2014 at 8:17 AM, James Green james.mk.gr...@gmail.com wrote: Is there a way of getting this to work? We have a Maven project that depends on Apache's commons-email. We use JNDI to look up a mail Session. We use the following in our POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration failOnMissingWebXmlfalse/failOnMissingWebXml /configuration /plugin plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.2/version configuration contextFiletomcat/context.xml/contextFile port9000/port path/foo/path forktrue/fork extraDependencies extraDependency groupIdjavax.mail/groupId artifactIdmail/artifactId version1.4/version /extraDependency extraDependency groupIdjavax.activation/groupId artifactIdactivation/artifactId version1.1.1/version /extraDependency /extraDependencies /configuration executions execution idstart/id goals goalrun-war-only/goal /goals
tomcat7-maven-plugin and mail
Is there a way of getting this to work? We have a Maven project that depends on Apache's commons-email. We use JNDI to look up a mail Session. We use the following in our POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration failOnMissingWebXmlfalse/failOnMissingWebXml /configuration /plugin plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.2/version configuration contextFiletomcat/context.xml/contextFile port9000/port path/foo/path forktrue/fork extraDependencies extraDependency groupIdjavax.mail/groupId artifactIdmail/artifactId version1.4/version /extraDependency extraDependency groupIdjavax.activation/groupId artifactIdactivation/artifactId version1.1.1/version /extraDependency /extraDependencies /configuration executions execution idstart/id goals goalrun-war-only/goal /goals phasepre-integration-test/phase /execution execution idshutdown/id goals goalshutdown/goal /goals phasepost-integration-test/phase /execution /executions /plugin Deployment fails with the following: java.lang.ClassNotFoundException: javax.mail.Session I have both mail and activation listed in the POM's dependencies with a scope of provided. Is further magic required? Thanks, James
Re: tomcat7-maven-plugin and mail
A few things you might take a look at. I don't think the Tomcat plugin requires javax.mail or activation by itself. That part of the plugin definition probably isn't doing what you intended it to do. I think you might want to remove the extraDependencies section. By including project ... dependencies dependency groupIdorg.apache.commons/groupId artifactIdcommons-email/artifactId versionyour_version_here/version /dependency /dependencies /project You'll get javax.mail as a transitive dependency. The Maven WAR plugin is smart enough to include your dependencies and their transitive dependencies in your war file. Even though you're looking up the mail Session using JNDI, I still think you'll be needing the commons email as a compiled dependency unless you've put it in the classpath yourself. If you have put it in the classpath, using provided scope will not include transitive dependencies, of which there are several for commons-email. If that's the route you want to go, you'll need to download and put commons-email's dependencies in the classpath along with commons-email. IMO and FWIW, self-managing dependencies like this complicates your project deployment scheme. The size overhead of including your project's dependencies in the each war is so worth it when Maven can handle making sure the dependency artifacts are where they need to be. On Mon, Dec 1, 2014 at 8:17 AM, James Green james.mk.gr...@gmail.com wrote: Is there a way of getting this to work? We have a Maven project that depends on Apache's commons-email. We use JNDI to look up a mail Session. We use the following in our POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration failOnMissingWebXmlfalse/failOnMissingWebXml /configuration /plugin plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.2/version configuration contextFiletomcat/context.xml/contextFile port9000/port path/foo/path forktrue/fork extraDependencies extraDependency groupIdjavax.mail/groupId artifactIdmail/artifactId version1.4/version /extraDependency extraDependency groupIdjavax.activation/groupId artifactIdactivation/artifactId version1.1.1/version /extraDependency /extraDependencies /configuration executions execution idstart/id goals goalrun-war-only/goal /goals phasepre-integration-test/phase /execution execution idshutdown/id goals goalshutdown/goal /goals phasepost-integration-test/phase /execution /executions /plugin Deployment fails with the following: java.lang.ClassNotFoundException: javax.mail.Session I have both mail and activation listed in the POM's dependencies with a scope of provided. Is further magic required? Thanks, James
tomcat7-websocket - tomcat7-maven-plugin java.lang.ClassNotFoundException: javax.servlet.http.HttpUpgradeHandler
Hello,
I am migrating my websocket application to the new API with version 7.0.47.
How can correctly make a configuration of tomcat7-maven-plugin to use
tomcat7-websocket on localhost.
Here what I have in my pom:
...
dependencies
...
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat-catalina/artifactId/dependency
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat-coyote/artifactId/dependency
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat7-websocket/artifactId/dependency
/dependencies
...
/plugins
plugin
groupIdorg.apache.tomcat.maven/groupIdartifactIdtomcat7-maven-plugin/artifactId
configuration
url/url
server/server
path//path
port7443/port
httpsPort0/httpsPort
keystorePasscatmot/keystorePass
tomcatUserssrc/main/tomcatconf/tomcat-users.xml/tomcatUsers
/configuration
/plugin
/plugins
/build
/project
and my parent pom:
...
dependencyManagement
...
dependencies
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat-catalina/artifactIdversion7.0.47/versionscopeprovided/scope/dependency
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat-coyote/artifactIdversion7.0.47/versionscopeprovided/scope/dependency
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat7-websocket/artifactIdversion7.0.47/versionscopeprovided/scope/dependency
dependencygroupIdjavax/groupIdartifactIdjavaee-web-api/artifactIdversion6.0/versionscopeprovided/scope/dependency
/dependencies
/dependencyManagement
...
pluginManagement
plugins
plugingroupIdorg.apache.tomcat.maven/groupIdartifactIdtomcat7-maven-plugin/artifactIdversion2.1/version
dependencies
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat-catalina/artifactIdversion7.0.47/versionscoperuntime/scope/dependency
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat-coyote/artifactIdversion7.0.47/versionscoperuntime/scope/dependency
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat7-websocket/artifactIdversion7.0.47/versionscoperuntime/scope/dependency
/dependencies /plugin
/plugins
/pluginManagement
/build
/project
When using simple server end point
@ServerEndpoint(value=/connector)
public class MachineWsConnector {
@OnOpen
public void onOpen(Session session) { }
@OnClose
public void onClose(Session session, CloseReason closeReason) { }
}
and trying to connect with client with:
WebSocketContainer container = ContainerProvider.getWebSocketContainer();
container.connectToServer(Client.class, new
URI(ws://localhost:7443/connector));
I get error on client side:
Exception in thread main javax.websocket.DeploymentException: The HTTP
response from the server [HTTP/1.1 500 Internal Server Error
] did not permit the HTTP upgrade to WebSocket
at
org.apache.tomcat.websocket.WsWebSocketContainer.parseStatus(WsWebSocketContainer.java:601)
at
org.apache.tomcat.websocket.WsWebSocketContainer.processResponse(WsWebSocketContainer.java:585)
at
org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:317)
at
org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:183)
at
org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:204)
at com.systemincloud.api.machine.java.Client.main(Client.java:49)
and on server side:
java.lang.ClassNotFoundException: javax.servlet.http.HttpUpgradeHandler
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1702)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1547)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:788)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2918)
at
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1174)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1669)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1547)
at
org.apache.tomcat.websocket.server.UpgradeUtil.doUpgrade(UpgradeUtil.java:174)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:76)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171
Re: tomcat7-websocket - tomcat7-maven-plugin java.lang.ClassNotFoundException: javax.servlet.http.HttpUpgradeHandler
I think I moved forward. I changed version of javaee-web-api from 6.0 to
7.0:
dependencygroupIdjavax/groupIdartifactIdjavaee-
web-api/artifactIdversion6.0/versionscopeprovided/
scope/dependency
to:
dependencygroupIdjavax/groupIdartifactIdjavaee-
web-api/artifactIdversion7.0/versionscopeprovided/
scope/dependency
However now I get an error on the server side:
SEVERE: Servlet.service() for servlet [default] in context with path []
threw exception [Filter execution threw an exception] with root cause
java.lang.NoSuchMethodError:
org.apache.tomcat.InstanceManager.newInstance(Ljava/lang/Class;)Ljava/lang/Object;
at org.apache.catalina.connector.Request.upgrade(Request.java:2850)
at
org.apache.catalina.connector.RequestFacade.upgrade(RequestFacade.java:1109)
at
org.apache.tomcat.websocket.server.UpgradeUtil.doUpgrade(UpgradeUtil.java:183)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:76)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
2013/11/7 Marek Jagielski marek.jagiel...@gmail.com
Hello,
I am migrating my websocket application to the new API with version
7.0.47. How can correctly make a configuration of tomcat7-maven-plugin to
use tomcat7-websocket on localhost.
Here what I have in my pom:
...
dependencies
...
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat-catalina/artifactId/dependency
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat-coyote/artifactId/dependency
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat7-websocket/artifactId/dependency
/dependencies
...
/plugins
plugin
groupIdorg.apache.tomcat.maven/groupIdartifactIdtomcat7-maven-plugin/artifactId
configuration
url/url
server/server
path//path
port7443/port
httpsPort0/httpsPort
keystorePasscatmot/keystorePass
tomcatUserssrc/main/tomcatconf/tomcat-users.xml/tomcatUsers
/configuration
/plugin
/plugins
/build
/project
and my parent pom:
...
dependencyManagement
...
dependencies
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat-catalina/artifactIdversion7.0.47/versionscopeprovided/scope/dependency
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat-coyote/artifactIdversion7.0.47/versionscopeprovided/scope/dependency
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat7-websocket/artifactIdversion7.0.47/versionscopeprovided/scope/dependency
dependencygroupIdjavax/groupIdartifactIdjavaee-web-api/artifactIdversion6.0/versionscopeprovided/scope/dependency
/dependencies
/dependencyManagement
...
pluginManagement
plugins
plugingroupIdorg.apache.tomcat.maven/groupIdartifactIdtomcat7-maven-plugin/artifactIdversion2.1/version
dependencies
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat-catalina/artifactIdversion7.0.47/versionscoperuntime/scope/dependency
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat-coyote/artifactIdversion7.0.47/versionscoperuntime/scope/dependency
dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat7-websocket/artifactIdversion7.0.47/versionscoperuntime/scope/dependency
/dependencies /plugin
/plugins
/pluginManagement
/build
/project
When using simple server end point
@ServerEndpoint(value=/connector)
public class MachineWsConnector {
@OnOpen
public void onOpen(Session session) { }
@OnClose
public void onClose(Session session, CloseReason closeReason) { }
}
and trying to connect with client with:
WebSocketContainer container
Re: tomcat7-websocket - tomcat7-maven-plugin java.lang.ClassNotFoundException: javax.servlet.http.HttpUpgradeHandler
While debuging I see that
httpUpgradeHandlerClass in upgrade of org.apache.catalina.connector.Request
is
class org.apache.tomcat.websocket.server.WsHttpUpgradeHandler
InstanceManager is org.apache.catalina.core.DefaultInstanceManager
in the source code of my maven dependency of tomcat-api-7.0.47 this method
should exist:
public interface InstanceManager {
public Object newInstance(Class? clazz)
throws IllegalAccessException, InvocationTargetException,
NamingException,
InstantiationException;
...
Any clue ?
Re: tomcat7-websocket - tomcat7-maven-plugin java.lang.ClassNotFoundException: javax.servlet.http.HttpUpgradeHandler
In tomcat's svn history I see that looked method was added to InstanceManager (tomcat-api) when Back-porting JSR-356: + public Object newInstance(Class? clazz) + throws IllegalAccessException, InvocationTargetException, NamingException, + InstantiationException; + However, I solved the problem by adding explicitly dependencygroupIdorg.apache.tomcat/groupIdartifactIdtomcat-api/artifactIdversion7.0.47/versionscoperuntime/scope/dependency into pluginManagement dependencies I hope that this topic can be at least useful for others. Thanks, Marek
tomcat7-maven-plugin enable auto deployment under webapps
Hello fellow tomcat7-maven-plugin users,
Is there a way to configure the embedded tomcat launched via the
tomcat7-maven-plugin in such a way that the
${project.build.directory}/tomcat/webapps folder will be monitored for
automatic deployments like it is with a standard tomcat bundle?
I dug around in the source of tomcat7-maven-plugin and even experimented
with my own modified version of the plugin where I added a HostConfig()
object to the embedded tomcat instance. This seems to get the scanning of
webapps folder working again but when it goes to hot-deploy any webapps
out there, it quickly runs into ClassNotFound exceptions because the
WebappClassLoader for the thread that is hot-deploy my new webapp doesn't
have the right parent classloader.
I see where the tomcat7-maven-plugin is creating the WebappClassLoader for
all of the configured contexts via the webapps config section for the
maven plugin. But I'm not sure how to get the WebappClassLoaders that are
created by the HostConfig.deployDirectory() to do the same.
Any clues? Appreciate the help anyone can give.
--
Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com
tomcat7 maven plugin and X509TrustManager
Hello,
I use tomcat7-maven-plugin:2.1 with SSL config and client authentication.
My plugin configuration:
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
configuration
systemProperties
javax.net.ssl.trustStore${project.basedir}/src/test/resources/META-INF/tomcat/certificates/truststore/javax.net.ssl.trustStore
javax.net.ssl.trustStorePasswordXXX/javax.net.ssl.trustStorePassword
/systemProperties
port8080/port
contextFile
${project.basedir}/src/test/resources/META-INF/tomcat/webapp-context.xml
/contextFile
httpsPort9090/httpsPort
clientAuthtrue/clientAuth
keystoreFile${project.basedir}/src/test/resources/META-INF/tomcat/certificates/keystore
/keystoreFile
keystorePassXX/keystorePass
/configuration
/plugin
My problem is how setup a custom implementation of X509TrustManager?
In tomcat connector, we can use the attribute 'trustManagerClassName'.
But with maven plugin, how do it?
Thanks,
Loïc
Re: Deploying war from dependency with tomcat7-maven-plugin
for 1) your jars must be in the plugin dependencies section (see jdbc driver here http://tomcat.apache.org/maven-plugin-trunk/run-mojo-features.html ) for 2) I understand you simply want to run a war (and maybe run unit tests) so unpacking with the dependency looks to be the solution. HTH Olivier On 9 September 2013 13:18, Greg Amerson gregory.amer...@liferay.com wrote: Hello all, I'm trying to use the tomcat7-maven-plugin, specifically running the *mvn tomcat7:run* command. However, in my case I have two requirements that are different than the documentation provides for and I'm wondering if it is possible with the current tomcat7-maven-plugin. 1. need to deploy several jars to the global tomcat classpath (i.e. same as copying them into tomcat.home/lib/ext/ folder in a standalone install). 2. need to deploy a war to the ROOT context but instead of packaging the current project from source, I just need to point to an existing WAR as a dependency. So in my project there will be no webapp source. I simply want to run a tomcat with some extra jars in /lib/ext/ directory and also deploy a war that is obtained via a dependency with war type instead of packaged from source. Thanks in advance for any help! -- Greg Amerson Liferay Developer Tools Liferay, Inc. www.liferay.com -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Deploying war from dependency with tomcat7-maven-plugin
Thanks Olivier, I was able to use your examples and specifying the dependencies manually and got it work nicely. So I just put Liferay portal web war package into my webapps section and also enumerated all the dependencies that need to be available to Embedded tomcat and it worked! For anyone interested here it is: https://gist.github.com/gamerson/6510740 G On Tue, Sep 10, 2013 at 2:19 PM, Olivier Lamy ol...@apache.org wrote: for 1) your jars must be in the plugin dependencies section (see jdbc driver here http://tomcat.apache.org/maven-plugin-trunk/run-mojo-features.html ) for 2) I understand you simply want to run a war (and maybe run unit tests) so unpacking with the dependency looks to be the solution. HTH Olivier On 9 September 2013 13:18, Greg Amerson gregory.amer...@liferay.com wrote: Hello all, I'm trying to use the tomcat7-maven-plugin, specifically running the *mvn tomcat7:run* command. However, in my case I have two requirements that are different than the documentation provides for and I'm wondering if it is possible with the current tomcat7-maven-plugin. 1. need to deploy several jars to the global tomcat classpath (i.e. same as copying them into tomcat.home/lib/ext/ folder in a standalone install). 2. need to deploy a war to the ROOT context but instead of packaging the current project from source, I just need to point to an existing WAR as a dependency. So in my project there will be no webapp source. I simply want to run a tomcat with some extra jars in /lib/ext/ directory and also deploy a war that is obtained via a dependency with war type instead of packaged from source. Thanks in advance for any help! -- Greg Amerson Liferay Developer Tools Liferay, Inc. www.liferay.com -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Greg Amerson Liferay Developer Tools Liferay, Inc. www.liferay.com
Re: Deploying war from dependency with tomcat7-maven-plugin
Hi Greg, Your requirement is quite interesting and I am looking forward some fine recommendation from our users. On Mon, Sep 9, 2013 at 8:48 AM, Greg Amerson gregory.amer...@liferay.comwrote: Hello all, I'm trying to use the tomcat7-maven-plugin, specifically running the *mvn tomcat7:run* command. However, in my case I have two requirements that are different than the documentation provides for and I'm wondering if it is possible with the current tomcat7-maven-plugin. 1. need to deploy several jars to the global tomcat classpath (i.e. same as copying them into tomcat.home/lib/ext/ folder in a standalone install). 2. need to deploy a war to the ROOT context but instead of packaging the current project from source, I just need to point to an existing WAR as a dependency. So in my project there will be no webapp source. I simply want to run a tomcat with some extra jars in /lib/ext/ directory and also deploy a war that is obtained via a dependency with war type instead of packaged from source. Thanks in advance for any help! -- Greg Amerson Liferay Developer Tools Liferay, Inc. www.liferay.com -- *Thanks Regards* * * *Pandian* *(Living @ Virtual World)*
Re: Deploying war from dependency with tomcat7-maven-plugin
2013/9/9 Greg Amerson gregory.amer...@liferay.com:
Hello all,
I'm trying to use the tomcat7-maven-plugin, specifically running the *mvn
tomcat7:run* command.
However, in my case I have two requirements that are different than the
documentation provides for and I'm wondering if it is possible with the
current tomcat7-maven-plugin.
1. need to deploy several jars to the global tomcat classpath (i.e. same as
copying them into tomcat.home/lib/ext/ folder in a standalone install).
2. need to deploy a war to the ROOT context but instead of packaging the
current project from source, I just need to point to an existing WAR as a
dependency.
So in my project there will be no webapp source. I simply want to run a
tomcat with some extra jars in /lib/ext/ directory and also deploy a war
that is obtained via a dependency with war type instead of packaged from
source.
Thanks in advance for any help!
Hi,
I don't know if it could answer your question but I think I do
something similar for integration testing.
First to add jar to embedded tomcat used by by the plugin, Ideclare
those Jar as dependencies for the plugin.
Then to add a different war I use the dependency plugin to unzip the
war in the current project build directory and then use the tomcat
plugin to launch it :
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.4/version
executions
execution
idunzip-webapp/id
phasepre-integration-test/phase
goals
goalunpack/goal
/goals
configuration
artifactItems
artifactItem
groupId${project.groupId}/groupId
artifactId${artifact-to-import}/artifactId
version${project.version}/version
typewar/type
/artifactItem
/artifactItems
outputDirectory${project.build.directory}/webapp/outputDirectory
overWriteSnapshotstrue/overWriteSnapshots
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
executions
execution
idtomcat-run/id
goals
goalrun-war-only/goal
/goals
phasepre-integration-test/phase
configuration
path//path
port8080/port
uriEncodingUTF-8/uriEncoding
warDirectory${project.build.directory}/webapp//warDirectory
forktrue/fork
ignorePackagingtrue/ignorePackaging
contextFile${project.build.directory}/webapp/META-INF/context.xml/contextFile
/configuration
/execution
execution
idtomcat-shutdown/id
goals
goalshutdown/goal
/goals
phasepost-integration-test/phase
/execution
/executions
/plugin
.
Cédric
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Deploying war from dependency with tomcat7-maven-plugin
Hello all, I'm trying to use the tomcat7-maven-plugin, specifically running the *mvn tomcat7:run* command. However, in my case I have two requirements that are different than the documentation provides for and I'm wondering if it is possible with the current tomcat7-maven-plugin. 1. need to deploy several jars to the global tomcat classpath (i.e. same as copying them into tomcat.home/lib/ext/ folder in a standalone install). 2. need to deploy a war to the ROOT context but instead of packaging the current project from source, I just need to point to an existing WAR as a dependency. So in my project there will be no webapp source. I simply want to run a tomcat with some extra jars in /lib/ext/ directory and also deploy a war that is obtained via a dependency with war type instead of packaged from source. Thanks in advance for any help! -- Greg Amerson Liferay Developer Tools Liferay, Inc. www.liferay.com
tomcat7-maven-plugin and async supported
I created a filter class and forgot to set the async supported property to true. This resulted that my war didn't deploy/work when running inside tomcat 7. I fixed that and it runs fine now, but I am surprised that I didn't see this earlier since I am using the tomcat7-maven-plugin to start an embedded tomcat instance to run my integration tests against which all ran fine. Can anyone explain the why because it is puzzling me. TIA, Bas
Re:[OT] tomcat7-maven-plugin: Build on executable war file
Timothy Astle wrote: ... Additionally, we have a Selenium grid set up. When our Jenkins build system makes a build, cargo to grabs the war and failsafe runs our selenium integration tests. All tests must pass before any artifact is deployed to Nexus. So in a sense, it feels like cheating to have the tests all pass on the non-standalone artifact, but we ship the standalone one. I've thought about using maven tomcat plugin as a means to possibly shore this up, but there is still a part of me that likes the aspect of being able to deploy to any type of container via cargo. That is the kind of text that will undoubtedly generate joy among archeologists when they dig it up from the memory-cube archives in a thousand years from now. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin: Build on executable war file
2013/2/28 Timothy Astle timothy.as...@caris.com: I'll chime in here :) We create the artifact that we want, but we have two. The WAR created by the maven war plugin, and the overlay war that is standalone. But we still need the war to package it in the standalone artifact. And all the logic to create a war is in the maven war plugin. And frankly I don't want to copy/paste all this logic to clone it in the tomcat plugin (doesn't make sense IMHO) Maybe what you can try is to use pom packaging (instead of the one you are probably currently using war packaging) and then use the war plugin to package the war which need to be included in the standalone. As it the generated war won't be an attached artifact and won't be deploy. NOTE: It's a solution I didn't test :-) We were hoping to only deploy the tomcat overlay war since it does everything that the other war does, plus contain tomcat. By doing this, we hope to avoid confusion from staff that may grab the wrong war file from our artifact repository (Nexus) and accidentally provide it to customers. So we're trying to be proactively safe. Additionally, we have a Selenium grid set up. When our Jenkins build system makes a build, cargo to grabs the war and failsafe runs our selenium integration tests. All tests must pass before any artifact is deployed to Nexus. So in a sense, it feels like cheating to have the tests all pass on the non-standalone artifact, but we ship the standalone one. I've thought about using maven tomcat plugin as a means to possibly shore this up, but there is still a part of me that likes the aspect of being able to deploy to any type of container via cargo. I haven't had a chance to dig into this yet, perhaps Rich has, but any expert advice is always much appreciated. Tim On 27/02/2013 6:46 PM, Olivier Lamy wrote: 2013/2/27 Richard McAleer rmcal...@caris.com: Hi, We're using tomcat7-maven-plugin 2.1 to build an executable war using the standalone-war-only goal. The maven build still generates the normal war file as well as the executable .war created by the plugin. However, since the standalone-war-only goal generates a war that is both executable and deployable, we really don't need to generate the normal war file. Is there a good way of generating just the executable war's using the plugin? We could probably have maven delete the original .war file and rename the executable .war to the normal webapp name, but that doesn't seem like the best way of doing it. Currently no. As the generated executable war/jar contains this war (not an exploded war) so it's mandatory to have it. BTW what is your use case ? Thanks, Richard -- Richard McAleer Developer Web Development Team *CARIS* http://www.caris.com 115 Waggoners Lane Fredericton, New Brunswick CanadaE3B 2L4 Tel: +1.506.458.8533 Fax: +1.506.459.3849 www.caris.com http://www.caris.com *Connect with CARIS* Twitter http://www.twitter.com/CARIS_GIS | LinkedIn http://www.linkedin.com/groups?mostPopular=gid=3217878 | Facebook https://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669?v=app_4949752878 | Google+ https://plus.google.com/b/114389770462919844434/114389770462919844434/posts | YouTube http://www.youtube.com/user/CARISGIS Download your free copy of CARIS Easy View today! www.caris.com/easyview http://www.caris.com/easyview _ This email and any files transmitted with it are confidential and intended only for the addressee(s). If you are not the intended recipient(s) please notify us by email reply. You should not use, disclose, distribute or copy this communication if received in error. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the company. No binding contract will result from this email until such time as a written document is signed on behalf of the company. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin: Build on executable war file
On 28/02/2013 9:32 AM, Olivier Lamy wrote: 2013/2/28 Timothy Astle timothy.as...@caris.com: I'll chime in here :) We create the artifact that we want, but we have two. The WAR created by the maven war plugin, and the overlay war that is standalone. But we still need the war to package it in the standalone artifact. And all the logic to create a war is in the maven war plugin. And frankly I don't want to copy/paste all this logic to clone it in the tomcat plugin (doesn't make sense IMHO) I completely understand your point. That would cause duplication of code and extra maintenance. Maybe what you can try is to use pom packaging (instead of the one you are probably currently using war packaging) and then use the war plugin to package the war which need to be included in the standalone. As it the generated war won't be an attached artifact and won't be deploy. NOTE: It's a solution I didn't test :-) haha, fair enough. To be honest, I don't think we want to pursue that route either. I much prefer explicit modelling of a project and avoid scripting. Going that route just leads to pain and suffering unless there is a really, really strong reason to do so. Many thanks for your feedback, it is much appreciated. Tim We were hoping to only deploy the tomcat overlay war since it does everything that the other war does, plus contain tomcat. By doing this, we hope to avoid confusion from staff that may grab the wrong war file from our artifact repository (Nexus) and accidentally provide it to customers. So we're trying to be proactively safe. Additionally, we have a Selenium grid set up. When our Jenkins build system makes a build, cargo to grabs the war and failsafe runs our selenium integration tests. All tests must pass before any artifact is deployed to Nexus. So in a sense, it feels like cheating to have the tests all pass on the non-standalone artifact, but we ship the standalone one. I've thought about using maven tomcat plugin as a means to possibly shore this up, but there is still a part of me that likes the aspect of being able to deploy to any type of container via cargo. I haven't had a chance to dig into this yet, perhaps Rich has, but any expert advice is always much appreciated. Tim On 27/02/2013 6:46 PM, Olivier Lamy wrote: 2013/2/27 Richard McAleer rmcal...@caris.com: Hi, We're using tomcat7-maven-plugin 2.1 to build an executable war using the standalone-war-only goal. The maven build still generates the normal war file as well as the executable .war created by the plugin. However, since the standalone-war-only goal generates a war that is both executable and deployable, we really don't need to generate the normal war file. Is there a good way of generating just the executable war's using the plugin? We could probably have maven delete the original .war file and rename the executable .war to the normal webapp name, but that doesn't seem like the best way of doing it. Currently no. As the generated executable war/jar contains this war (not an exploded war) so it's mandatory to have it. BTW what is your use case ? Thanks, Richard -- Richard McAleer Developer Web Development Team *CARIS* http://www.caris.com 115 Waggoners Lane Fredericton, New Brunswick CanadaE3B 2L4 Tel: +1.506.458.8533 Fax: +1.506.459.3849 www.caris.com http://www.caris.com *Connect with CARIS* Twitter http://www.twitter.com/CARIS_GIS | LinkedIn http://www.linkedin.com/groups?mostPopular=gid=3217878 | Facebook https://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669?v=app_4949752878 | Google+ https://plus.google.com/b/114389770462919844434/114389770462919844434/posts | YouTube http://www.youtube.com/user/CARISGIS Download your free copy of CARIS Easy View today! www.caris.com/easyview http://www.caris.com/easyview _ This email and any files transmitted with it are confidential and intended only for the addressee(s). If you are not the intended recipient(s) please notify us by email reply. You should not use, disclose, distribute or copy this communication if received in error. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the company. No binding contract will result from this email until such time as a written document is signed on behalf of the company. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat7-maven-plugin: Build on executable war file
Hi, We're using tomcat7-maven-plugin 2.1 to build an executable war using the standalone-war-only goal. The maven build still generates the normal war file as well as the executable .war created by the plugin. However, since the standalone-war-only goal generates a war that is both executable and deployable, we really don't need to generate the normal war file. Is there a good way of generating just the executable war's using the plugin? We could probably have maven delete the original .war file and rename the executable .war to the normal webapp name, but that doesn't seem like the best way of doing it. Thanks, Richard -- Richard McAleer Developer Web Development Team *CARIS* http://www.caris.com 115 Waggoners Lane Fredericton, New Brunswick CanadaE3B 2L4 Tel: +1.506.458.8533 Fax: +1.506.459.3849 www.caris.com http://www.caris.com *Connect with CARIS* Twitter http://www.twitter.com/CARIS_GIS | LinkedIn http://www.linkedin.com/groups?mostPopular=gid=3217878 | Facebook https://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669?v=app_4949752878 | Google+ https://plus.google.com/b/114389770462919844434/114389770462919844434/posts | YouTube http://www.youtube.com/user/CARISGIS Download your free copy of CARIS Easy View today! www.caris.com/easyview http://www.caris.com/easyview _ This email and any files transmitted with it are confidential and intended only for the addressee(s). If you are not the intended recipient(s) please notify us by email reply. You should not use, disclose, distribute or copy this communication if received in error. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the company. No binding contract will result from this email until such time as a written document is signed on behalf of the company.
Re: tomcat7-maven-plugin: Build on executable war file
2013/2/27 Richard McAleer rmcal...@caris.com: Hi, We're using tomcat7-maven-plugin 2.1 to build an executable war using the standalone-war-only goal. The maven build still generates the normal war file as well as the executable .war created by the plugin. However, since the standalone-war-only goal generates a war that is both executable and deployable, we really don't need to generate the normal war file. Is there a good way of generating just the executable war's using the plugin? We could probably have maven delete the original .war file and rename the executable .war to the normal webapp name, but that doesn't seem like the best way of doing it. Currently no. As the generated executable war/jar contains this war (not an exploded war) so it's mandatory to have it. BTW what is your use case ? Thanks, Richard -- Richard McAleer Developer Web Development Team *CARIS* http://www.caris.com 115 Waggoners Lane Fredericton, New Brunswick CanadaE3B 2L4 Tel: +1.506.458.8533 Fax: +1.506.459.3849 www.caris.com http://www.caris.com *Connect with CARIS* Twitter http://www.twitter.com/CARIS_GIS | LinkedIn http://www.linkedin.com/groups?mostPopular=gid=3217878 | Facebook https://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669?v=app_4949752878 | Google+ https://plus.google.com/b/114389770462919844434/114389770462919844434/posts | YouTube http://www.youtube.com/user/CARISGIS Download your free copy of CARIS Easy View today! www.caris.com/easyview http://www.caris.com/easyview _ This email and any files transmitted with it are confidential and intended only for the addressee(s). If you are not the intended recipient(s) please notify us by email reply. You should not use, disclose, distribute or copy this communication if received in error. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the company. No binding contract will result from this email until such time as a written document is signed on behalf of the company. -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[OT] tomcat7-maven-plugin
Hello: How is it possible that tomcat7-maven-plugin has got a 'deploy' goal but not 'undeploy' goal ? Regards 2013/2/27 Olivier Lamy ol...@apache.org: 2013/2/27 Richard McAleer rmcal...@caris.com: Hi, We're using tomcat7-maven-plugin 2.1 to build an executable war using the standalone-war-only goal. The maven build still generates the normal war file as well as the executable .war created by the plugin. However, since the standalone-war-only goal generates a war that is both executable and deployable, we really don't need to generate the normal war file. Is there a good way of generating just the executable war's using the plugin? We could probably have maven delete the original .war file and rename the executable .war to the normal webapp name, but that doesn't seem like the best way of doing it. Currently no. As the generated executable war/jar contains this war (not an exploded war) so it's mandatory to have it. BTW what is your use case ? Thanks, Richard -- Richard McAleer Developer Web Development Team *CARIS* http://www.caris.com 115 Waggoners Lane Fredericton, New Brunswick CanadaE3B 2L4 Tel: +1.506.458.8533 Fax: +1.506.459.3849 www.caris.com http://www.caris.com *Connect with CARIS* Twitter http://www.twitter.com/CARIS_GIS | LinkedIn http://www.linkedin.com/groups?mostPopular=gid=3217878 | Facebook https://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669?v=app_4949752878 | Google+ https://plus.google.com/b/114389770462919844434/114389770462919844434/posts | YouTube http://www.youtube.com/user/CARISGIS Download your free copy of CARIS Easy View today! www.caris.com/easyview http://www.caris.com/easyview _ This email and any files transmitted with it are confidential and intended only for the addressee(s). If you are not the intended recipient(s) please notify us by email reply. You should not use, disclose, distribute or copy this communication if received in error. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the company. No binding contract will result from this email until such time as a written document is signed on behalf of the company. -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin: Build on executable war file
I'll chime in here :) We create the artifact that we want, but we have two. The WAR created by the maven war plugin, and the overlay war that is standalone. We were hoping to only deploy the tomcat overlay war since it does everything that the other war does, plus contain tomcat. By doing this, we hope to avoid confusion from staff that may grab the wrong war file from our artifact repository (Nexus) and accidentally provide it to customers. So we're trying to be proactively safe. Additionally, we have a Selenium grid set up. When our Jenkins build system makes a build, cargo to grabs the war and failsafe runs our selenium integration tests. All tests must pass before any artifact is deployed to Nexus. So in a sense, it feels like cheating to have the tests all pass on the non-standalone artifact, but we ship the standalone one. I've thought about using maven tomcat plugin as a means to possibly shore this up, but there is still a part of me that likes the aspect of being able to deploy to any type of container via cargo. I haven't had a chance to dig into this yet, perhaps Rich has, but any expert advice is always much appreciated. Tim On 27/02/2013 6:46 PM, Olivier Lamy wrote: 2013/2/27 Richard McAleer rmcal...@caris.com: Hi, We're using tomcat7-maven-plugin 2.1 to build an executable war using the standalone-war-only goal. The maven build still generates the normal war file as well as the executable .war created by the plugin. However, since the standalone-war-only goal generates a war that is both executable and deployable, we really don't need to generate the normal war file. Is there a good way of generating just the executable war's using the plugin? We could probably have maven delete the original .war file and rename the executable .war to the normal webapp name, but that doesn't seem like the best way of doing it. Currently no. As the generated executable war/jar contains this war (not an exploded war) so it's mandatory to have it. BTW what is your use case ? Thanks, Richard -- Richard McAleer Developer Web Development Team *CARIS* http://www.caris.com 115 Waggoners Lane Fredericton, New Brunswick CanadaE3B 2L4 Tel: +1.506.458.8533 Fax: +1.506.459.3849 www.caris.com http://www.caris.com *Connect with CARIS* Twitter http://www.twitter.com/CARIS_GIS | LinkedIn http://www.linkedin.com/groups?mostPopular=gid=3217878 | Facebook https://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669?v=app_4949752878 | Google+ https://plus.google.com/b/114389770462919844434/114389770462919844434/posts | YouTube http://www.youtube.com/user/CARISGIS Download your free copy of CARIS Easy View today! www.caris.com/easyview http://www.caris.com/easyview _ This email and any files transmitted with it are confidential and intended only for the addressee(s). If you are not the intended recipient(s) please notify us by email reply. You should not use, disclose, distribute or copy this communication if received in error. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the company. No binding contract will result from this email until such time as a written document is signed on behalf of the company. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] tomcat7-maven-plugin
2013/2/28 Jose María Zaragoza demablo...@gmail.com: Hello: How is it possible that tomcat7-maven-plugin has got a 'deploy' goal but not 'undeploy' goal ? sure ? http://tomcat.apache.org/maven-plugin-2.1/tomcat7-maven-plugin/undeploy-mojo.html :-) Regards 2013/2/27 Olivier Lamy ol...@apache.org: 2013/2/27 Richard McAleer rmcal...@caris.com: Hi, We're using tomcat7-maven-plugin 2.1 to build an executable war using the standalone-war-only goal. The maven build still generates the normal war file as well as the executable .war created by the plugin. However, since the standalone-war-only goal generates a war that is both executable and deployable, we really don't need to generate the normal war file. Is there a good way of generating just the executable war's using the plugin? We could probably have maven delete the original .war file and rename the executable .war to the normal webapp name, but that doesn't seem like the best way of doing it. Currently no. As the generated executable war/jar contains this war (not an exploded war) so it's mandatory to have it. BTW what is your use case ? Thanks, Richard -- Richard McAleer Developer Web Development Team *CARIS* http://www.caris.com 115 Waggoners Lane Fredericton, New Brunswick CanadaE3B 2L4 Tel: +1.506.458.8533 Fax: +1.506.459.3849 www.caris.com http://www.caris.com *Connect with CARIS* Twitter http://www.twitter.com/CARIS_GIS | LinkedIn http://www.linkedin.com/groups?mostPopular=gid=3217878 | Facebook https://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669?v=app_4949752878 | Google+ https://plus.google.com/b/114389770462919844434/114389770462919844434/posts | YouTube http://www.youtube.com/user/CARISGIS Download your free copy of CARIS Easy View today! www.caris.com/easyview http://www.caris.com/easyview _ This email and any files transmitted with it are confidential and intended only for the addressee(s). If you are not the intended recipient(s) please notify us by email reply. You should not use, disclose, distribute or copy this communication if received in error. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the company. No binding contract will result from this email until such time as a written document is signed on behalf of the company. -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin
On Mon, Dec 17, 2012 at 8:13 AM, Josh Gooding josh.good...@gmail.comwrote: As far as this goes, there is definitely something strange going on, and I think it points to the SSL self signed cert. Can someone verify that the tomcat7 maven plugin works with self signed SSL? I have setup another TC7 server on a remote BSD VM with the absolute basic configuration. Since the first server has the manager application running on a self signed SSL certificate (not sure if I mentioned that before), I decided NOT to set it [SSL] up on the new machine, and it works as expected and can be reproduced on demand. I notice that when I script the command using curl, I have to pass it the -k option to get it to work. I am wondering if that might be the problem that I am seeing, just masked by the 401 error. I'm looking in the tomcat logs and I'm not seeing anything out of the ordinary though. Maybe that error is only returned by maven. Anyone? I solved the problem. It ended up being the self signed cert that I created. Little did I know that the CN had to match the domain name of the server. Had me running around for a few days figuring it out. The minute I changed the CN to do a partial match on the domain name (i.e. *.dev.texas.priv.[companyname].com) and imported everything, restarted tomcat, BLAM. It worked. On Thu, Dec 13, 2012 at 9:48 AM, Josh Gooding josh.good...@gmail.comwrote: On Thu, Dec 13, 2012 at 9:36 AM, Olivier Lamy ol...@apache.org wrote: 2012/12/13 Josh Gooding josh.good...@gmail.com: On Wed, Dec 12, 2012 at 6:05 PM, Olivier Lamy ol...@apache.org wrote: Good detailed description :-). Hey even I get it right once in a while... ;) I just wonder about the cli you are using ? cli as in command line interface? - Win 7, CentOS, and Ubuntu terminals, and yes I get my fair share of flack for not letting Eclipse just do it. Of course I'm a control freak when it comes to my code... :-) I mean mvn tomcat7:deploy or something else ? or you bind deploy to a lifecycle phase ? Oh I gotcha. tomcat7:deploy I didn't bind the deploy to the life-cycle phase yet. I want to get it working first. So let me form possibly some better questions here: 1 - Where does the plug in 2012/12/12 Josh Gooding josh.good...@gmail.com: I didn't want to come here to ask as I always hate to bother anyone, but maybe I should have come here first. I'm coming up short on answers and ideas. I'm having an issue with using maven and the tomcat7 plugin. Maven version -3.0.4 Tomcat version - 7.0.29 .jdk version - 1.6 tomcat7-maven-plugin version - 2.0 Hey group, I am having an issue here with using the tomcat7-maven-plugin in conjunction with the tomcat 7 manager. here's what I have so far. tomcat-users.xml - tomcat-users role rolename=manager-gui/ role rolename=manager-script/ role rolename=admin/ user username=localTomcatAdmin password=password roles=manager-gui,manager-script,admin/ /tomcat-users in my M2_HOME/conf/settings.xml: (note not in my .m2/ directory) (I'll get to this definition in a minute) pluginGroups pluginGrouporg.apache.tomcat.maven/pluginGroup /pluginGroups servers server idLocalTomcatServer/id usernamelocalTomcatAdmin/username passwordpassword/password /server /servers now for the last piece, in my pom-deploy.xml (parent) I have this: plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.0/version configuration serverLocalTomcatServer/server path/TripTixRX/path port8080/port /configuration /plugin I have verified that the manager works with the applied credentials, I can login and supply the credentials to my local /manager/html. The problem is that when I deploy through maven as mvn tomcat7:deploy and returns me the dreaded 401 - Unauthorized page with the same credentials. It's almost like maven is not parsing the configuration for the plugin maybe? At this point I don't know what to do. I've turned on verbose output in maven and it shows what appears that the plugin is attempting to upload the war file twice and returns the 401 page. I also have a question as to getting this to work initially. I added the pluginGrouporg.apache.tomcat.maven/pluginGroup to my conf/settings.xml to get the tomcat7 plugin to download and work, is this normal or should I not have to define it here? I mean having to change and version maven settings.xml files seems a bit counter intuitive for preserving maximum portability right, or am I looking at this from the wrong angle? Any information anyone can provide as to where to look or what could be causing this issue, I
Re: tomcat7-maven-plugin
As far as this goes, there is definitely something strange going on, and I think it points to the SSL self signed cert. Can someone verify that the tomcat7 maven plugin works with self signed SSL? I have setup another TC7 server on a remote BSD VM with the absolute basic configuration. Since the first server has the manager application running on a self signed SSL certificate (not sure if I mentioned that before), I decided NOT to set it [SSL] up on the new machine, and it works as expected and can be reproduced on demand. I notice that when I script the command using curl, I have to pass it the -k option to get it to work. I am wondering if that might be the problem that I am seeing, just masked by the 401 error. I'm looking in the tomcat logs and I'm not seeing anything out of the ordinary though. Maybe that error is only returned by maven. Anyone? On Thu, Dec 13, 2012 at 9:48 AM, Josh Gooding josh.good...@gmail.comwrote: On Thu, Dec 13, 2012 at 9:36 AM, Olivier Lamy ol...@apache.org wrote: 2012/12/13 Josh Gooding josh.good...@gmail.com: On Wed, Dec 12, 2012 at 6:05 PM, Olivier Lamy ol...@apache.org wrote: Good detailed description :-). Hey even I get it right once in a while... ;) I just wonder about the cli you are using ? cli as in command line interface? - Win 7, CentOS, and Ubuntu terminals, and yes I get my fair share of flack for not letting Eclipse just do it. Of course I'm a control freak when it comes to my code... :-) I mean mvn tomcat7:deploy or something else ? or you bind deploy to a lifecycle phase ? Oh I gotcha. tomcat7:deploy I didn't bind the deploy to the life-cycle phase yet. I want to get it working first. So let me form possibly some better questions here: 1 - Where does the plug in 2012/12/12 Josh Gooding josh.good...@gmail.com: I didn't want to come here to ask as I always hate to bother anyone, but maybe I should have come here first. I'm coming up short on answers and ideas. I'm having an issue with using maven and the tomcat7 plugin. Maven version -3.0.4 Tomcat version - 7.0.29 .jdk version - 1.6 tomcat7-maven-plugin version - 2.0 Hey group, I am having an issue here with using the tomcat7-maven-plugin in conjunction with the tomcat 7 manager. here's what I have so far. tomcat-users.xml - tomcat-users role rolename=manager-gui/ role rolename=manager-script/ role rolename=admin/ user username=localTomcatAdmin password=password roles=manager-gui,manager-script,admin/ /tomcat-users in my M2_HOME/conf/settings.xml: (note not in my .m2/ directory) (I'll get to this definition in a minute) pluginGroups pluginGrouporg.apache.tomcat.maven/pluginGroup /pluginGroups servers server idLocalTomcatServer/id usernamelocalTomcatAdmin/username passwordpassword/password /server /servers now for the last piece, in my pom-deploy.xml (parent) I have this: plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.0/version configuration serverLocalTomcatServer/server path/TripTixRX/path port8080/port /configuration /plugin I have verified that the manager works with the applied credentials, I can login and supply the credentials to my local /manager/html. The problem is that when I deploy through maven as mvn tomcat7:deploy and returns me the dreaded 401 - Unauthorized page with the same credentials. It's almost like maven is not parsing the configuration for the plugin maybe? At this point I don't know what to do. I've turned on verbose output in maven and it shows what appears that the plugin is attempting to upload the war file twice and returns the 401 page. I also have a question as to getting this to work initially. I added the pluginGrouporg.apache.tomcat.maven/pluginGroup to my conf/settings.xml to get the tomcat7 plugin to download and work, is this normal or should I not have to define it here? I mean having to change and version maven settings.xml files seems a bit counter intuitive for preserving maximum portability right, or am I looking at this from the wrong angle? Any information anyone can provide as to where to look or what could be causing this issue, I would be greatly appreciated. Warmest regards, - Josh -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http
Re: tomcat7-maven-plugin
On Wed, Dec 12, 2012 at 6:05 PM, Olivier Lamy ol...@apache.org wrote: Good detailed description :-). Hey even I get it right once in a while... ;) I just wonder about the cli you are using ? cli as in command line interface? - Win 7, CentOS, and Ubuntu terminals, and yes I get my fair share of flack for not letting Eclipse just do it. Of course I'm a control freak when it comes to my code... 2012/12/12 Josh Gooding josh.good...@gmail.com: I didn't want to come here to ask as I always hate to bother anyone, but maybe I should have come here first. I'm coming up short on answers and ideas. I'm having an issue with using maven and the tomcat7 plugin. Maven version -3.0.4 Tomcat version - 7.0.29 .jdk version - 1.6 tomcat7-maven-plugin version - 2.0 Hey group, I am having an issue here with using the tomcat7-maven-plugin in conjunction with the tomcat 7 manager. here's what I have so far. tomcat-users.xml - tomcat-users role rolename=manager-gui/ role rolename=manager-script/ role rolename=admin/ user username=localTomcatAdmin password=password roles=manager-gui,manager-script,admin/ /tomcat-users in my M2_HOME/conf/settings.xml: (note not in my .m2/ directory) (I'll get to this definition in a minute) pluginGroups pluginGrouporg.apache.tomcat.maven/pluginGroup /pluginGroups servers server idLocalTomcatServer/id usernamelocalTomcatAdmin/username passwordpassword/password /server /servers now for the last piece, in my pom-deploy.xml (parent) I have this: plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.0/version configuration serverLocalTomcatServer/server path/TripTixRX/path port8080/port /configuration /plugin I have verified that the manager works with the applied credentials, I can login and supply the credentials to my local /manager/html. The problem is that when I deploy through maven as mvn tomcat7:deploy and returns me the dreaded 401 - Unauthorized page with the same credentials. It's almost like maven is not parsing the configuration for the plugin maybe? At this point I don't know what to do. I've turned on verbose output in maven and it shows what appears that the plugin is attempting to upload the war file twice and returns the 401 page. I also have a question as to getting this to work initially. I added the pluginGrouporg.apache.tomcat.maven/pluginGroup to my conf/settings.xml to get the tomcat7 plugin to download and work, is this normal or should I not have to define it here? I mean having to change and version maven settings.xml files seems a bit counter intuitive for preserving maximum portability right, or am I looking at this from the wrong angle? Any information anyone can provide as to where to look or what could be causing this issue, I would be greatly appreciated. Warmest regards, - Josh -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin
2012/12/13 Josh Gooding josh.good...@gmail.com: On Wed, Dec 12, 2012 at 6:05 PM, Olivier Lamy ol...@apache.org wrote: Good detailed description :-). Hey even I get it right once in a while... ;) I just wonder about the cli you are using ? cli as in command line interface? - Win 7, CentOS, and Ubuntu terminals, and yes I get my fair share of flack for not letting Eclipse just do it. Of course I'm a control freak when it comes to my code... :-) I mean mvn tomcat7:deploy or something else ? or you bind deploy to a lifecycle phase ? 2012/12/12 Josh Gooding josh.good...@gmail.com: I didn't want to come here to ask as I always hate to bother anyone, but maybe I should have come here first. I'm coming up short on answers and ideas. I'm having an issue with using maven and the tomcat7 plugin. Maven version -3.0.4 Tomcat version - 7.0.29 .jdk version - 1.6 tomcat7-maven-plugin version - 2.0 Hey group, I am having an issue here with using the tomcat7-maven-plugin in conjunction with the tomcat 7 manager. here's what I have so far. tomcat-users.xml - tomcat-users role rolename=manager-gui/ role rolename=manager-script/ role rolename=admin/ user username=localTomcatAdmin password=password roles=manager-gui,manager-script,admin/ /tomcat-users in my M2_HOME/conf/settings.xml: (note not in my .m2/ directory) (I'll get to this definition in a minute) pluginGroups pluginGrouporg.apache.tomcat.maven/pluginGroup /pluginGroups servers server idLocalTomcatServer/id usernamelocalTomcatAdmin/username passwordpassword/password /server /servers now for the last piece, in my pom-deploy.xml (parent) I have this: plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.0/version configuration serverLocalTomcatServer/server path/TripTixRX/path port8080/port /configuration /plugin I have verified that the manager works with the applied credentials, I can login and supply the credentials to my local /manager/html. The problem is that when I deploy through maven as mvn tomcat7:deploy and returns me the dreaded 401 - Unauthorized page with the same credentials. It's almost like maven is not parsing the configuration for the plugin maybe? At this point I don't know what to do. I've turned on verbose output in maven and it shows what appears that the plugin is attempting to upload the war file twice and returns the 401 page. I also have a question as to getting this to work initially. I added the pluginGrouporg.apache.tomcat.maven/pluginGroup to my conf/settings.xml to get the tomcat7 plugin to download and work, is this normal or should I not have to define it here? I mean having to change and version maven settings.xml files seems a bit counter intuitive for preserving maximum portability right, or am I looking at this from the wrong angle? Any information anyone can provide as to where to look or what could be causing this issue, I would be greatly appreciated. Warmest regards, - Josh -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin
On Thu, Dec 13, 2012 at 9:36 AM, Olivier Lamy ol...@apache.org wrote: 2012/12/13 Josh Gooding josh.good...@gmail.com: On Wed, Dec 12, 2012 at 6:05 PM, Olivier Lamy ol...@apache.org wrote: Good detailed description :-). Hey even I get it right once in a while... ;) I just wonder about the cli you are using ? cli as in command line interface? - Win 7, CentOS, and Ubuntu terminals, and yes I get my fair share of flack for not letting Eclipse just do it. Of course I'm a control freak when it comes to my code... :-) I mean mvn tomcat7:deploy or something else ? or you bind deploy to a lifecycle phase ? Oh I gotcha. tomcat7:deploy I didn't bind the deploy to the life-cycle phase yet. I want to get it working first. 2012/12/12 Josh Gooding josh.good...@gmail.com: I didn't want to come here to ask as I always hate to bother anyone, but maybe I should have come here first. I'm coming up short on answers and ideas. I'm having an issue with using maven and the tomcat7 plugin. Maven version -3.0.4 Tomcat version - 7.0.29 .jdk version - 1.6 tomcat7-maven-plugin version - 2.0 Hey group, I am having an issue here with using the tomcat7-maven-plugin in conjunction with the tomcat 7 manager. here's what I have so far. tomcat-users.xml - tomcat-users role rolename=manager-gui/ role rolename=manager-script/ role rolename=admin/ user username=localTomcatAdmin password=password roles=manager-gui,manager-script,admin/ /tomcat-users in my M2_HOME/conf/settings.xml: (note not in my .m2/ directory) (I'll get to this definition in a minute) pluginGroups pluginGrouporg.apache.tomcat.maven/pluginGroup /pluginGroups servers server idLocalTomcatServer/id usernamelocalTomcatAdmin/username passwordpassword/password /server /servers now for the last piece, in my pom-deploy.xml (parent) I have this: plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.0/version configuration serverLocalTomcatServer/server path/TripTixRX/path port8080/port /configuration /plugin I have verified that the manager works with the applied credentials, I can login and supply the credentials to my local /manager/html. The problem is that when I deploy through maven as mvn tomcat7:deploy and returns me the dreaded 401 - Unauthorized page with the same credentials. It's almost like maven is not parsing the configuration for the plugin maybe? At this point I don't know what to do. I've turned on verbose output in maven and it shows what appears that the plugin is attempting to upload the war file twice and returns the 401 page. I also have a question as to getting this to work initially. I added the pluginGrouporg.apache.tomcat.maven/pluginGroup to my conf/settings.xml to get the tomcat7 plugin to download and work, is this normal or should I not have to define it here? I mean having to change and version maven settings.xml files seems a bit counter intuitive for preserving maximum portability right, or am I looking at this from the wrong angle? Any information anyone can provide as to where to look or what could be causing this issue, I would be greatly appreciated. Warmest regards, - Josh -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat7-maven-plugin
I didn't want to come here to ask as I always hate to bother anyone, but maybe I should have come here first. I'm coming up short on answers and ideas. I'm having an issue with using maven and the tomcat7 plugin. Maven version -3.0.4 Tomcat version - 7.0.29 .jdk version - 1.6 tomcat7-maven-plugin version - 2.0 Hey group, I am having an issue here with using the tomcat7-maven-plugin in conjunction with the tomcat 7 manager. here's what I have so far. tomcat-users.xml - tomcat-users role rolename=manager-gui/ role rolename=manager-script/ role rolename=admin/ user username=localTomcatAdmin password=password roles=manager-gui,manager-script,admin/ /tomcat-users in my M2_HOME/conf/settings.xml: (note not in my .m2/ directory) (I'll get to this definition in a minute) pluginGroups pluginGrouporg.apache.tomcat.maven/pluginGroup /pluginGroups servers server idLocalTomcatServer/id usernamelocalTomcatAdmin/username passwordpassword/password /server /servers now for the last piece, in my pom-deploy.xml (parent) I have this: plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.0/version configuration serverLocalTomcatServer/server path/TripTixRX/path port8080/port /configuration /plugin I have verified that the manager works with the applied credentials, I can login and supply the credentials to my local /manager/html. The problem is that when I deploy through maven as mvn tomcat7:deploy and returns me the dreaded 401 - Unauthorized page with the same credentials. It's almost like maven is not parsing the configuration for the plugin maybe? At this point I don't know what to do. I've turned on verbose output in maven and it shows what appears that the plugin is attempting to upload the war file twice and returns the 401 page. I also have a question as to getting this to work initially. I added the pluginGrouporg.apache.tomcat.maven/pluginGroup to my conf/settings.xml to get the tomcat7 plugin to download and work, is this normal or should I not have to define it here? I mean having to change and version maven settings.xml files seems a bit counter intuitive for preserving maximum portability right, or am I looking at this from the wrong angle? Any information anyone can provide as to where to look or what could be causing this issue, I would be greatly appreciated. Warmest regards, - Josh
Re: tomcat7-maven-plugin
Good detailed description :-). I just wonder about the cli you are using ? 2012/12/12 Josh Gooding josh.good...@gmail.com: I didn't want to come here to ask as I always hate to bother anyone, but maybe I should have come here first. I'm coming up short on answers and ideas. I'm having an issue with using maven and the tomcat7 plugin. Maven version -3.0.4 Tomcat version - 7.0.29 .jdk version - 1.6 tomcat7-maven-plugin version - 2.0 Hey group, I am having an issue here with using the tomcat7-maven-plugin in conjunction with the tomcat 7 manager. here's what I have so far. tomcat-users.xml - tomcat-users role rolename=manager-gui/ role rolename=manager-script/ role rolename=admin/ user username=localTomcatAdmin password=password roles=manager-gui,manager-script,admin/ /tomcat-users in my M2_HOME/conf/settings.xml: (note not in my .m2/ directory) (I'll get to this definition in a minute) pluginGroups pluginGrouporg.apache.tomcat.maven/pluginGroup /pluginGroups servers server idLocalTomcatServer/id usernamelocalTomcatAdmin/username passwordpassword/password /server /servers now for the last piece, in my pom-deploy.xml (parent) I have this: plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.0/version configuration serverLocalTomcatServer/server path/TripTixRX/path port8080/port /configuration /plugin I have verified that the manager works with the applied credentials, I can login and supply the credentials to my local /manager/html. The problem is that when I deploy through maven as mvn tomcat7:deploy and returns me the dreaded 401 - Unauthorized page with the same credentials. It's almost like maven is not parsing the configuration for the plugin maybe? At this point I don't know what to do. I've turned on verbose output in maven and it shows what appears that the plugin is attempting to upload the war file twice and returns the 401 page. I also have a question as to getting this to work initially. I added the pluginGrouporg.apache.tomcat.maven/pluginGroup to my conf/settings.xml to get the tomcat7 plugin to download and work, is this normal or should I not have to define it here? I mean having to change and version maven settings.xml files seems a bit counter intuitive for preserving maximum portability right, or am I looking at this from the wrong angle? Any information anyone can provide as to where to look or what could be causing this issue, I would be greatly appreciated. Warmest regards, - Josh -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin 2.0-SNAPSHOT:deploy ignores server configuration
vote started see: http://markmail.org/message/ewcp3ukbcoogtswh 2012/9/12 Gert van Spijker g...@ab-graph.com: On 11/09/12 20:34, Olivier Lamy wrote: Hi, Some issues has been fixed regarding that. Is there any logs on server side. Did you try a recent snapshot or build yourself ? No, I didn't. But I googled a bit more and found this: http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/snapshot-test.html I added the repositories as described and tested. The current snapshot does indeed solve the problem. Thanks. This seems like a fairly fundamental issue. Are the main stream repositories going to be updated soon? Or would it otherwise be a good idea to make a note about this in the documentation? Gert 2012/9/11 Gert van Spijker g...@ab-graph.com: Hi, If this is not the correct list to ask about the Tomcat Maven plugins then I apologize in advance. I have been googiling for better places, but to no avail. I have a Maven Web application project and am trying to deploy to a local Tomcat 7 server on http://localhost:8080. I can access this server with my browser and deploy the web app manually. I also set the correct credentials in the maven settings.xml configuration file. I follow the documentation about the tomcat7:deploy goal: http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/deploy-mojo.html Although the server is running on the plugin's default URL I get a 403 HTTP error. I have tried to add the .text using the url parameter, but this is completely ignored (I can see in the plugin output that it always uses the default URL) I also set the server parameter to match the id in mavens settings.xml but the behavior does not change. It seems that tomcat7-maven-plugin 2.0-SNAPSHOT ignores its parameters. Or am I doing something wrong? Gert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat7-maven-plugin 2.0-SNAPSHOT:deploy ignores server configuration
Hi, If this is not the correct list to ask about the Tomcat Maven plugins then I apologize in advance. I have been googiling for better places, but to no avail. I have a Maven Web application project and am trying to deploy to a local Tomcat 7 server on http://localhost:8080. I can access this server with my browser and deploy the web app manually. I also set the correct credentials in the maven settings.xml configuration file. I follow the documentation about the tomcat7:deploy goal: http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/deploy-mojo.html Although the server is running on the plugin's default URL I get a 403 HTTP error. I have tried to add the .text using the url parameter, but this is completely ignored (I can see in the plugin output that it always uses the default URL) I also set the server parameter to match the id in mavens settings.xml but the behavior does not change. It seems that tomcat7-maven-plugin 2.0-SNAPSHOT ignores its parameters. Or am I doing something wrong? Gert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin 2.0-SNAPSHOT:deploy ignores server configuration
Hi, Some issues has been fixed regarding that. Is there any logs on server side. Did you try a recent snapshot or build yourself ? 2012/9/11 Gert van Spijker g...@ab-graph.com: Hi, If this is not the correct list to ask about the Tomcat Maven plugins then I apologize in advance. I have been googiling for better places, but to no avail. I have a Maven Web application project and am trying to deploy to a local Tomcat 7 server on http://localhost:8080. I can access this server with my browser and deploy the web app manually. I also set the correct credentials in the maven settings.xml configuration file. I follow the documentation about the tomcat7:deploy goal: http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/deploy-mojo.html Although the server is running on the plugin's default URL I get a 403 HTTP error. I have tried to add the .text using the url parameter, but this is completely ignored (I can see in the plugin output that it always uses the default URL) I also set the server parameter to match the id in mavens settings.xml but the behavior does not change. It seems that tomcat7-maven-plugin 2.0-SNAPSHOT ignores its parameters. Or am I doing something wrong? Gert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin 2.0-SNAPSHOT:deploy ignores server configuration
On 11/09/12 20:34, Olivier Lamy wrote: Hi, Some issues has been fixed regarding that. Is there any logs on server side. Did you try a recent snapshot or build yourself ? No, I didn't. But I googled a bit more and found this: http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/snapshot-test.html I added the repositories as described and tested. The current snapshot does indeed solve the problem. Thanks. This seems like a fairly fundamental issue. Are the main stream repositories going to be updated soon? Or would it otherwise be a good idea to make a note about this in the documentation? Gert 2012/9/11 Gert van Spijker g...@ab-graph.com: Hi, If this is not the correct list to ask about the Tomcat Maven plugins then I apologize in advance. I have been googiling for better places, but to no avail. I have a Maven Web application project and am trying to deploy to a local Tomcat 7 server on http://localhost:8080. I can access this server with my browser and deploy the web app manually. I also set the correct credentials in the maven settings.xml configuration file. I follow the documentation about the tomcat7:deploy goal: http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/deploy-mojo.html Although the server is running on the plugin's default URL I get a 403 HTTP error. I have tried to add the .text using the url parameter, but this is completely ignored (I can see in the plugin output that it always uses the default URL) I also set the server parameter to match the id in mavens settings.xml but the behavior does not change. It seems that tomcat7-maven-plugin 2.0-SNAPSHOT ignores its parameters. Or am I doing something wrong? Gert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
2012/8/30 Knute Snortum ksnor...@catalystitservices.com:
See below:
-Original Message-
From: Knute Snortum [mailto:ksnor...@catalystitservices.com]
Sent: Wednesday, August 29, 2012 3:05 PM
To: Tomcat Users List
Subject: RE: tomcat7-maven-plugin doesn't understand Maven filtering of
context files?
-Original Message-
From: Olivier Lamy [mailto:ol...@apache.org]
Sent: Wednesday, August 29, 2012 9:32 AM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering
of context files?
[section deleted]
What cli are you using ?
If I understand you, it's this:
mvn clean install tomcat:run -P development
I'm making that up because it's actually run from an Eclipse form.
When I run that from the command line in the project folder, I get the
same results so I think it's right...
I just noticed that the CLI should be:
mvn clean install tomcat7:run -P development
...with tomcat7 not tomcat. This gives me the Tomcat 2.0-beta-1
version that we were excepting. I also notice the debug flag (-e?)
and that gives me a ton of info. Should I repost the output, or some
of it?
Add as an attachment?
Regarding the flag have a look at what mvn -h says :-) (-X is for full
debug trace)
Maybe in a jira issue yes but not sure that will help
BTW do you have any sample project to reproduce your issue ?
It would be complex to do this, but I'm going to try. I'm not sure
how I would post that.
Just share a project via bitbucket or github.
Is there anything else I should do? I don't want to report this as a bug if
it's working as designed. But I was hoping I wouldn't have to setup my own,
private Tomcat server to do development.
Thanks for the project that helps me to understand your problem :-)
The filtering here is done by the maven-war-plugin so the tomcat7
doesn't have any idea of that !
The plugin use warSourceDirectory
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/run-mojo.html#warSourceDirectory
So by default web.xml is src/main/webapp/WEB-INF/web.xml and the file
is not filtered
In your case you can add
warSourceDirectory${project.build.directory}/${project.artifactId}-${project.version}/warSourceDirectory
to the tomcat7 plugin configuration
and run: mvn clean install tomcat7:run
and it looks it works no more debug mode and it will use the filtered file.
HTH
I created a test project in Github:
https://github.com/ksnortum/Tomcat7MavenPluginTester
It demonstrates what I believe is a bug in tomcat7-maven-plugin. The
Tomcat server that is created does not use the configuration files
(e.g.: web.xml) in the war file or the war directory that is created.
It uses the project files, that is, the ones in src/main/webapp/WEB-
INF. If you use Maven web resource filtering, the war file is changed
but the project file isn't. This is correct. But if tomcat7-maven-
plugin doesn't use the war configuration files, then how can you
properly test the war file?
- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
-Original Message-
From: Olivier Lamy [mailto:ol...@apache.org]
Sent: Friday, August 31, 2012 6:58 AM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of
context files?
2012/8/30 Knute Snortum ksnor...@catalystitservices.com:
See below:
-Original Message-
From: Knute Snortum [mailto:ksnor...@catalystitservices.com]
Sent: Wednesday, August 29, 2012 3:05 PM
To: Tomcat Users List
Subject: RE: tomcat7-maven-plugin doesn't understand Maven filtering
of context files?
-Original Message-
From: Olivier Lamy [mailto:ol...@apache.org]
Sent: Wednesday, August 29, 2012 9:32 AM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven
filtering of context files?
[section deleted]
What cli are you using ?
If I understand you, it's this:
mvn clean install tomcat:run -P development
I'm making that up because it's actually run from an Eclipse
form.
When I run that from the command line in the project folder, I get
the same results so I think it's right...
I just noticed that the CLI should be:
mvn clean install tomcat7:run -P development
...with tomcat7 not tomcat. This gives me the Tomcat
2.0-beta-1
version that we were excepting. I also notice the debug flag (-e?)
and that gives me a ton of info. Should I repost the output, or
some
of it?
Add as an attachment?
Regarding the flag have a look at what mvn -h says :-) (-X is for
full debug trace)
Maybe in a jira issue yes but not sure that will help
BTW do you have any sample project to reproduce your issue ?
It would be complex to do this, but I'm going to try. I'm not
sure
how I would post that.
Just share a project via bitbucket or github.
Is there anything else I should do? I don't want to report this as a
bug if it's working as designed. But I was hoping I wouldn't have to
setup my own, private Tomcat server to do development.
Thanks for the project that helps me to understand your problem :-)
The filtering here is done by the maven-war-plugin so the tomcat7
doesn't have any idea of that !
The plugin use warSourceDirectory
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-
plugin/run-mojo.html#warSourceDirectory
So by default web.xml is src/main/webapp/WEB-INF/web.xml and the file is
not filtered
In your case you can add
warSourceDirectory${project.build.directory}/${project.artifactId}-
${project.version}/warSourceDirectory
to the tomcat7 plugin configuration
and run: mvn clean install tomcat7:run
and it looks it works no more debug mode and it will use the filtered
file.
HTH
That was it! You solved a problem that has been haunting me for about a month!
Thank you.
Just for your notes, the default directory for the Maven filtering plugin is
${project.build.directory}/${project.build.finalName}, and the final name
defaults to ${project.artifactId}-${project.version}. I say that in case you
or anyone uses buildfinalName in their POM.
Thanks again!
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
See below: -Original Message- From: Knute Snortum [mailto:ksnor...@catalystitservices.com] Sent: Wednesday, August 29, 2012 3:05 PM To: Tomcat Users List Subject: RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files? -Original Message- From: Olivier Lamy [mailto:ol...@apache.org] Sent: Wednesday, August 29, 2012 9:32 AM To: Tomcat Users List Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files? [section deleted] What cli are you using ? If I understand you, it's this: mvn clean install tomcat:run -P development I'm making that up because it's actually run from an Eclipse form. When I run that from the command line in the project folder, I get the same results so I think it's right... I just noticed that the CLI should be: mvn clean install tomcat7:run -P development ...with tomcat7 not tomcat. This gives me the Tomcat 2.0-beta-1 version that we were excepting. I also notice the debug flag (-e?) and that gives me a ton of info. Should I repost the output, or some of it? Add as an attachment? Regarding the flag have a look at what mvn -h says :-) (-X is for full debug trace) Maybe in a jira issue yes but not sure that will help BTW do you have any sample project to reproduce your issue ? It would be complex to do this, but I'm going to try. I'm not sure how I would post that. Just share a project via bitbucket or github. Is there anything else I should do? I don't want to report this as a bug if it's working as designed. But I was hoping I wouldn't have to setup my own, private Tomcat server to do development. I created a test project in Github: https://github.com/ksnortum/Tomcat7MavenPluginTester It demonstrates what I believe is a bug in tomcat7-maven-plugin. The Tomcat server that is created does not use the configuration files (e.g.: web.xml) in the war file or the war directory that is created. It uses the project files, that is, the ones in src/main/webapp/WEB- INF. If you use Maven web resource filtering, the war file is changed but the project file isn't. This is correct. But if tomcat7-maven- plugin doesn't use the war configuration files, then how can you properly test the war file? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
2012/8/29 Knute Snortum ksnor...@catalystitservices.com:
-Original Message-
From: Olivier Lamy [mailto:ol...@apache.org]
Sent: Tuesday, August 28, 2012 2:17 PM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of
context files?
Hi,
Inline
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
If this is the wrong mailing list for tomcat7-maven-plugin, could
someone direct me to the right place?
I'm developing a Vaadin web app in Eclipse Juno on Windows 7 and I'm
using the tomcat7-maven-plugin 2.0-beta-1 to help in development by
running the app in Tomcat inside of the IDE -- or I'm trying. The error
I'm getting is:
org.springframework.beans.factory.BeanDefinitionStoreException:
Invalid bean definition with name 'dataSource' defined in
ServletContext resource [/WEB-INF/applicationContext.xml]: Could not
resolve placeholder 'db.driverClassName' in string value
[${db.driverClassName}]
applicationContext.xml is my Spring context file. I have
placeholders in it to point to the correct database based on Maven
profiles and filtering. So a piece of applicationContext.xml looks like
this:
bean id=dataSource
class=org.apache.commons.dbcp.BasicDataSource destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url} /
property name=username
value=${db.username} /
property name=password
value=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean
that does not have the placeholders replaced yet.
The odd thing is that in the war file and the directory under target
that the war file is created from, all the place holders have been
correctly substituted. I can see them in an editor. The context file
with the placeholders is the one still sitting in my development folder.
So my question is, why isn't the Tomcat plugin seeing the context file
in the war file or folder? And if it looks in the development folder
for the file, can Maven filtering work with the plugin?.
as you are using gwt maven plugin, I'm not sure that works.
Something you can do is using sys properties in tomcat7/6-maven-plugin
(spring placeholder resolves against sys props too).
Add you sys props as it:
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat6-maven-
plugin/examples/add-system-properties.html
Well, I'm using Maven filtering, and the reason for that is my client
requires that I use Maven profiling to set the development and the production
environments. So I'd have to a Maven Tomcat plugin in each profile -- which
maybe I'll do.
I need the GWT plugin because this is a Vaadin project and Vaadin uses GWT.
Below is part of the messages created by Maven et al in my IDE
console. I've left out the clean and testing messages and most of the
stacktrace, which I think is from Spring anyway:
[INFO]
[INFO] --- gwt-maven-plugin:2.4.0:compile (default) @ dpt --- [INFO]
auto discovered modules
[com.catalystitservices.nike.dpt.widgetset.DptWidgetset]
[INFO] com.catalystitservices.nike.dpt.widgetset.DptWidgetset is up to
date. GWT compilation skipped [INFO] [INFO] ---
maven-war-plugin:2.2:war (default-war) @ dpt --- [INFO] Packaging
webapp [INFO] Assembling webapp [dpt] in [C:\Projects\DPT\target\dpt]
[INFO] Processing war project [INFO] Copying webapp webResources
[C:\Projects\DPT\src/main/webapp/] to [C:\Projects\DPT\target\dpt]
[INFO] Copying webapp resources [C:\Projects\DPT\src\main\webapp]
[INFO] Webapp assembled in [1442 msecs] [INFO] Building war:
C:\Projects\DPT\target\dpt.war [INFO] [INFO] ---
tomcat7-maven-plugin:2.0-beta-1:exec-war-only (tomcat-run) @ dpt ---
[INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install)
@ dpt --- [INFO] Installing C:\Projects\DPT\target\dpt.war to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1
-SNAPSHOT.war [INFO] Installing C:\Projects\DPT\pom.xml to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1
-SNAPSHOT.pom [INFO] Installing
C:\Projects\DPT\target\dpt-1.1-SNAPSHOT-war-exec.jar to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1
-SNAPSHOT-exec-war.jar
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
you are using an old version here ? Don't you have duplicate entries in
your pom ?
There's no duplicate. The one I have looks like this:
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version${tomcat7MavenPlugin}/version
...
And my properties look like:
tomcat7MavenPlugin2.0-beta-1
RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
[part of message deleted]
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
you are using an old version here ? Don't you have duplicate entries
in your pom ?
There's no duplicate. The one I have looks like this:
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version${tomcat7MavenPlugin}/version
...
And my properties look like:
tomcat7MavenPlugin2.0-beta-1/tomcat7MavenPlugin
Ok but the logs doesn't says that :-)
True. I'm not sure why. I'll fool with it some.
What cli are you using ?
If I understand you, it's this:
mvn clean install tomcat:run -P development
I'm making that up because it's actually run from an Eclipse form. When I run
that from the command line in the project folder, I get the same results so I
think it's right...
I just noticed that the CLI should be:
mvn clean install tomcat7:run -P development
...with tomcat7 not tomcat. This gives me the Tomcat 2.0-beta-1 version
that we were excepting. I also notice the debug flag (-e?) and that gives me a
ton of info. Should I repost the output, or some of it? Add as an attachment?
BTW do you have any sample project to reproduce your issue ?
It would be complex to do this, but I'm going to try. I'm not sure how I would
post that.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
2012/8/29 Knute Snortum ksnor...@catalystitservices.com:
[part of message deleted]
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
you are using an old version here ? Don't you have duplicate entries
in your pom ?
There's no duplicate. The one I have looks like this:
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version${tomcat7MavenPlugin}/version
...
And my properties look like:
tomcat7MavenPlugin2.0-beta-1/tomcat7MavenPlugin
Ok but the logs doesn't says that :-)
True. I'm not sure why. I'll fool with it some.
What cli are you using ?
If I understand you, it's this:
mvn clean install tomcat:run -P development
I'm making that up because it's actually run from an Eclipse form. When I
run that from the command line in the project folder, I get the same results
so I think it's right...
I just noticed that the CLI should be:
mvn clean install tomcat7:run -P development
...with tomcat7 not tomcat. This gives me the Tomcat 2.0-beta-1 version
that we were excepting. I also notice the debug flag (-e?) and that gives me
a ton of info. Should I repost the output, or some of it? Add as an
attachment?
Regarding the flag have a look at what mvn -h says :-) (-X is for full
debug trace)
Maybe in a jira issue yes but not sure that will help
BTW do you have any sample project to reproduce your issue ?
It would be complex to do this, but I'm going to try. I'm not sure how I
would post that.
Just share a project via bitbucket or github.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
-Original Message- From: Olivier Lamy [mailto:ol...@apache.org] Sent: Wednesday, August 29, 2012 9:32 AM To: Tomcat Users List Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files? [section deleted] What cli are you using ? If I understand you, it's this: mvn clean install tomcat:run -P development I'm making that up because it's actually run from an Eclipse form. When I run that from the command line in the project folder, I get the same results so I think it's right... I just noticed that the CLI should be: mvn clean install tomcat7:run -P development ...with tomcat7 not tomcat. This gives me the Tomcat 2.0-beta-1 version that we were excepting. I also notice the debug flag (-e?) and that gives me a ton of info. Should I repost the output, or some of it? Add as an attachment? Regarding the flag have a look at what mvn -h says :-) (-X is for full debug trace) Maybe in a jira issue yes but not sure that will help BTW do you have any sample project to reproduce your issue ? It would be complex to do this, but I'm going to try. I'm not sure how I would post that. Just share a project via bitbucket or github. I created a test project in Github: https://github.com/ksnortum/Tomcat7MavenPluginTester It demonstrates what I believe is a bug in tomcat7-maven-plugin. The Tomcat server that is created does not use the configuration files (e.g.: web.xml) in the war file or the war directory that is created. It uses the project files, that is, the ones in src/main/webapp/WEB-INF. If you use Maven web resource filtering, the war file is changed but the project file isn't. This is correct. But if tomcat7-maven-plugin doesn't use the war configuration files, then how can you properly test the war file? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat7-maven-plugin doesn't understand Maven filtering of context files?
If this is the wrong mailing list for tomcat7-maven-plugin, could someone
direct me to the right place?
I'm developing a Vaadin web app in Eclipse Juno on Windows 7 and I'm using the
tomcat7-maven-plugin 2.0-beta-1 to help in development by running the app in
Tomcat inside of the IDE -- or I'm trying. The error I'm getting is:
org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean
definition with name 'dataSource' defined in ServletContext resource
[/WEB-INF/applicationContext.xml]: Could not resolve placeholder
'db.driverClassName' in string value [${db.driverClassName}]
applicationContext.xml is my Spring context file. I have placeholders in it
to point to the correct database based on Maven profiles and filtering. So a
piece of applicationContext.xml looks like this:
bean id=dataSource class=org.apache.commons.dbcp.BasicDataSource
destroy-method=close
property name=driverClassName value=${db.driverClassName}
/
property name=url value=${db.url} /
property name=usernamevalue=${db.username} /
property name=passwordvalue=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean that does
not have the placeholders replaced yet.
The odd thing is that in the war file and the directory under target that the
war file is created from, all the place holders have been correctly
substituted. I can see them in an editor. The context file with the
placeholders is the one still sitting in my development folder.
So my question is, why isn't the Tomcat plugin seeing the context file in the
war file or folder? And if it looks in the development folder for the file,
can Maven filtering work with the plugin?.
Below is part of the messages created by Maven et al in my IDE console. I've
left out the clean and testing messages and most of the stacktrace, which I
think is from Spring anyway:
[INFO]
[INFO] --- gwt-maven-plugin:2.4.0:compile (default) @ dpt ---
[INFO] auto discovered modules
[com.catalystitservices.nike.dpt.widgetset.DptWidgetset]
[INFO] com.catalystitservices.nike.dpt.widgetset.DptWidgetset is up to date.
GWT compilation skipped
[INFO]
[INFO] --- maven-war-plugin:2.2:war (default-war) @ dpt ---
[INFO] Packaging webapp
[INFO] Assembling webapp [dpt] in [C:\Projects\DPT\target\dpt]
[INFO] Processing war project
[INFO] Copying webapp webResources [C:\Projects\DPT\src/main/webapp/] to
[C:\Projects\DPT\target\dpt]
[INFO] Copying webapp resources [C:\Projects\DPT\src\main\webapp]
[INFO] Webapp assembled in [1442 msecs]
[INFO] Building war: C:\Projects\DPT\target\dpt.war
[INFO]
[INFO] --- tomcat7-maven-plugin:2.0-beta-1:exec-war-only (tomcat-run) @ dpt ---
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ dpt ---
[INFO] Installing C:\Projects\DPT\target\dpt.war to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1-SNAPSHOT.war
[INFO] Installing C:\Projects\DPT\pom.xml to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1-SNAPSHOT.pom
[INFO] Installing C:\Projects\DPT\target\dpt-1.1-SNAPSHOT-war-exec.jar to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1-SNAPSHOT-exec-war.jar
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
[INFO]
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ dpt ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO]
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ dpt ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
[INFO]
[INFO] --- tomcat-maven-plugin:1.1:run (default-cli) @ dpt ---
[INFO] Running war on http://localhost:8080/dpt
[INFO] Creating Tomcat server configuration at C:\Projects\DPT\target\tomcat
Aug 28, 2012 10:13:59 AM org.apache.catalina.startup.Embedded start
INFO: Starting tomcat server
Aug 28, 2012 10:14:00 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.29
Aug 28, 2012 10:14:00 AM org.apache.catalina.core.ApplicationContext log
INFO: Set web app root system property: 'webapp.root' =
[C:\Projects\DPT\src\main\webapp\]
Aug 28, 2012 10:14:00 AM org.apache.catalina.core.ApplicationContext log
INFO: Initializing log4j from [classpath:log4j.properties]
Aug 28, 2012 10:14:00 AM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
28.08.2012 10:14:00 INFO (ContextLoader.java:272) - Root
WebApplicationContext: initialization started
28.08.2012 10:14:00 INFO (AbstractApplicationContext.java:500) - Refreshing
Root WebApplicationContext: startup date [Tue Aug 28 10
Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
If this is the wrong mailing list for tomcat7-maven-plugin, could someone
direct me to the right place?
Yes, this is the list.
I'm developing a Vaadin web app in Eclipse Juno on Windows 7 and I'm using
the tomcat7-maven-plugin 2.0-beta-1 to help in development by running the app
in Tomcat inside of the IDE -- or I'm trying. The error I'm getting is:
org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean
definition with name 'dataSource' defined in ServletContext resource
[/WEB-INF/applicationContext.xml]: Could not resolve placeholder
'db.driverClassName' in string value [${db.driverClassName}]
applicationContext.xml is my Spring context file. I have placeholders in
it to point to the correct database based on Maven profiles and filtering.
So a piece of applicationContext.xml looks like this:
bean id=dataSource class=org.apache.commons.dbcp.BasicDataSource
destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url} /
property name=usernamevalue=${db.username} /
property name=passwordvalue=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean that does
not have the placeholders replaced yet.
Usually it is Spring job to resolve those.
(It has nothing to to with Tomcat or Maven).
See org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
The odd thing is that in the war file and the directory under target that the
war file is created from, all the place holders have been correctly
substituted. I can see them in an editor. The context file with the
placeholders is the one still sitting in my development folder.
So my question is, why isn't the Tomcat plugin seeing the context file in the
war file or folder? And if it looks in the development folder for the file,
can Maven filtering work with the plugin?.
Below is part of the messages created by Maven et al in my IDE console. I've
left out the clean and testing messages and most of the stacktrace, which I
think is from Spring anyway:
(...)
28.08.2012 10:14:01 ERROR (ContextLoader.java:307) - Context initialization
failed
org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean
definition with name 'dataSource' defined in ServletContext resource
[/WEB-INF/applicationContext.xml]: Could not resolve placeholder
'db.driverClassName' in string value [${db.driverClassName}]
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Tuesday, August 28, 2012 11:15 AM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of
context files?
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
If this is the wrong mailing list for tomcat7-maven-plugin, could
someone direct me to the right place?
Yes, this is the list.
Thanks
I'm developing a Vaadin web app in Eclipse Juno on Windows 7 and I'm
using the tomcat7-maven-plugin 2.0-beta-1 to help in development by
running the app in Tomcat inside of the IDE -- or I'm trying. The error
I'm getting is:
org.springframework.beans.factory.BeanDefinitionStoreException:
Invalid bean definition with name 'dataSource' defined in ServletContext
resource [/WEB-INF/applicationContext.xml]: Could not resolve
placeholder 'db.driverClassName' in string value [${db.driverClassName}]
applicationContext.xml is my Spring context file. I have
placeholders in it to point to the correct database based on Maven
profiles and filtering. So a piece of applicationContext.xml looks like
this:
bean id=dataSource
class=org.apache.commons.dbcp.BasicDataSource destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url} /
property name=username
value=${db.username} /
property name=password
value=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean
that does not have the placeholders replaced yet.
Usually it is Spring job to resolve those.
(It has nothing to to with Tomcat or Maven).
See
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
Well, I'm using Maven filtering, but regardless, I thought the whole point of
the tomcat7-maven-plugin was to run the *war* file, not the development
(project) files. If it doesn't, it's useless to me. Or maybe I should ask,
How does one run the war file created with mvn clean install in the IDE
(Eclipse)?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
applicationContext.xml is my Spring context file. I have
placeholders in it to point to the correct database based on Maven
profiles and filtering. So a piece of applicationContext.xml looks like
this:
bean id=dataSource
class=org.apache.commons.dbcp.BasicDataSource destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url} /
property name=username
value=${db.username} /
property name=password
value=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean
that does not have the placeholders replaced yet.
Usually it is Spring job to resolve those.
(It has nothing to to with Tomcat or Maven).
See
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
Well, I'm using Maven filtering, but regardless, I thought the whole point of
the tomcat7-maven-plugin was to run the *war* file, not the development
(project) files.
Your question was about applicationContext.xml. That is an essential
part of a Spring web application. It is not just a project file.
Now you are changing the topic...
Tomcat knows nothing about Spring, and context has different meaning
in Tomcat (referring to the META-INF/context.xml file in a web
application, see Tomcat Configuration Reference in Tomcat 7
documentation).
If you need apply filtering to your data file (that
applicationContext.xml one), shouldn't you configure so explicitly
somewhere?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Tuesday, August 28, 2012 12:02 PM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of
context files?
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
applicationContext.xml is my Spring context file. I have
placeholders in it to point to the correct database based on Maven
profiles and filtering. So a piece of applicationContext.xml looks
like
this:
bean id=dataSource
class=org.apache.commons.dbcp.BasicDataSource
destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url}
/
property name=username
value=${db.username} /
property name=password
value=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean
that does not have the placeholders replaced yet.
Usually it is Spring job to resolve those.
(It has nothing to to with Tomcat or Maven).
See
org.springframework.beans.factory.config.PropertyPlaceholderConfigure
r
Well, I'm using Maven filtering, but regardless, I thought the whole
point of the tomcat7-maven-plugin was to run the *war* file, not the
development (project) files.
Your question was about applicationContext.xml. That is an essential
part of a Spring web application. It is not just a project file.
Now you are changing the topic...
I'm not trying to. It's the applicationContext.xml file that gets changed by
Maven filtering, then it gets put into the war file by the tomcat plugin. I
want the plugin to run the war run, not the still in the project with the
placeholders. That's what I thought it did.
Tomcat knows nothing about Spring, and context has different meaning
in Tomcat (referring to the META-INF/context.xml file in a web
application, see Tomcat Configuration Reference in Tomcat 7
documentation).
If you need apply filtering to your data file (that
applicationContext.xml one), shouldn't you configure so explicitly
somewhere?
I do, and it works perfectly. It creates my context files with the database
data in them as it should. These files are built into a war file. I want the
Tomcat plugin to run the war file.
When I manually deploy the war file that is created, it works perfectly. I
thought the point of the Tomcat plugin was that I didn't have to manually
deploy the war file.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
Hi,
Inline
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
If this is the wrong mailing list for tomcat7-maven-plugin, could someone
direct me to the right place?
I'm developing a Vaadin web app in Eclipse Juno on Windows 7 and I'm using
the tomcat7-maven-plugin 2.0-beta-1 to help in development by running the app
in Tomcat inside of the IDE -- or I'm trying. The error I'm getting is:
org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean
definition with name 'dataSource' defined in ServletContext resource
[/WEB-INF/applicationContext.xml]: Could not resolve placeholder
'db.driverClassName' in string value [${db.driverClassName}]
applicationContext.xml is my Spring context file. I have placeholders in
it to point to the correct database based on Maven profiles and filtering.
So a piece of applicationContext.xml looks like this:
bean id=dataSource class=org.apache.commons.dbcp.BasicDataSource
destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url} /
property name=usernamevalue=${db.username} /
property name=passwordvalue=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean that does
not have the placeholders replaced yet.
The odd thing is that in the war file and the directory under target that the
war file is created from, all the place holders have been correctly
substituted. I can see them in an editor. The context file with the
placeholders is the one still sitting in my development folder.
So my question is, why isn't the Tomcat plugin seeing the context file in the
war file or folder? And if it looks in the development folder for the file,
can Maven filtering work with the plugin?.
as you are using gwt maven plugin, I'm not sure that works.
Something you can do is using sys properties in tomcat7/6-maven-plugin
(spring placeholder resolves against sys props too).
Add you sys props as it:
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat6-maven-plugin/examples/add-system-properties.html
Below is part of the messages created by Maven et al in my IDE console. I've
left out the clean and testing messages and most of the stacktrace, which I
think is from Spring anyway:
[INFO]
[INFO] --- gwt-maven-plugin:2.4.0:compile (default) @ dpt ---
[INFO] auto discovered modules
[com.catalystitservices.nike.dpt.widgetset.DptWidgetset]
[INFO] com.catalystitservices.nike.dpt.widgetset.DptWidgetset is up to date.
GWT compilation skipped
[INFO]
[INFO] --- maven-war-plugin:2.2:war (default-war) @ dpt ---
[INFO] Packaging webapp
[INFO] Assembling webapp [dpt] in [C:\Projects\DPT\target\dpt]
[INFO] Processing war project
[INFO] Copying webapp webResources [C:\Projects\DPT\src/main/webapp/] to
[C:\Projects\DPT\target\dpt]
[INFO] Copying webapp resources [C:\Projects\DPT\src\main\webapp]
[INFO] Webapp assembled in [1442 msecs]
[INFO] Building war: C:\Projects\DPT\target\dpt.war
[INFO]
[INFO] --- tomcat7-maven-plugin:2.0-beta-1:exec-war-only (tomcat-run) @ dpt
---
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ dpt ---
[INFO] Installing C:\Projects\DPT\target\dpt.war to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1-SNAPSHOT.war
[INFO] Installing C:\Projects\DPT\pom.xml to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1-SNAPSHOT.pom
[INFO] Installing C:\Projects\DPT\target\dpt-1.1-SNAPSHOT-war-exec.jar to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1-SNAPSHOT-exec-war.jar
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
you are using an old version here ? Don't you have duplicate entries
in your pom ?
[INFO]
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ dpt ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO]
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ dpt ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
[INFO]
[INFO] --- tomcat-maven-plugin:1.1:run (default-cli) @ dpt ---
[INFO] Running war on http://localhost:8080/dpt
[INFO] Creating Tomcat server configuration at C:\Projects\DPT\target\tomcat
Aug 28, 2012 10:13:59 AM org.apache.catalina.startup.Embedded start
INFO: Starting tomcat server
Aug 28, 2012 10:14:00 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.29
Aug 28, 2012 10:14:00 AM org.apache.catalina.core.ApplicationContext log
INFO: Set web app root system property
RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
-Original Message-
From: Olivier Lamy [mailto:ol...@apache.org]
Sent: Tuesday, August 28, 2012 2:17 PM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of
context files?
Hi,
Inline
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
If this is the wrong mailing list for tomcat7-maven-plugin, could
someone direct me to the right place?
I'm developing a Vaadin web app in Eclipse Juno on Windows 7 and I'm
using the tomcat7-maven-plugin 2.0-beta-1 to help in development by
running the app in Tomcat inside of the IDE -- or I'm trying. The error
I'm getting is:
org.springframework.beans.factory.BeanDefinitionStoreException:
Invalid bean definition with name 'dataSource' defined in
ServletContext resource [/WEB-INF/applicationContext.xml]: Could not
resolve placeholder 'db.driverClassName' in string value
[${db.driverClassName}]
applicationContext.xml is my Spring context file. I have
placeholders in it to point to the correct database based on Maven
profiles and filtering. So a piece of applicationContext.xml looks like
this:
bean id=dataSource
class=org.apache.commons.dbcp.BasicDataSource destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url} /
property name=username
value=${db.username} /
property name=password
value=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean
that does not have the placeholders replaced yet.
The odd thing is that in the war file and the directory under target
that the war file is created from, all the place holders have been
correctly substituted. I can see them in an editor. The context file
with the placeholders is the one still sitting in my development folder.
So my question is, why isn't the Tomcat plugin seeing the context file
in the war file or folder? And if it looks in the development folder
for the file, can Maven filtering work with the plugin?.
as you are using gwt maven plugin, I'm not sure that works.
Something you can do is using sys properties in tomcat7/6-maven-plugin
(spring placeholder resolves against sys props too).
Add you sys props as it:
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat6-maven-
plugin/examples/add-system-properties.html
Well, I'm using Maven filtering, and the reason for that is my client requires
that I use Maven profiling to set the development and the production
environments. So I'd have to a Maven Tomcat plugin in each profile -- which
maybe I'll do.
I need the GWT plugin because this is a Vaadin project and Vaadin uses GWT.
Below is part of the messages created by Maven et al in my IDE
console. I've left out the clean and testing messages and most of the
stacktrace, which I think is from Spring anyway:
[INFO]
[INFO] --- gwt-maven-plugin:2.4.0:compile (default) @ dpt --- [INFO]
auto discovered modules
[com.catalystitservices.nike.dpt.widgetset.DptWidgetset]
[INFO] com.catalystitservices.nike.dpt.widgetset.DptWidgetset is up to
date. GWT compilation skipped [INFO] [INFO] ---
maven-war-plugin:2.2:war (default-war) @ dpt --- [INFO] Packaging
webapp [INFO] Assembling webapp [dpt] in [C:\Projects\DPT\target\dpt]
[INFO] Processing war project [INFO] Copying webapp webResources
[C:\Projects\DPT\src/main/webapp/] to [C:\Projects\DPT\target\dpt]
[INFO] Copying webapp resources [C:\Projects\DPT\src\main\webapp]
[INFO] Webapp assembled in [1442 msecs] [INFO] Building war:
C:\Projects\DPT\target\dpt.war [INFO] [INFO] ---
tomcat7-maven-plugin:2.0-beta-1:exec-war-only (tomcat-run) @ dpt ---
[INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install)
@ dpt --- [INFO] Installing C:\Projects\DPT\target\dpt.war to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1
-SNAPSHOT.war [INFO] Installing C:\Projects\DPT\pom.xml to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1
-SNAPSHOT.pom [INFO] Installing
C:\Projects\DPT\target\dpt-1.1-SNAPSHOT-war-exec.jar to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1
-SNAPSHOT-exec-war.jar
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
you are using an old version here ? Don't you have duplicate entries in
your pom ?
There's no duplicate. The one I have looks like this:
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version${tomcat7MavenPlugin}/version
...
And my properties look like:
tomcat7MavenPlugin2.0-beta-1/tomcat7MavenPlugin
[INFO]
[INFO] --- maven-resources-plugin:2.5
Re: Tomcat7-maven-plugin 2.0-beta1 and useSeparateTomcatClassloader fails with run goal
Hi Olivier,
It's actually the act of declaring a context.xml with a Loader element
that causes the application to fail. A new instance of WebAppLoader is
created, overriding the one carefully created by the plugin, without the
benefit of a properly configured class path. I've included a small patch
below which demonstrates my intent.
I'd added
classLoaderClassorg.springframework.instrument.classloading.tomcat.Tomcat
InstrumentableClassLoader/classLoaderClass to the plugin configuration,
which was then picked up correctly and used by the WebAppLoader.
Thanks,
Leigh
Index:
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/r
un/AbstractRunMojo.java
===
---
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/r
un/AbstractRunMojo.java (revision 1)
+++
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/r
un/AbstractRunMojo.java (revision )
@@ -363,6 +357,15 @@
*/
private ClassRealm tomcatRealm;
+/**
+ * Class loader class to set.
+ *
+ * @parameter
+ */
+protected String classLoaderClass;
+
//
--
// Mojo Implementation
//
--
@@ -460,14 +462,19 @@
{
context.setParentClassLoader( getTomcatClassLoader() );
}
+final WebappLoader loader = createWebappLoader();
-context.setLoader( createWebappLoader() );
+context.setLoader( loader );
File contextFile = getContextFile();
if ( contextFile != null )
{
context.setConfigFile( getContextFile().toURI().toURL() );
}
+if (classLoaderClass != null) {
+loader.setLoaderClass(classLoaderClass);
+}
+
return context;
}
On 12/04/2012 13:14, Olivier Lamy ol...@apache.org wrote:
The plugin has an option to setup context.xml to use see [1].
You can try to write an other context.xml only for using with the plugin ?
--
Olivier
[1]
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/ru
n-mojo.html#contextFile
2012/4/12 Leigh Anderson leigh.ander...@betfair.com:
Hi Olivier,
That's solved the problem, thanks. Unfortunately, declaring a custom
class
loader in a context.xml causes Tomcat to use that one, instead of the
one
set up with the correct class path by the plugin. I'll keep looking to
see
if I can find a way around this.
Thanks for your prompt help with this.
Leigh
On 12/04/2012 11:35, Olivier Lamy ol...@apache.org wrote:
Hello,
Apologize for delay.
That should be fixed now (I have deployed 2.0-SNAPSHOT).
If you could try with your use case.
Thanks,
2012/4/8 Olivier Lamy ol...@apache.org:
Hello Leigh,
Thanks for creating issue.
Until now I tried to reproduce the issue but I failed.
I wonder if you could attach a build log using -e mvn flag.
2012/4/5 Leigh Anderson leigh.ander...@betfair.com:
Hi Olivier,
I'm not able to run this with tomcat6 as it's a Servlet 3.0 project.
I'll
get the issue created -- should have some time next week to put
together a
sample project.
Thanks,
Leigh
On 04/04/2012 11:36, Olivier Lamy ol...@apache.org wrote:
Hello,
Looks to be an issue (does that work with tomcat6:run ?)
Could you create an issue here:
https://issues.apache.org/jira/browse/MTOMCAT (if possible with a
small sample project to reproduce).
Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
2012/4/3 Leigh Anderson leigh.ander...@betfair.com:
Hi All,
I'm trying to start a web application with 'mvn tomcat7:run'. It
seems
that with the configuration below it fails with the following
error:
[INFO]
--
--
[ERROR] Failed to execute goal
org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run
(default-cli)
on project mantis-test-web-app: No such archiver: 'jar'. - [Help
1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run
Maven
with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full
debug
logging.
I have also tried
* 'mvn tomcat:run-war', which seems to get past this point,
but
then the
application will not start because the 'additionalClasspathDir'
property
is not supported by the 'run-war' goal.
* removing 'useSeparateTomcatClassLoader' which then doesn't
load the
Spring instrumenting class loader required to use AspectJ LTW,
specified
in
context.xml. I have confirmed that I get the same 'no such
archiver'
error
if I remove the
context.xml, so I don't believe this to be the cause.
Is there something I've missed in the configuration?
Cheers,
Leigh
plugin
Re: Tomcat7-maven-plugin 2.0-beta1 and useSeparateTomcatClassloader fails with run goal
Hi,
2012/4/13 Leigh Anderson leigh.ander...@betfair.com:
Hi Olivier,
It's actually the act of declaring a context.xml with a Loader element
that causes the application to fail. A new instance of WebAppLoader is
created, overriding the one carefully created by the plugin, without the
benefit of a properly configured class path. I've included a small patch
below which demonstrates my intent.
Oh sure good catch.
I'd added
classLoaderClassorg.springframework.instrument.classloading.tomcat.Tomcat
InstrumentableClassLoader/classLoaderClass to the plugin configuration,
which was then picked up correctly and used by the WebAppLoader.
Could you attach the patch to an issue ?
Thanks,
Leigh
Index:
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/r
un/AbstractRunMojo.java
===
---
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/r
un/AbstractRunMojo.java (revision 1)
+++
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/r
un/AbstractRunMojo.java (revision )
@@ -363,6 +357,15 @@
*/
private ClassRealm tomcatRealm;
+ /**
+ * Class loader class to set.
+ *
+ * @parameter
+ */
+ protected String classLoaderClass;
+
//
--
// Mojo Implementation
//
--
@@ -460,14 +462,19 @@
{
context.setParentClassLoader( getTomcatClassLoader() );
}
+ final WebappLoader loader = createWebappLoader();
- context.setLoader( createWebappLoader() );
+ context.setLoader( loader );
File contextFile = getContextFile();
if ( contextFile != null )
{
context.setConfigFile( getContextFile().toURI().toURL() );
}
+ if (classLoaderClass != null) {
+ loader.setLoaderClass(classLoaderClass);
+ }
+
return context;
}
On 12/04/2012 13:14, Olivier Lamy ol...@apache.org wrote:
The plugin has an option to setup context.xml to use see [1].
You can try to write an other context.xml only for using with the plugin ?
--
Olivier
[1]
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/ru
n-mojo.html#contextFile
2012/4/12 Leigh Anderson leigh.ander...@betfair.com:
Hi Olivier,
That's solved the problem, thanks. Unfortunately, declaring a custom
class
loader in a context.xml causes Tomcat to use that one, instead of the
one
set up with the correct class path by the plugin. I'll keep looking to
see
if I can find a way around this.
Thanks for your prompt help with this.
Leigh
On 12/04/2012 11:35, Olivier Lamy ol...@apache.org wrote:
Hello,
Apologize for delay.
That should be fixed now (I have deployed 2.0-SNAPSHOT).
If you could try with your use case.
Thanks,
2012/4/8 Olivier Lamy ol...@apache.org:
Hello Leigh,
Thanks for creating issue.
Until now I tried to reproduce the issue but I failed.
I wonder if you could attach a build log using -e mvn flag.
2012/4/5 Leigh Anderson leigh.ander...@betfair.com:
Hi Olivier,
I'm not able to run this with tomcat6 as it's a Servlet 3.0 project.
I'll
get the issue created -- should have some time next week to put
together a
sample project.
Thanks,
Leigh
On 04/04/2012 11:36, Olivier Lamy ol...@apache.org wrote:
Hello,
Looks to be an issue (does that work with tomcat6:run ?)
Could you create an issue here:
https://issues.apache.org/jira/browse/MTOMCAT (if possible with a
small sample project to reproduce).
Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
2012/4/3 Leigh Anderson leigh.ander...@betfair.com:
Hi All,
I'm trying to start a web application with 'mvn tomcat7:run'. It
seems
that with the configuration below it fails with the following
error:
[INFO]
--
--
[ERROR] Failed to execute goal
org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run
(default-cli)
on project mantis-test-web-app: No such archiver: 'jar'. - [Help
1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run
Maven
with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full
debug
logging.
I have also tried
* 'mvn tomcat:run-war', which seems to get past this point,
but
then the
application will not start because the 'additionalClasspathDir'
property
is not supported by the 'run-war' goal.
* removing 'useSeparateTomcatClassLoader' which then doesn't
load the
Spring instrumenting class loader required to use AspectJ LTW,
specified
in
context.xml. I have confirmed that I get the same 'no such
archiver'
error
if I remove the
context.xml, so I don't believe
Re: Tomcat7-maven-plugin 2.0-beta1 and useSeparateTomcatClassloader fails with run goal
I'd added
classLoaderClassorg.springframework.instrument.classloading.tomcat.Tomc
at
InstrumentableClassLoader/classLoaderClass to the plugin
configuration,
which was then picked up correctly and used by the WebAppLoader.
Could you attach the patch to an issue ?
MTOMCAT-140 created.
Thanks,
Leigh
Index:
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7
/r
un/AbstractRunMojo.java
===
---
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7
/r
un/AbstractRunMojo.java (revision 1)
+++
tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7
/r
un/AbstractRunMojo.java (revision )
@@ -363,6 +357,15 @@
*/
private ClassRealm tomcatRealm;
+/**
+ * Class loader class to set.
+ *
+ * @parameter
+ */
+protected String classLoaderClass;
+
//
--
// Mojo Implementation
//
--
@@ -460,14 +462,19 @@
{
context.setParentClassLoader( getTomcatClassLoader() );
}
+final WebappLoader loader = createWebappLoader();
-context.setLoader( createWebappLoader() );
+context.setLoader( loader );
File contextFile = getContextFile();
if ( contextFile != null )
{
context.setConfigFile( getContextFile().toURI().toURL() );
}
+if (classLoaderClass != null) {
+loader.setLoaderClass(classLoaderClass);
+}
+
return context;
}
On 12/04/2012 13:14, Olivier Lamy ol...@apache.org wrote:
The plugin has an option to setup context.xml to use see [1].
You can try to write an other context.xml only for using with the
plugin ?
--
Olivier
[1]
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/
ru
n-mojo.html#contextFile
2012/4/12 Leigh Anderson leigh.ander...@betfair.com:
Hi Olivier,
That's solved the problem, thanks. Unfortunately, declaring a custom
class
loader in a context.xml causes Tomcat to use that one, instead of the
one
set up with the correct class path by the plugin. I'll keep looking to
see
if I can find a way around this.
Thanks for your prompt help with this.
Leigh
On 12/04/2012 11:35, Olivier Lamy ol...@apache.org wrote:
Hello,
Apologize for delay.
That should be fixed now (I have deployed 2.0-SNAPSHOT).
If you could try with your use case.
Thanks,
2012/4/8 Olivier Lamy ol...@apache.org:
Hello Leigh,
Thanks for creating issue.
Until now I tried to reproduce the issue but I failed.
I wonder if you could attach a build log using -e mvn flag.
2012/4/5 Leigh Anderson leigh.ander...@betfair.com:
Hi Olivier,
I'm not able to run this with tomcat6 as it's a Servlet 3.0
project.
I'll
get the issue created -- should have some time next week to put
together a
sample project.
Thanks,
Leigh
On 04/04/2012 11:36, Olivier Lamy ol...@apache.org wrote:
Hello,
Looks to be an issue (does that work with tomcat6:run ?)
Could you create an issue here:
https://issues.apache.org/jira/browse/MTOMCAT (if possible with a
small sample project to reproduce).
Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
2012/4/3 Leigh Anderson leigh.ander...@betfair.com:
Hi All,
I'm trying to start a web application with 'mvn tomcat7:run'. It
seems
that with the configuration below it fails with the following
error:
[INFO]
--
--
--
--
[ERROR] Failed to execute goal
org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run
(default-cli)
on project mantis-test-web-app: No such archiver: 'jar'. - [Help
1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run
Maven
with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full
debug
logging.
I have also tried
* 'mvn tomcat:run-war', which seems to get past this
point,
but
then the
application will not start because the 'additionalClasspathDir'
property
is not supported by the 'run-war' goal.
* removing 'useSeparateTomcatClassLoader' which then
doesn't
load the
Spring instrumenting class loader required to use AspectJ LTW,
specified
in
context.xml. I have confirmed that I get the same 'no such
archiver'
error
if I remove the
context.xml, so I don't believe this to be the cause.
Is there something I've missed in the configuration?
Cheers,
Leigh
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version2.0-beta-1/version
configuration
systemProperties
log4j.defaultInitOverridetrue
Re: Tomcat7-maven-plugin 2.0-beta1 and useSeparateTomcatClassloader fails with run goal
Hello,
Apologize for delay.
That should be fixed now (I have deployed 2.0-SNAPSHOT).
If you could try with your use case.
Thanks,
2012/4/8 Olivier Lamy ol...@apache.org:
Hello Leigh,
Thanks for creating issue.
Until now I tried to reproduce the issue but I failed.
I wonder if you could attach a build log using -e mvn flag.
2012/4/5 Leigh Anderson leigh.ander...@betfair.com:
Hi Olivier,
I'm not able to run this with tomcat6 as it's a Servlet 3.0 project. I'll
get the issue created -- should have some time next week to put together a
sample project.
Thanks,
Leigh
On 04/04/2012 11:36, Olivier Lamy ol...@apache.org wrote:
Hello,
Looks to be an issue (does that work with tomcat6:run ?)
Could you create an issue here:
https://issues.apache.org/jira/browse/MTOMCAT (if possible with a
small sample project to reproduce).
Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
2012/4/3 Leigh Anderson leigh.ander...@betfair.com:
Hi All,
I'm trying to start a web application with 'mvn tomcat7:run'. It seems
that with the configuration below it fails with the following error:
[INFO]
[ERROR] Failed to execute goal
org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run
(default-cli)
on project mantis-test-web-app: No such archiver: 'jar'. - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven
with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug
logging.
I have also tried
* 'mvn tomcat:run-war', which seems to get past this point, but
then the
application will not start because the 'additionalClasspathDir' property
is not supported by the 'run-war' goal.
* removing 'useSeparateTomcatClassLoader' which then doesn't
load the
Spring instrumenting class loader required to use AspectJ LTW, specified
in
context.xml. I have confirmed that I get the same 'no such archiver'
error
if I remove the
context.xml, so I don't believe this to be the cause.
Is there something I've missed in the configuration?
Cheers,
Leigh
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version2.0-beta-1/version
configuration
systemProperties
log4j.defaultInitOverridetrue/log4j.defaultInitOverride
HOSTNAMElocalhost/HOSTNAME
port.http9090/port.http
port.https8443/port.https
/systemProperties
port9090/port
httpsPort8443/httpsPort
path//path
useTestClasspathfalse/useTestClasspath
additionalClasspathDirs
additionalClasspathDir${project.basedir}/config/additionalClasspathDir
/additionalClasspathDirs
useSeparateTomcatClassLoadertrue/useSeparateTomcatClassLoader
/configuration
dependencies
dependency
groupIdorg.springframework/groupId
artifactIdspring-instrument-tomcat/artifactId
version${spring.version}/version
/dependency
/dependencies
/plugin
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy |
Re: Tomcat7-maven-plugin 2.0-beta1 and useSeparateTomcatClassloader fails with run goal
Hi Olivier,
That's solved the problem, thanks. Unfortunately, declaring a custom class
loader in a context.xml causes Tomcat to use that one, instead of the one
set up with the correct class path by the plugin. I'll keep looking to see
if I can find a way around this.
Thanks for your prompt help with this.
Leigh
On 12/04/2012 11:35, Olivier Lamy ol...@apache.org wrote:
Hello,
Apologize for delay.
That should be fixed now (I have deployed 2.0-SNAPSHOT).
If you could try with your use case.
Thanks,
2012/4/8 Olivier Lamy ol...@apache.org:
Hello Leigh,
Thanks for creating issue.
Until now I tried to reproduce the issue but I failed.
I wonder if you could attach a build log using -e mvn flag.
2012/4/5 Leigh Anderson leigh.ander...@betfair.com:
Hi Olivier,
I'm not able to run this with tomcat6 as it's a Servlet 3.0 project.
I'll
get the issue created -- should have some time next week to put
together a
sample project.
Thanks,
Leigh
On 04/04/2012 11:36, Olivier Lamy ol...@apache.org wrote:
Hello,
Looks to be an issue (does that work with tomcat6:run ?)
Could you create an issue here:
https://issues.apache.org/jira/browse/MTOMCAT (if possible with a
small sample project to reproduce).
Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
2012/4/3 Leigh Anderson leigh.ander...@betfair.com:
Hi All,
I'm trying to start a web application with 'mvn tomcat7:run'. It
seems
that with the configuration below it fails with the following error:
[INFO]
--
--
[ERROR] Failed to execute goal
org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run
(default-cli)
on project mantis-test-web-app: No such archiver: 'jar'. - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run
Maven
with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug
logging.
I have also tried
* 'mvn tomcat:run-war', which seems to get past this point,
but
then the
application will not start because the 'additionalClasspathDir'
property
is not supported by the 'run-war' goal.
* removing 'useSeparateTomcatClassLoader' which then doesn't
load the
Spring instrumenting class loader required to use AspectJ LTW,
specified
in
context.xml. I have confirmed that I get the same 'no such archiver'
error
if I remove the
context.xml, so I don't believe this to be the cause.
Is there something I've missed in the configuration?
Cheers,
Leigh
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version2.0-beta-1/version
configuration
systemProperties
log4j.defaultInitOverridetrue/log4j.defaultInitOverride
HOSTNAMElocalhost/HOSTNAME
port.http9090/port.http
port.https8443/port.https
/systemProperties
port9090/port
httpsPort8443/httpsPort
path//path
useTestClasspathfalse/useTestClasspath
additionalClasspathDirs
additionalClasspathDir${project.basedir}/config/additionalClasspath
Dir
/additionalClasspathDirs
useSeparateTomcatClassLoadertrue/useSeparateTomcatClassLoader
/configuration
dependencies
dependency
groupIdorg.springframework/groupId
artifactIdspring-instrument-tomcat/artifactId
version${spring.version}/version
/dependency
/dependencies
/plugin
__
__
In order to protect our email recipients, Betfair Group use SkyScan
from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
__
__
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
In order to protect our email recipients, Betfair Group use SkyScan
from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
Re: Tomcat7-maven-plugin 2.0-beta1 and useSeparateTomcatClassloader fails with run goal
The plugin has an option to setup context.xml to use see [1].
You can try to write an other context.xml only for using with the plugin ?
--
Olivier
[1]
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/run-mojo.html#contextFile
2012/4/12 Leigh Anderson leigh.ander...@betfair.com:
Hi Olivier,
That's solved the problem, thanks. Unfortunately, declaring a custom class
loader in a context.xml causes Tomcat to use that one, instead of the one
set up with the correct class path by the plugin. I'll keep looking to see
if I can find a way around this.
Thanks for your prompt help with this.
Leigh
On 12/04/2012 11:35, Olivier Lamy ol...@apache.org wrote:
Hello,
Apologize for delay.
That should be fixed now (I have deployed 2.0-SNAPSHOT).
If you could try with your use case.
Thanks,
2012/4/8 Olivier Lamy ol...@apache.org:
Hello Leigh,
Thanks for creating issue.
Until now I tried to reproduce the issue but I failed.
I wonder if you could attach a build log using -e mvn flag.
2012/4/5 Leigh Anderson leigh.ander...@betfair.com:
Hi Olivier,
I'm not able to run this with tomcat6 as it's a Servlet 3.0 project.
I'll
get the issue created -- should have some time next week to put
together a
sample project.
Thanks,
Leigh
On 04/04/2012 11:36, Olivier Lamy ol...@apache.org wrote:
Hello,
Looks to be an issue (does that work with tomcat6:run ?)
Could you create an issue here:
https://issues.apache.org/jira/browse/MTOMCAT (if possible with a
small sample project to reproduce).
Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
2012/4/3 Leigh Anderson leigh.ander...@betfair.com:
Hi All,
I'm trying to start a web application with 'mvn tomcat7:run'. It
seems
that with the configuration below it fails with the following error:
[INFO]
--
--
[ERROR] Failed to execute goal
org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run
(default-cli)
on project mantis-test-web-app: No such archiver: 'jar'. - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run
Maven
with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug
logging.
I have also tried
* 'mvn tomcat:run-war', which seems to get past this point,
but
then the
application will not start because the 'additionalClasspathDir'
property
is not supported by the 'run-war' goal.
* removing 'useSeparateTomcatClassLoader' which then doesn't
load the
Spring instrumenting class loader required to use AspectJ LTW,
specified
in
context.xml. I have confirmed that I get the same 'no such archiver'
error
if I remove the
context.xml, so I don't believe this to be the cause.
Is there something I've missed in the configuration?
Cheers,
Leigh
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version2.0-beta-1/version
configuration
systemProperties
log4j.defaultInitOverridetrue/log4j.defaultInitOverride
HOSTNAMElocalhost/HOSTNAME
port.http9090/port.http
port.https8443/port.https
/systemProperties
port9090/port
httpsPort8443/httpsPort
path//path
useTestClasspathfalse/useTestClasspath
additionalClasspathDirs
additionalClasspathDir${project.basedir}/config/additionalClasspath
Dir
/additionalClasspathDirs
useSeparateTomcatClassLoadertrue/useSeparateTomcatClassLoader
/configuration
dependencies
dependency
groupIdorg.springframework/groupId
artifactIdspring-instrument-tomcat/artifactId
version${spring.version}/version
/dependency
/dependencies
/plugin
__
__
In order to protect our email recipients, Betfair Group use SkyScan
from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
__
__
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h
Re: Tomcat7-maven-plugin 2.0-beta1 and useSeparateTomcatClassloader fails with run goal
Hello Leigh,
Thanks for creating issue.
Until now I tried to reproduce the issue but I failed.
I wonder if you could attach a build log using -e mvn flag.
2012/4/5 Leigh Anderson leigh.ander...@betfair.com:
Hi Olivier,
I'm not able to run this with tomcat6 as it's a Servlet 3.0 project. I'll
get the issue created -- should have some time next week to put together a
sample project.
Thanks,
Leigh
On 04/04/2012 11:36, Olivier Lamy ol...@apache.org wrote:
Hello,
Looks to be an issue (does that work with tomcat6:run ?)
Could you create an issue here:
https://issues.apache.org/jira/browse/MTOMCAT (if possible with a
small sample project to reproduce).
Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
2012/4/3 Leigh Anderson leigh.ander...@betfair.com:
Hi All,
I'm trying to start a web application with 'mvn tomcat7:run'. It seems
that with the configuration below it fails with the following error:
[INFO]
[ERROR] Failed to execute goal
org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run
(default-cli)
on project mantis-test-web-app: No such archiver: 'jar'. - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven
with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug
logging.
I have also tried
* 'mvn tomcat:run-war', which seems to get past this point, but
then the
application will not start because the 'additionalClasspathDir' property
is not supported by the 'run-war' goal.
* removing 'useSeparateTomcatClassLoader' which then doesn't
load the
Spring instrumenting class loader required to use AspectJ LTW, specified
in
context.xml. I have confirmed that I get the same 'no such archiver'
error
if I remove the
context.xml, so I don't believe this to be the cause.
Is there something I've missed in the configuration?
Cheers,
Leigh
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version2.0-beta-1/version
configuration
systemProperties
log4j.defaultInitOverridetrue/log4j.defaultInitOverride
HOSTNAMElocalhost/HOSTNAME
port.http9090/port.http
port.https8443/port.https
/systemProperties
port9090/port
httpsPort8443/httpsPort
path//path
useTestClasspathfalse/useTestClasspath
additionalClasspathDirs
additionalClasspathDir${project.basedir}/config/additionalClasspathDir
/additionalClasspathDirs
useSeparateTomcatClassLoadertrue/useSeparateTomcatClassLoader
/configuration
dependencies
dependency
groupIdorg.springframework/groupId
artifactIdspring-instrument-tomcat/artifactId
version${spring.version}/version
/dependency
/dependencies
/plugin
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat7-maven-plugin 2.0-beta1 and useSeparateTomcatClassloader fails with run goal
Hi Olivier,
I'm not able to run this with tomcat6 as it's a Servlet 3.0 project. I'll
get the issue created -- should have some time next week to put together a
sample project.
Thanks,
Leigh
On 04/04/2012 11:36, Olivier Lamy ol...@apache.org wrote:
Hello,
Looks to be an issue (does that work with tomcat6:run ?)
Could you create an issue here:
https://issues.apache.org/jira/browse/MTOMCAT (if possible with a
small sample project to reproduce).
Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
2012/4/3 Leigh Anderson leigh.ander...@betfair.com:
Hi All,
I'm trying to start a web application with 'mvn tomcat7:run'. It seems
that with the configuration below it fails with the following error:
[INFO]
[ERROR] Failed to execute goal
org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run
(default-cli)
on project mantis-test-web-app: No such archiver: 'jar'. - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven
with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug
logging.
I have also tried
* 'mvn tomcat:run-war', which seems to get past this point, but
then the
application will not start because the 'additionalClasspathDir' property
is not supported by the 'run-war' goal.
* removing 'useSeparateTomcatClassLoader' which then doesn't
load the
Spring instrumenting class loader required to use AspectJ LTW, specified
in
context.xml. I have confirmed that I get the same 'no such archiver'
error
if I remove the
context.xml, so I don't believe this to be the cause.
Is there something I've missed in the configuration?
Cheers,
Leigh
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version2.0-beta-1/version
configuration
systemProperties
log4j.defaultInitOverridetrue/log4j.defaultInitOverride
HOSTNAMElocalhost/HOSTNAME
port.http9090/port.http
port.https8443/port.https
/systemProperties
port9090/port
httpsPort8443/httpsPort
path//path
useTestClasspathfalse/useTestClasspath
additionalClasspathDirs
additionalClasspathDir${project.basedir}/config/additionalClasspathDir
/additionalClasspathDirs
useSeparateTomcatClassLoadertrue/useSeparateTomcatClassLoader
/configuration
dependencies
dependency
groupIdorg.springframework/groupId
artifactIdspring-instrument-tomcat/artifactId
version${spring.version}/version
/dependency
/dependencies
/plugin
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat7-maven-plugin 2.0-beta1 and useSeparateTomcatClassloader fails with run goal
Hello,
Looks to be an issue (does that work with tomcat6:run ?)
Could you create an issue here:
https://issues.apache.org/jira/browse/MTOMCAT (if possible with a
small sample project to reproduce).
Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
2012/4/3 Leigh Anderson leigh.ander...@betfair.com:
Hi All,
I'm trying to start a web application with 'mvn tomcat7:run'. It seems
that with the configuration below it fails with the following error:
[INFO]
[ERROR] Failed to execute goal
org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run (default-cli)
on project mantis-test-web-app: No such archiver: 'jar'. - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
I have also tried
* 'mvn tomcat:run-war', which seems to get past this point, but then
the
application will not start because the 'additionalClasspathDir' property
is not supported by the 'run-war' goal.
* removing 'useSeparateTomcatClassLoader' which then doesn't load the
Spring instrumenting class loader required to use AspectJ LTW, specified
in
context.xml. I have confirmed that I get the same 'no such archiver' error
if I remove the
context.xml, so I don't believe this to be the cause.
Is there something I've missed in the configuration?
Cheers,
Leigh
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version2.0-beta-1/version
configuration
systemProperties
log4j.defaultInitOverridetrue/log4j.defaultInitOverride
HOSTNAMElocalhost/HOSTNAME
port.http9090/port.http
port.https8443/port.https
/systemProperties
port9090/port
httpsPort8443/httpsPort
path//path
useTestClasspathfalse/useTestClasspath
additionalClasspathDirs
additionalClasspathDir${project.basedir}/config/additionalClasspathDir
/additionalClasspathDirs
useSeparateTomcatClassLoadertrue/useSeparateTomcatClassLoader
/configuration
dependencies
dependency
groupIdorg.springframework/groupId
artifactIdspring-instrument-tomcat/artifactId
version${spring.version}/version
/dependency
/dependencies
/plugin
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat7-maven-plugin 2.0-beta1 and useSeparateTomcatClassloader fails with run goal
Hi All,
I'm trying to start a web application with 'mvn tomcat7:run'. It seems
that with the configuration below it fails with the following error:
[INFO]
[ERROR] Failed to execute goal
org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-beta-1:run (default-cli)
on project mantis-test-web-app: No such archiver: 'jar'. - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
I have also tried
* 'mvn tomcat:run-war', which seems to get past this point, but then the
application will not start because the 'additionalClasspathDir' property
is not supported by the 'run-war' goal.
* removing 'useSeparateTomcatClassLoader' which then doesn't load the
Spring instrumenting class loader required to use AspectJ LTW, specified
in
context.xml. I have confirmed that I get the same 'no such archiver' error
if I remove the
context.xml, so I don't believe this to be the cause.
Is there something I've missed in the configuration?
Cheers,
Leigh
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version2.0-beta-1/version
configuration
systemProperties
log4j.defaultInitOverridetrue/log4j.defaultInitOverride
HOSTNAMElocalhost/HOSTNAME
port.http9090/port.http
port.https8443/port.https
/systemProperties
port9090/port
httpsPort8443/httpsPort
path//path
useTestClasspathfalse/useTestClasspath
additionalClasspathDirs
additionalClasspathDir${project.basedir}/config/additionalClasspathDir
/additionalClasspathDirs
useSeparateTomcatClassLoadertrue/useSeparateTomcatClassLoader
/configuration
dependencies
dependency
groupIdorg.springframework/groupId
artifactIdspring-instrument-tomcat/artifactId
version${spring.version}/version
/dependency
/dependencies
/plugin
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Using tomcat7-maven-plugin- 2.0-beta-1: java.lang.RuntimeException: Name jdbc is not bound in this Context
I create a simple project using commons-dbcp and without using any query for test, the issue still occurred. I reported a bug. Thanks! -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, March 07, 2012 11:53 PM To: Tomcat Users List Subject: Re: [OT] Using tomcat7-maven-plugin- 2.0-beta-1: java.lang.RuntimeException: Name jdbc is not bound in this Context -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guofeng, On 3/7/12 5:32 AM, Guofeng Zhang wrote: Resource auth=Container maxPoolSize=100 minPoolSize=10 name=jdbc/iviewDS testQuery=select count(*) from T_ROLE You might want to use a simper testQuery (like SELECT 1 FROM DUAL, for instance). Some RDBMS engines don't have great performance with SELECT COUNT(*) (for instance, MySQL using the InnoDB engine). Also, does your factory generate a DataSource for which testQuery is a valid property? If you are using Tomcat's standard connection poll (DBCP's BasicDataSource) or Tomcat's other pool (jdbc-pool), then the proper configuration attribute is validationQuery. See http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html#JDBC_Data_Sources Specifically, step #4 under that heading. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9XhGoACgkQ9CaO5/Lv0PB7yACguvu8xlUz6Yf+MJKMqv5NH0V9 Lv0AnA+8Qyo5NUClxyAJHsfMIaaBbXXk =K1IB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Using tomcat7-maven-plugin- 2.0-beta-1: java.lang.RuntimeException: Name jdbc is not bound in this Context
Hi, I try tomcat7-maven-plugin/2.0-beta-1. When I use mvn tomcat7:run to launch my app, I got: javax.naming.NameNotFoundException: Name jdbc is not bound in this Context I configured the datatsource as global naming datasource in server.xml, GlobalNamingResources Resource auth=Container maxPoolSize=100 minPoolSize=10 name=jdbc/iviewDS testQuery=select count(*) from T_ROLE factory=.. type=javax.sql.DataSource uniqueResourceName=jdbc/iviewDS/ The server.xml is copied to src\main\tomcatconf, (this also copyied by the plugin to target\tomcat\conf, so it is used). then in webapp/META-INF/context.xml, I have: ResourceLink name=jdbc/iviewDS global=jdbc/iviewDS type=javax.sql.DataSource / And in web.xml: resource-ref descriptiondatasoruce/description res-ref-namejdbc/iviewDS/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref In my code, I lookup the datasource using 'java:/comp/env/jdbc/iviewDS'. This works well when I deploy the app into tomcat/app directory. How to solve the issue when use the plugin? Thanks Guofeng
Re: Using tomcat7-maven-plugin- 2.0-beta-1: java.lang.RuntimeException: Name jdbc is not bound in this Context
Hello
Sounds like an issue.
It will be really lovely if you could create a sample project to
reproduce that and attach it to a new issue here:
https://issues.apache.org/jira/browse/MTOMCAT
BTW does that work using a context file tru the configuration
contextFile${tomcatContextXml}/contextFile (and not with a
server.xml file I mean nothing in src\main\tomcatconf ) ?
Thanks,
2012/3/7 Guofeng Zhang guof...@radvision.com:
Hi,
I try tomcat7-maven-plugin/2.0-beta-1. When I use mvn tomcat7:run to launch
my app, I got:
javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
I configured the datatsource as global naming datasource in server.xml,
GlobalNamingResources
Resource
auth=Container
maxPoolSize=100 minPoolSize=10
name=jdbc/iviewDS
testQuery=select count(*) from T_ROLE
factory=..
type=javax.sql.DataSource
uniqueResourceName=jdbc/iviewDS/
The server.xml is copied to src\main\tomcatconf, (this also copyied by the
plugin to target\tomcat\conf, so it is used).
then in webapp/META-INF/context.xml, I have:
ResourceLink
name=jdbc/iviewDS
global=jdbc/iviewDS
type=javax.sql.DataSource
/
And in web.xml:
resource-ref
descriptiondatasoruce/description
res-ref-namejdbc/iviewDS/res-ref-name
res-typejavax.sql.DataSource/res-type
res-authContainer/res-auth
/resource-ref
In my code, I lookup the datasource using 'java:/comp/env/jdbc/iviewDS'.
This works well when I deploy the app into tomcat/app directory.
How to solve the issue when use the plugin?
Thanks
Guofeng
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Using tomcat7-maven-plugin- 2.0-beta-1: java.lang.RuntimeException: Name jdbc is not bound in this Context
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guofeng, On 3/7/12 5:32 AM, Guofeng Zhang wrote: Resource auth=Container maxPoolSize=100 minPoolSize=10 name=jdbc/iviewDS testQuery=select count(*) from T_ROLE You might want to use a simper testQuery (like SELECT 1 FROM DUAL, for instance). Some RDBMS engines don't have great performance with SELECT COUNT(*) (for instance, MySQL using the InnoDB engine). Also, does your factory generate a DataSource for which testQuery is a valid property? If you are using Tomcat's standard connection poll (DBCP's BasicDataSource) or Tomcat's other pool (jdbc-pool), then the proper configuration attribute is validationQuery. See http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html#JDBC_Data_Sources Specifically, step #4 under that heading. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9XhGoACgkQ9CaO5/Lv0PB7yACguvu8xlUz6Yf+MJKMqv5NH0V9 Lv0AnA+8Qyo5NUClxyAJHsfMIaaBbXXk =K1IB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7 maven plugin (frustration) - probably a simple question
Hello,
Does your current project have war packaging ? If yes, I think there
are some issues with that and btw use exec-war-only goal to prevent to
run an other full lifecycle in your war project.
What I recommend is to have an other project with packaging pom and
construct the exec war.
I have pushed samples here: https://github.com/olamy/translate-puzzle .
2011/12/27 PS M. transparentpolit...@gmail.com:
Hi there --
I am frustrated with the tomcat7 maven plugin. I am trying to create an
executable jar from my war project. The problem is that none of the war's
dependencies are included in the executable jar even though the
corresponding war created at the same time is complete.
In the pom.xml file:
project
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
executions
execution
idtomcat-run/id
goals
goalexec-war/goal
/goals
phasepackage/phase
configuration
path//path
attachArtifactClassifier
exec-war!-- default --
/attachArtifactClassifier
attachArtifactClassifierType
jar!-- default value is jar --
/attachArtifactClassifierType
warRunDependencies
warRunDependency
dependency
groupIdcom.my-company/groupId
artifactIdwireservice/artifactId
version${project.version}/version
typewar/type
/dependency
contextPath//contextPath
/warRunDependency
/warRunDependencies
!-- naming is disable by default so use true
to enable it --
enableNamingtrue/enableNaming
/configuration
/execution
/executions
/plugin
The generated executable has a this structure:
820944 Mon Dec 26 18:28:42 PST 2011 .war
183 Mon Dec 26 18:28:42 PST 2011 tomcat.standalone.properties
0 Mon Dec 26 18:28:44 PST 2011 META-INF/
394 Mon Dec 26 18:28:44 PST 2011 META-INF/MANIFEST.MF
0 Mon Dec 26 18:28:44 PST 2011 javax/
0 Mon Dec 26 18:28:44 PST 2011 javax/annotation/
0 Mon Dec 26 18:28:44 PST 2011 javax/annotation/security/
0 Mon Dec 26 18:28:44 PST 2011 javax/servlet/
0 Mon Dec 26 18:28:44 PST 2011 javax/servlet/annotation/
0 Mon Dec 26 18:28:44 PST 2011 javax/servlet/descriptor/
0 Mon Dec 26 18:28:44 PST 2011 javax/servlet/http/
0 Mon Dec 26 18:28:44 PST 2011 javax/servlet/jsp/
0 Mon Dec 26 18:28:44 PST 2011 javax/servlet/resources/
0 Mon Dec 26 18:28:44 PST 2011 org/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/authenticator/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/comet/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/connector/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/core/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/deploy/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/filters/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/loader/
( tomcat 7 exploded into classes )
The .war file has just the the classes in the current project included.
No dependencies are included as jars or exploded in any other form.
java -jar .jar starts tomcat but the war servlet is does not respond on
http://localhost:8080/ and in any event it would not be able to run because
of the missing dependencies.
So 2 questions:
1. How to get the tomcat7-maven-plugin to include the war's
dependencies. ( fyi the dependencies in question have the default scope )
2. How to get the path correctly so that http://localhost:8080/ is
responded to?
Thanks!
Pat
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7 maven plugin (frustration) - probably a simple question
O.k. I will try today
tomcat7 maven plugin (frustration) - probably a simple question
Hi there --
I am frustrated with the tomcat7 maven plugin. I am trying to create an
executable jar from my war project. The problem is that none of the war's
dependencies are included in the executable jar even though the
corresponding war created at the same time is complete.
In the pom.xml file:
project
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
executions
execution
idtomcat-run/id
goals
goalexec-war/goal
/goals
phasepackage/phase
configuration
path//path
attachArtifactClassifier
exec-war!-- default --
/attachArtifactClassifier
attachArtifactClassifierType
jar!-- default value is jar --
/attachArtifactClassifierType
warRunDependencies
warRunDependency
dependency
groupIdcom.my-company/groupId
artifactIdwireservice/artifactId
version${project.version}/version
typewar/type
/dependency
contextPath//contextPath
/warRunDependency
/warRunDependencies
!-- naming is disable by default so use true
to enable it --
enableNamingtrue/enableNaming
/configuration
/execution
/executions
/plugin
The generated executable has a this structure:
820944 Mon Dec 26 18:28:42 PST 2011 .war
183 Mon Dec 26 18:28:42 PST 2011 tomcat.standalone.properties
0 Mon Dec 26 18:28:44 PST 2011 META-INF/
394 Mon Dec 26 18:28:44 PST 2011 META-INF/MANIFEST.MF
0 Mon Dec 26 18:28:44 PST 2011 javax/
0 Mon Dec 26 18:28:44 PST 2011 javax/annotation/
0 Mon Dec 26 18:28:44 PST 2011 javax/annotation/security/
0 Mon Dec 26 18:28:44 PST 2011 javax/servlet/
0 Mon Dec 26 18:28:44 PST 2011 javax/servlet/annotation/
0 Mon Dec 26 18:28:44 PST 2011 javax/servlet/descriptor/
0 Mon Dec 26 18:28:44 PST 2011 javax/servlet/http/
0 Mon Dec 26 18:28:44 PST 2011 javax/servlet/jsp/
0 Mon Dec 26 18:28:44 PST 2011 javax/servlet/resources/
0 Mon Dec 26 18:28:44 PST 2011 org/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/authenticator/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/comet/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/connector/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/core/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/deploy/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/filters/
0 Mon Dec 26 18:28:44 PST 2011 org/apache/catalina/loader/
( tomcat 7 exploded into classes )
The .war file has just the the classes in the current project included.
No dependencies are included as jars or exploded in any other form.
java -jar .jar starts tomcat but the war servlet is does not respond on
http://localhost:8080/ and in any event it would not be able to run because
of the missing dependencies.
So 2 questions:
1. How to get the tomcat7-maven-plugin to include the war's
dependencies. ( fyi the dependencies in question have the default scope )
2. How to get the path correctly so that http://localhost:8080/ is
responded to?
Thanks!
Pat
Re: tomcat7-maven-plugin redeploy
Hello, Did you try update parameter to true [1] ? Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy [1] http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/deploy-mojo.html#update 2011/11/16 Hodchenkov, Paul paul.hodchen...@oxagile.com: Hi, It's seems that new tomcat7 plugin does not have undeploy/redeploy goals. So deployment fails with: -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Cannot invoke Tomcat manager: FAIL - Application already exists at path / Is it possible to undeploy/redeploy app using apache tomcat7 plugin? Should I revert back to codehaus plugin? -Original Message- From: Jesse Farinacci [mailto:jie...@gmail.com] Sent: Wednesday, November 16, 2011 4:21 AM To: Tomcat Users List Subject: Re: tomcat7-maven-plugin redeploy Greetings, On Tue, Nov 15, 2011 at 6:13 PM, David Yu d...@collab.net wrote: Is there a redeploy goal for the tomcat7 plugin? I'm trying to re-deploy a war file that has already been deployed and built to my remote tomcat server. Thanks. New development is at: http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/plugin-info.html Old deprecated plugin is at: http://mojo.codehaus.org/tomcat-maven-plugin/plugin-info.html http://mojo.codehaus.org/tomcat-maven-plugin/redeploy-mojo.html -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat7-maven-plugin redeploy
Thanks, it works. -Original Message- From: Olivier Lamy [mailto:ol...@apache.org] Sent: Wednesday, November 16, 2011 11:35 AM To: Tomcat Users List Subject: Re: tomcat7-maven-plugin redeploy Hello, Did you try update parameter to true [1] ? Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy [1] http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/deploy-mojo.html#update 2011/11/16 Hodchenkov, Paul paul.hodchen...@oxagile.com: Hi, It's seems that new tomcat7 plugin does not have undeploy/redeploy goals. So deployment fails with: -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Cannot invoke Tomcat manager: FAIL - Application already exists at path / Is it possible to undeploy/redeploy app using apache tomcat7 plugin? Should I revert back to codehaus plugin? -Original Message- From: Jesse Farinacci [mailto:jie...@gmail.com] Sent: Wednesday, November 16, 2011 4:21 AM To: Tomcat Users List Subject: Re: tomcat7-maven-plugin redeploy Greetings, On Tue, Nov 15, 2011 at 6:13 PM, David Yu d...@collab.net wrote: Is there a redeploy goal for the tomcat7 plugin? I'm trying to re-deploy a war file that has already been deployed and built to my remote tomcat server. Thanks. New development is at: http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/plugin-info.html Old deprecated plugin is at: http://mojo.codehaus.org/tomcat-maven-plugin/plugin-info.html http://mojo.codehaus.org/tomcat-maven-plugin/redeploy-mojo.html -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat7-maven-plugin redeploy
Is there a redeploy goal for the tomcat7 plugin? I'm trying to re-deploy a war file that has already been deployed and built to my remote tomcat server. Thanks. David Yu | Sales Engineer | CollabNet, Inc. 8000 Marina Blvd. Suite 600 | Brisbane, CA 94005 | USA Skype david.yongshin.yu | O 650.228.2613 | C 415.235.1241 | d...@collab.net mailto:d...@collab.net Agile Development in the Cloud: 7,000 Companies, 5M users, 90+ countries
Re: tomcat7-maven-plugin redeploy
Greetings, On Tue, Nov 15, 2011 at 6:13 PM, David Yu d...@collab.net wrote: Is there a redeploy goal for the tomcat7 plugin? I'm trying to re-deploy a war file that has already been deployed and built to my remote tomcat server. Thanks. New development is at: http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/plugin-info.html Old deprecated plugin is at: http://mojo.codehaus.org/tomcat-maven-plugin/plugin-info.html http://mojo.codehaus.org/tomcat-maven-plugin/redeploy-mojo.html -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat7-maven-plugin redeploy
Hi, It's seems that new tomcat7 plugin does not have undeploy/redeploy goals. So deployment fails with: -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Cannot invoke Tomcat manager: FAIL - Application already exists at path / Is it possible to undeploy/redeploy app using apache tomcat7 plugin? Should I revert back to codehaus plugin? -Original Message- From: Jesse Farinacci [mailto:jie...@gmail.com] Sent: Wednesday, November 16, 2011 4:21 AM To: Tomcat Users List Subject: Re: tomcat7-maven-plugin redeploy Greetings, On Tue, Nov 15, 2011 at 6:13 PM, David Yu d...@collab.net wrote: Is there a redeploy goal for the tomcat7 plugin? I'm trying to re-deploy a war file that has already been deployed and built to my remote tomcat server. Thanks. New development is at: http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/plugin-info.html Old deprecated plugin is at: http://mojo.codehaus.org/tomcat-maven-plugin/plugin-info.html http://mojo.codehaus.org/tomcat-maven-plugin/redeploy-mojo.html -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
