gmane.comp.java.cargo.user

CARGO 1.2.2 available!

S. Ali Tokmen — 2012-05-21T18:26:22

Dear CARGO enthusiasts

After about 7 weeks after the last release, I decided we have enough
changes and fixed bugs in order to go ahead with CARGO 1.2.2. As for
what's new, the list is this time small (12 entries):

*Improvements and new features* (5)

  *
      o Jetty containers now support datasources (CARGO-1107
        <https://jira.codehaus.org/browse/CARGO-1107>)
      o Jetty 7.x standalone local container is now the default
        container for the CARGO Maven2/Maven3 plugin (CARGO-1106
        <https://jira.codehaus.org/browse/CARGO-1106>) and downloads its
        container via the artifactInstaller
      o The usage of an external jetty-env.xml file has finally been
        documented (CARGO-861 <https://jira.codehaus.org/browse/CARGO-861>)
      o The XML/properties replacement engine can now WARN when a
        replacement is not possible (instead of failing) (CARGO-1099
        <https://jira.codehaus.org/browse/CARGO-1099>)
      o Deployers (and mostly undeployers) can now intelligently ignore
        failures when deploy/undeploy fails (for example, if the
        application is not deployed but one attempts to undeploy it)
        (CARGO-1100 <https://jira.codehaus.org/browse/CARGO-1100>)

*Bug fixes* (7)

  *
      o Proxies that would be previously set by Maven are not used
        during deployment anymore (CARGO-1042
        <https://jira.codehaus.org/browse/CARGO-1042>)
      o Module names in JBoss do not contain any periods anymore
        -allowing the deployment of datasources via Maven2/Maven3 plugin
        (CARGO-1091 <https://jira.codehaus.org/browse/CARGO-1091>)
      o Logging level is now interpreted properly for containers that
        output their messages on stderr (CARGO-1095
        <https://jira.codehaus.org/browse/CARGO-1095>)
      o Jetty can deploy to root (/) context (CARGO-1103
        <https://jira.codehaus.org/browse/CARGO-1103>)
      o cargo.jboss.invoker.pool.port configuration property works
        properly for JBoss 5+ (CARGO-1104
        <https://jira.codehaus.org/browse/CARGO-1104>)
      o Merging of XML files doesn't throw a
        ConcurrentModificationException anymore (CARGO-1105
        <https://jira.codehaus.org/browse/CARGO-1105>)
      o JVM properties on Glassfish now work (CARGO-1108
        <https://jira.codehaus.org/browse/CARGO-1108>)


In addition to these, we have done various changes in the documentation
as well as the Maven archetypes. For example, a profile for JBoss 7.1.x
<http://cargo.codehaus.org/JBoss+7.1.x> has been added to all archetypes
and is configured with an artifactInstaller.

The full release notes can be found on
https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18384&styleName=Html&projectId=10730
<https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18384&styleName=Html&projectId=10730>

To use this new version:

  * Users of the Java API and/or the ANT tasks can download the required
    components (be it the uberjar, ANT tasks and others) via the CARGO
    Downloads page <http://cargo.codehaus.org/Downloads>.
  * Users of the Maven2/Maven3 plugin simply need to change their plugin
    version to 1.2.2.

Please provide your feedback to the user-z8XaHfFCYGOxIXFVlbCvtR2eb7JE58TQ< at >public.gmane.org
<mailto:user-z8XaHfFCYGOxIXFVlbCvtR2eb7JE58TQ< at >public.gmane.org> mailing list.

Enjoy!

Using Cargo to start up Server in Integration test in maven project

MiB — 2012-05-04T12:51:23

I have set up a simple Maven 2 Spring MVC project and want to start by  
doing end to end integration testing in the form of simple short  
Acceptance tests. Everything in my project is set up properly enough  
to work when I run my integration tests with the server started inside  
of Eclipse. I use Tomcat 6.0.35 which is what is on the server, but  
for testing any container would do.

I'm using Surefire 2.8 excluding integration tests and let Failsafe  
2.12 run the integration tests.

As the tests does run though the server isn't starting up resulting in  
build success and test failure, I'm obviously missing some set up that  
would allow some action of Failsafe indirectly or directly to start up  
the server via Cargo. Failsafe executes the goals "integration-test"  
and "verify" and I want Cargo to start the server prior to running the  
integration tests and to stop the server when they're done.

I've read the documentation and several articles, but I'm obviously  
missing some details here. It would be very nice if you would look at  
my set up below and perhaps have an idea for what could be missing  
here. Suggestions for how to do the troubleshooting would also be  
useful.

Can you please assist me a bit in setting this up properly?

My cargo-maven2-plugin setup in pom.xml is for v1.2.1 and looks like  
this:


<configuration>
<container>
<containerId>tomcat6x</containerId>
<type>installed</type>
<home>/Applications/Utveckling/apache-tomcat-6.0.35</home>
</container>

<configuration>
<type>existing</type>
<home>/Applications/Utveckling/apache-tomcat-6.0.35</home>
<properties>
<cargo.servlet.port>${servlet.port}</cargo.servlet.port>
</properties>
</configuration>
</configuration>

<executions>
<execution>
<id>verify-deploy</id>
<phase>install</phase>
<goals>
<goal>deployer-deploy</goal>
</goals>
</execution>
<!-- before integration tests are run: start server -->
<execution>
<id>start-container</id>
<phase>pre-integration-phase</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<phase>post-integration-phase</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
<execution>
<id>clean-undeploy</id>
<phase>pre-clean</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>


/Mikael

NodeMerge question

Neo Qing — 2012-05-04T09:36:35

Hi, Dear Developers:
   I have questions about NodeMerge.
   I want to merge two wars, warA has a web.xml, it has element
<welcome-file-list>
    <welcome-file>index.html</welcome-file>
  </welcome-file-list>
the web.xml of warB  has element as below
 <welcome-file-list>
    <welcome-file>default.html</welcome-file>
      <welcome-file>test.jsp</welcome-file>
  </welcome-file-list>
 I want to merge welcome-file-list and without any information lost, how to
define the merge strategy?
Currently ,I'm using below
<tag name="welcome-file-list">
            <strategy name="NodeMerge">
            <welcome-file-list>
                <welcome-file>$left:welcome-file</welcome-file>
                <welcome-file>$right:welcome-file</welcome-file>
            </welcome-file-list>
            </strategy>
          </tag>
 result is
<welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>default.html</welcome-file>
  </welcome-file-list>
but my expect is
<welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>default.html</welcome-file>
     <welcome-file>test.jsp</welcome-file>
  </welcome-file-list>
So what is the right way to achieve my expect? thanks in advance.

Failing to set JVM properties on Glassfish

Denis N. Antonioli — 2012-05-02T21:37:59

Hi

I'm using the maven cargo plugin 1.2.1.

I want to overwrite some properties during the deployment of my war to glasssfish 3.1, but this doesn't seem to work.

Does anyone got this working?

In my pom, I set:
              <plugin>
                   <groupId>org.codehaus.cargo</groupId>
                   <artifactId>cargo-maven2-plugin</artifactId>
                   <version>1.2.1</version>
                   <configuration>
                       <container>
                           <dependencies>
                               <dependency>
                                   <groupId>org.apache.derby</groupId>
                                   <artifactId>derby</artifactId>
                               </dependency>
                           </dependencies>
                           <systemProperties>
                               <derby.system.home>${project.build.directory}/derby</derby.system.home>
                               <hibernate.hbm2ddl.auto>create-drop</hibernate.hbm2ddl.auto>
                           </systemProperties>
                       </container>
                       ...
               </plugin>

I see in the log that cargo passes these properties to the asadmin command as system properties:

[DEBUG] [talledLocalContainer] Jvm Spawn flag [false]
[DEBUG] [talledLocalContainer] Execute:Java13CommandLauncher: Executing '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/jre/bin/java' with arguments:
'-Dhibernate.hbm2ddl.auto=create-drop'
'-Dderby.system.home=.../target/derby'
'-jar'
'.../target/cargo/installs/glassfish-3.1.2/glassfish3/glassfish/modules/admin-cli.jar'
'--interactive=false'
'--user'
'admin'
'--passwordfile'
'.../target/cargo/configurations/glassfish3x/password.properties'
'create-domain'
'--adminport'
'4848'
'--instanceport'
'8080'
'--domainproperties'
'jms.port=7676:orb.listener.port=3700:orb.ssl.port=3820:http.ssl.port=8181:orb.mutualauth.port=3920:domain.jmxPort=8686:java.debugger.port=9009:osgi.shell.telnet.port=6666'
'--domaindir'
'.../target/cargo/configurations/glassfish3x'
'cargo-domain'


But my application fails during the test as the hibernate property isn't set.


I think that cargo should use a call to asadmin to set the properties on the container (<http://docs.oracle.com/cd/E26576_01/doc.312/e24938/create-system-properties.htm#GSRFM00059>).

Any thoughts?

Thanks
dna

NoClassDefFoundError with GlassFish 3.1.2

hoangx281283 — 2012-05-02T08:04:02

I encountered NoClassDefFoundError problem with Cargo/GlassFish 3.1.2 (i'm
using Ant to deploy the test)

The log message told me that my class, located under
deployed_war/WEB-INF/lib requires a class (a log library) located in
<sharedClasspath>but the web app classloader could not find such class.

Anyone has encountered the same problem as mine?

SSL?

Luis Montes — 2012-05-01T01:54:21

Is is possible to run cargo and listen on a secure port?  Was hoping to
test some oauth2 stuff which requies HTTPS.

Thanks,

Luis

Reload JSPs

Mansour Al Akeel — 2012-04-30T15:56:43

Hello all,
I am using cargo ant to run my webapp. This webapp, contains JSPs
files. When I modify these jsps under full tomcat
($TOMCAT_HOME/webapps/myApp/test.jsp),
I can see the modification when the page reload. With maven-tomcat the
same thing. Reloading is transparent.
With cargo ant, this is not the case. Is there some config I am
missing ? Here's mine:

  <cargo containerId="tomcat7x"
                   home="< at >{tomcat-home}"
                   output="< at >{tomcat-log-dir}/output.log"
                   log="< at >{tomcat-log-dir}/cargo.log"
                   action="run">
                <configuration home="< at >{tomcat-config-dir}">
                    <property name="cargo.servlet.port" value="8080"/>
                    <property name="cargo.logging" value="low"/>
                    <deployable type="war" file="${build.dir}">
                        <property name="context" value="${ant.project.name}"/>
                    </deployable>
                </configuration>
            </cargo>


Thank you.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

ConcurrentModificationException when trying to merge xml file

MrProgrammer55 — 2012-04-27T21:26:37

I went ahead and posted this as a bug at Cargo's site, but I thought I'd post
a message here to see if anyone else has encountered this problem also?

https://jira.codehaus.org/browse/CARGO-1105
https://jira.codehaus.org/browse/CARGO-1105 

Quick summary of bug: Trying to merge 2 non web.xml xml files and get the
following error:

Caused by: java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at
org.codehaus.cargo.module.merge.DocumentMerger.merge(DocumentMerger.java:95)
at
org.codehaus.cargo.module.merge.DocumentMerger.performMerge(DocumentMerger.java:79)
at
org.codehaus.cargo.module.merge.DocumentStreamAdapter.performMerge(DocumentStreamAdapter.java:101)
... 25 more

Using Cargo 1.2.1. Please see link for more info.  Thanks for your time.
Chris

Customize log level for container

hoangx281283 — 2012-04-26T09:36:07

I wish to know how could we set log level on a group of classes for container
running in Cargo, something like

org.abc.xyz.level=FINEST

I have GlassFish started via Cargo, i tried to customize the log config of
orginal GlassFish. However, the log config is always replaced with one
provided by Cargo

Questions on GlassFish 3 with Cargo Ant

hoangx281283 — 2012-04-25T09:01:02

I defined extraClasspath via Ant configuration for GlassFish 3.1.2 container
but it did not work

         <cargo
         containerId="${cargo.container.id}"
         home="${test.cargo.home}"
         log="${cargo.log.dir}/cargo.${test.id}.start.log"
         ....
         <extraClasspath>
           <pathelement location="${correct path to my jar}" />
         </extraClasspath>
         ....

Did anyone encounter the same problem as mine?

I'm using Cargo 1.0.6, and i learnt through Cargo JIRA that Cargo 1.0.6
supports GlassFish 3.x

Use of "existing local configuration for installed Jetty container"

Shum, Adrian — 2012-04-24T03:46:25

Dear all,

 

I was trying to see if I can externalized the JNDI entry by 

providing an external jetty-env.xml 

(http://jira.codehaus.org/browse/CARGO-861)

 

I was then referred to 

https://jira.codehaus.org/browse/CARGO-1083

and I was told it should solve the problem.

 

However, I found difficulties in understanding how to

use this feature to archieve what I want.

 

I don't want Jetty to be pre-installed.  I want a my build

machine be able to just get the source, and it will install

and run Jetty by Cargo automatically, and run my integration

tests against it.  Therefore I don't want jetty-env.xml 

built into my WAR.  Instead, it will be a file provided externally.

 

Can anyone give me some direction on this?

 

Thanks

--

Best regards,

Adrian Shum

Multi-level Contexts failing on Tomcat 7

danhome — 2012-04-05T11:55:05

Apparently multi-level context paths were fixed as part of
https://jira.codehaus.org/browse/CARGO-734, but I'm not having any luck. 
Has anyone else has success getting multi-level contexts to work with Tomcat
7?

If I set the <context>secure#testapp</context> deployment fails with the
following error:

[INFO] [edDeployerDeployMojo] Resolved container artifact
org.codehaus.cargo:cargo-core-container-tomcat:jar:1.2.1 for container
tomcat7x
[DEBUG] Performing deployment action into [Tomcat 7.x Remote]...
[DEBUG] Initial deployable values: groupId = [com.testapp], artifactId =
[testapp], type = [war], location = [null]
[DEBUG] Searching for an artifact that matches
[com.testapp:testapp:war:null]...
[DEBUG] Checking artifact
[com.myapp.test:test-deployment-as01-tomcatsvr2:pom:null]...
[DEBUG] Checking artifact [com.testapp:testapp:war:null]...
[DEBUG] Computed deployable values: groupId = [com.testapp], artifactId =
[testapp], classifier = [null], type = [war], location =
[/Users/Joe/.m2/repo/com/testapp/testapp/1.0/testapp-1.0.war]
[DEBUG] Setting deployable property [context]:[secure#testapp] for
[/Users/Joe/.m2/repo/com/testapp/testapp/1.0/testapp-1.0.war]
[DEBUG] Invoking setter method public synchronized void
org.codehaus.cargo.container.deployable.WAR.setContext(java.lang.String) for
deployable org.codehaus.cargo.container.tomcat.TomcatWAR[testapp-1.0.war]
with argument secure#testapp
[DEBUG] Deploying
[/Users/Joe/.m2/repo/com/testapp/testapp/1.0/testapp-1.0.war] ...
[INFO] [mcat7xRemoteDeployer] Deploying
[/Users/Joe/.m2/repo/com/testapp/testapp/1.0/testapp-1.0.war]
[DEBUG] [mcat7xRemoteDeployer] Tomcat Manager URL is
http://as01.test-dev.local:9080/manager/text
[DEBUG] [ternal.TomcatManager] Invoking Tomcat manager using path
[/deploy?path=%2Fsecure%23testapp]
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] test-deployment ................................... SUCCESS [0.748s]
[INFO] test-deployment-as01 .............................. SUCCESS [0.010s]
[INFO] test-deployment-as01-tomcatsvr2 ................... FAILURE [5.822s]
[INFO] test-deployment-as02 .............................. SKIPPED
[INFO] test-deployment-as02-tomcatsvr1 ................... SKIPPED
[INFO] test-deployment-as02-tomcatsvr2 ................... SKIPPED
[INFO] test-deployment-as03 .............................. SKIPPED
[INFO] test-deployment-as03-tomcatsvr1 ................... SKIPPED
[INFO] test-deployment-as03-tomcatsvr2 ................... SKIPPED
[INFO] test-deployment-as04 .............................. SKIPPED
[INFO] test-deployment-as04-tomcatsvr1 ................... SKIPPED
[INFO] test-deployment-as04-tomcatsvr2 ................... SKIPPED
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 7.539s
[INFO] Finished at: Thu Apr 05 06:50:10 CDT 2012
[INFO] Final Memory: 7M/81M
[INFO]
------------------------------------------------------------------------
[WARNING] The requested profile "test-shared-default" could not be activated
because it does not exist.
[WARNING] The requested profile "test-developer" could not be activated
because it does not exist.
[ERROR] Failed to execute goal
org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deploy (default-cli) on project
test-deployment-as01-tomcatsvr2: Execution default-cli of goal
org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deploy failed: Failed to deploy
[/Users/Joe/.m2/repo/com/testapp/testapp/1.0/testapp-1.0.war]: FAIL - Failed
to deploy application at context path /secure#testapp -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deploy (default-cli) on
project test-deployment-as01-tomcatsvr2: Execution default-cli of goal
org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deploy failed: Failed to deploy
[/Users/Joe/.m2/repo/com/testapp/testapp/1.0/testapp-1.0.war]
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deploy
failed: Failed to deploy
[/Users/Joe/.m2/repo/com/testapp/testapp/1.0/testapp-1.0.war]
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.codehaus.cargo.container.ContainerException: Failed to deploy
[/Users/Joe/.m2/repo/com/testapp/testapp/1.0/testapp-1.0.war]
at
org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.deploy(AbstractTomcatManagerDeployer.java:106)
at
org.codehaus.cargo.maven2.DeployerDeployMojo.performDeployerActionOnSingleDeployable(DeployerDeployMojo.java:56)
at
org.codehaus.cargo.maven2.AbstractDeployerMojo.performDeployerActionOnAllDeployables(AbstractDeployerMojo.java:178)
at
org.codehaus.cargo.maven2.AbstractDeployerMojo.doExecute(AbstractDeployerMojo.java:98)
at
org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:311)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
Caused by:
org.codehaus.cargo.container.tomcat.internal.TomcatManagerException: FAIL -
Failed to deploy application at context path /secure#testapp

at
org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:529)
at
org.codehaus.cargo.container.tomcat.internal.TomcatManager.deployImpl(TomcatManager.java:569)
at
org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:273)
at
org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:256)
at
org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:240)
at
org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.deploy(AbstractTomcatManagerDeployer.java:102)
... 25 more
[ERROR] 
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR]   mvn <goals> -rf :test-deployment-as01-tomcatsvr2

CARGO 1.2.1 is now available, and is not an April fool!

S. Ali Tokmen — 2012-03-31T22:07:25

Dear CARGO enthusiasts

CARGO 1.2.1 is now available; and no this is definitely not an April fool!

Of course, all of you are wondering what that release brings in... As
usual, we have a certain number of fixes and improvements; major
highlights are:

  * 12 bug fixes, be it for core components but also for containers.
  * CARGO now supports starting an installed local container
    independently from the starting instance (Java API, ANT or
    Maven2/Maven3 plugin); so that the started container can "outlive".
    This new feature is called spawning.
  * The Jetty container now supports existing local configuration.
  * JBoss 7.1.0 and 7.1.1 (Final versions) are supported.
  * The XML merger (i.e., uberwar) now does a much more careful work
    when it comes to merging duplicate XML entities.

To use this new version:

  * Users of the Java API and/or ANT tasks can download the CARGO
    uberjar and ANT tasks from the download page:
    http://cargo.codehaus.org/Downloads
  * Maven2/Maven3 users simply need to change the plugin's <version> to
    1.2.1, and Maven2/Maven3 will download the new version automatically.

Please share your good (and bad) findings on the user-z8XaHfFCYGOxIXFVlbCvtR2eb7JE58TQ< at >public.gmane.org
mailing list.

As usual, for those who are wondering, please find below the full change
list:

  * The following issues with the XML merger (i.e., uberwar) have been
    fixed:
      o [CARGO-1078 <https://jira.codehaus.org/browse/CARGO-1078>] -
        Duplicate entries when merging <filter-mapping>
      o [CARGO-1080 <https://jira.codehaus.org/browse/CARGO-1080>] -
        Duplicate entries when merging servlet mappings
      o [CARGO-1081 <https://jira.codehaus.org/browse/CARGO-1081>] -
        Duplicate entries when merging security constraints
      o [CARGO-1094 <https://jira.codehaus.org/browse/CARGO-1094>] -
        Duplicate init-param element when merging filter
      o [CARGO-1096 <https://jira.codehaus.org/browse/CARGO-1096>] - XML
        merger adds xmlns="" entries
  * JBoss-specific fixes:
      o [CARGO-1086 <https://jira.codehaus.org/browse/CARGO-1086>] -
        CARGO doesn't work with JBoss 7.1.0.Final
      o [CARGO-1087 <https://jira.codehaus.org/browse/CARGO-1087>] -
        remote deployment to JBoss AS 7.1.0.Final in standalone
        configuration leads to javax.security.sasl.SaslException
      o [CARGO-1088 <https://jira.codehaus.org/browse/CARGO-1088>] -
        Undeploy fails with a non-farm configuration
  * Jetty-specific fixes:
      o [CARGO-1085 <https://jira.codehaus.org/browse/CARGO-1085>] - WAR
        authentication does not work with embedded Jetty 7.6.x and 8.1.x
  * GlassFish-specific fixes:
      o [CARGO-1077 <https://jira.codehaus.org/browse/CARGO-1077>] -
        Standalone GlassFish configuration deletes all existing
        GlassFish domain when started
  * Tomcat-specific fixes:
      o [CARGO-1082 <https://jira.codehaus.org/browse/CARGO-1082>] -
        CARGO does not create the list of roles in the Tomcat users XML
  * Fixes relating to the Maven2/Maven3 plugin:
      o [CARGO-1089 <https://jira.codehaus.org/browse/CARGO-1089>] -
        pingUrl and pingTimeout doesn't work with cargo:start


  * General improvements:
      o [CARGO-364 <https://jira.codehaus.org/browse/CARGO-364>] - Allow
        spawned execution of an local containers to enable the app
        server to outlive the calling CARGO application (Java API, ANT
        or Maven2/Maven3)
  * XML merger (i.e., uberwar) improvements:
      o [CARGO-1079 <https://jira.codehaus.org/browse/CARGO-1079>] - Add
        support for merging <mime-mapping>
  * Jetty-specific improvements:
      o [CARGO-1083 <https://jira.codehaus.org/browse/CARGO-1083>] - Add
        Jetty support to existing local configuration for installed
        container
      o [CARGO-1093 <https://jira.codehaus.org/browse/CARGO-1093>] -
        Allow jetty existing local container to start using only
        configuration on the server
  * GlassFish-specific improvements:
      o [CARGO-1071 <https://jira.codehaus.org/browse/CARGO-1071>] -
        Allow to start GlassFish domain in debug mode
      o [CARGO-1072 <https://jira.codehaus.org/browse/CARGO-1072>] -
        Allow to set GlassFish debugger port
  * Improvements on the Maven2/Maven3 plugin
      o [CARGO-1097 <https://jira.codehaus.org/browse/CARGO-1097>] -
        Make use of maven artifact when computing location for
        deployable and dependency

You can also see the HTML release notes via
https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18290&styleName=Html&projectId=10730

Enjoy!

Logging settings

Dirk Mahler — 2012-03-29T11:23:42

Hi,

we're using the cargo maven plugin with JBoss 7.1.0.Final. We provide 
our own standalone.xml which is copied by cargo to the container 
configuration and afterwards processed by cargo for adjusting ports etc. 
This works fine so far.

Our problem is that cargo also adjusts the logging configuration by 
applying the values according to "cargo.logging" to the console handler 
and root logger. Is there a way to suppress this and just use the values 
as they are provided from "our" standalone.xml?

Regards

Dirk

Stopping container affects another module in maven parallel build

no1wantdthisname — 2012-03-20T17:42:13

I have multiple integration test modules that start up their own container.  

It works fine when running "mvn verify", but sometimes fails when running
"mvn -T 1C verify".  As far as I can tell, the stop goal of one module is
affecting the other.

Is there a way to prevent this while still being able to run in parallel?

Cargo Maven Plugin: Start permanently in another thread

eduardoh — 2012-03-13T20:17:41

I am trying to start an existing local Jetty with Cargo, using the maven
plugin.

My CI tool (Bamboo) has an agent in the server which executes the maven
goals to deploy my war, and restart the server.

The problem I am facing is:
1) If I use "cargo:start", the server is shut down as soon as the maven
finishes the build
2) If I use "cargo:run", the server starts, but my agent session gets
"locked"/busy since the cargo plugin is waiting for the CTRL+C user command
to finish the maven task.


I believe what I need is a bit of both: the server running in another
thread, so it doesn't lock the parent maven, but without shutting down when
the parent completes.


Is there any thoughts or possibilites in that direction?

Thanks for your usual assistance,
Eduardo

Encountering Exception when deploying in Jetty 7.2x ExistingInstallation

svu004 — 2012-03-06T19:35:18

Hi,

I am trying to deploy a war[say, mywebapp.war] in Jetty7.2x [which is
already installed on my host] and start Jetty container using the below pom.
[All that the pom contains is to have a dependency on the mywebapp.war,
deploy it in the container and start jetty]. 

I am encountering the below " java.lang.NumberFormatException" from Jetty
and Jetty shows up the usage... Any pointers or suggestion to solving the
issue will greatly help me.
Please let me know if there is something that I am missing in my pom.xml
[see below ] 

Note: I am using the 1.2.1-snapshot version that contains Eduardoh's fix for
supporting the Existing Installation Type. 



[INFO]
------------------------------------------------------------------------
[INFO] [talledLocalContainer] Jetty 7.x starting...
[INFO] [talledLocalContainer] Running Jetty As: "C:\Program
Files\Java\jdk1.6.0_
25\jre\bin\java.exe" -Xms128m -Xmx512m -XX:PermSize=48m -XX:MaxPermSize=128m
-Dj
etty.home=C:\test_jetty_home\jetty-distribution-7.2.2.v20101205 -DSTOP.PORT=
-DS
TOP.KEY=secret -Djetty.port=8080
-Dconfig.home=C:\test_jetty_home\jetty-distribu
tion-7.2.2.v20101205
-Djetty.logs=C:\test_jetty_home\jetty-distribution-7.2.2.v2
0101205/logs -classpath "C:\Program Files\Java\jdk1.6.0_25\lib\tools.jar"
-jar C
:\test_jetty_home\jetty-distribution-7.2.2.v20101205\start.jar
OPTIONS=Server,js
p,jmx,resources,websocket,ext --ini --pre
C:\test_jetty_home\jetty-distribution-
7.2.2.v20101205/etc/jetty-logging.xml
C:\test_jetty_home\jetty-distribution-7.2.
2.v20101205/etc/jetty.xml
C:\test_jetty_home\jetty-distribution-7.2.2.v20101205/
etc/jetty-deploy.xml
C:\test_jetty_home\jetty-distribution-7.2.2.v20101205/etc/j
etty-webapps.xml
C:\test_jetty_home\jetty-distribution-7.2.2.v20101205/etc/jetty
-contexts.xml
C:\test_jetty_home\jetty-distribution-7.2.2.v20101205/etc/jetty-te
strealm.xml "path=C:\Program Files\Java\jdk1.6.0_25\lib\tools.jar"
[INFO] [talledLocalContainer] java.lang.NumberFormatException: For input
string:
 ""
[INFO] [talledLocalContainer]   at
java.lang.NumberFormatException.forInputStrin
g(NumberFormatException.java:48)
[INFO] [talledLocalContainer]   at
java.lang.Integer.parseInt(Integer.java:470)
[INFO] [talledLocalContainer]   at
java.lang.Integer.parseInt(Integer.java:499)
[INFO] [talledLocalContainer]   at
org.eclipse.jetty.start.Main.start(Main.java:
501)
[INFO] [talledLocalContainer]   at
org.eclipse.jetty.start.Main.parseCommandLine
(Main.java:273)
[INFO] [talledLocalContainer]   at
org.eclipse.jetty.start.Main.main(Main.java:8
1)
[INFO] [talledLocalContainer]
[INFO] [talledLocalContainer] Usage: java -jar start.jar [options]
[properties]
[configs]
[INFO] [talledLocalContainer]        java -jar start.jar --help  # for more
info
rmation

======================

Snippet of my pom.xml:


<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.2.1-SNAPSHOT</version>
<configuration>
<!-- Container configuration -->
<container>
<containerId>jetty7x</containerId>
<type>installed</type>
<home>C:\xxxx\jetty-distribution-7.2.2.v20101205\</home>
</container>

<configuration>
<type>existing</type>
<home>C:\xxxx\jetty-distribution-7.2.2.v20101205\</home>
</configuration>
<deployer>
<deployables>
<!-- This deployable specifies the webapp you want to deploy -->
<deployable>
<artifactId>mywebapp</artifactId>
<groupId>com.xxx.yyy</groupId>
<type>war</type>
</deployable>
</deployables>
</deployer>
</configuration>

<executions>
<execution>
<id>verify-deploy</id>
<phase>install</phase>
<goals>
<goal>deployer-deploy</goal>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>clean-undeploy</id>
<phase>pre-clean</phase>
<goals>
<goal>stop</goal>
<goal>deployer-undeploy</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

How can I deploy to running JBoss 7.1 using Cargo?

laredotornado — 2012-03-01T22:48:32

Hi,

I'm using Maven 3.0.3 and trying to deploy my app to a running JBoss 7.1
server, installed locally.  What dependencies do I need to include to make
this happen?  Here is my current Cargo configuration ...

<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.1.3</version>
<configuration>
<container>
<containerId>jboss7x</containerId>
<type>remote</type>
</container>
</configuration>
<executions>
<execution>
<id>deploy</id>
<phase>install</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>

And here is the error message I'm getting ...

[ERROR] Failed to execute goal
org.codehaus.cargo:cargo-maven2-plugin:1.1.3:deploy (deploy) on project
event-maven: Execution deploy of goal
org.codehaus.cargo:cargo-maven2-plugin:1.1.3:deploy failed: Failed to create
deployer with implementation class
org.codehaus.cargo.container.jboss.JBoss7xRemoteDeployer for the parameters
(container [id = [jboss7x]], deployer type [remote]).
InvocationTargetException: Cannot locate the JBoss connector classes! Make
sure the required JBoss JARs (or Maven dependencies) are in CARGO's
classpath.

Thanks for your guidance, - Dave

No datasource configuration generated

Serkan Erdur — 2012-03-01T13:09:41

Hi,

Below is my maven pom configuration.
I am running "clean integration-test" and in the end no datasource
configuration is produced in "tomcat/conf/" server.xml or context.xml. Otherwise
everything seems ok (oracle jar is copied into common/lib).
Anyone ideas?

Many thanks
                              <plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.2.0</version>
<executions>
<execution>
<id>start</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
<configuration>
<wait>false</wait>
<!-- Container Configuration -->
<container>
<containerId>tomcat6x</containerId>
<zipUrlInstaller>
<url>https://xxx/content/groups/global/tomcat/tomcat-
6/apache-tomcat/6.0.33/apache-tomcat-6.0.33.zip</url>
<proxy>
<host>xxx</host>
<port>8080</port>
</proxy>
</zipUrlInstaller>

<output>${project.build.directory}/cargo/container.log</output>
<append>false</append>
<log>${project.build.directory}/cargo/cargo.log</log>
<timeout>600000</timeout>
<systemProperties>
<environment>${test-environment}</environment>
<hostname>${hostname}</hostname>
<logdirectory>${project.build.directory}/tomcat/logs</logdirectory>
</systemProperties>
<dependencies>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc14</artifactId>
</dependency>
</dependencies>
</container>
<properties>
<cargo.datasource.datasource.oracle>

cargo.datasource.driver=oracle.jdbc.OracleDriver|

cargo.datasource.url=jdbc:oracle:thin:< at >xxx:1521:xxx|
cargo.datasource.jndi=jdbc/kuz_cdb_DS|
cargo.datasource.username=xxx|
cargo.datasource.password=xxx
</cargo.datasource.datasource.oracle>
<cargo.datasource.datasource.oracle>

cargo.datasource.driver=oracle.jdbc.OracleDriver|

cargo.datasource.url=jdbc:oracle:thin:< at >xxx:1521:xxx|
cargo.datasource.jndi=jdbc/kuz_kuz_DS|
cargo.datasource.username=xxx|
cargo.datasource.password=xxx
</cargo.datasource.datasource.oracle>
</properties>
<configuration>
<type>standalone</type>
<home>${project.build.directory}/tomcat</home>
<properties>
<cargo.servlet.port>8080</cargo.servlet.port>
<cargo.logging>medium</cargo.logging>
<cargo.jvmargs>-Xmx500m</cargo.jvmargs>
</properties>
<deployables>
<deployable>
<groupId>com.xxx</groupId>
<artifactId>kuzu-webapp</artifactId>
<type>war</type>
<properties>
<context>kuzu</context>
</properties>

<pingURL>http://localhost:8080/kuzu/healthCheck.jsp</pingURL>
</deployable>
</deployables>
</configuration>
</configuration>
</plugin>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

No datasource configuration generated in server.xml.

serkan — 2012-03-01T12:48:52

Hi,

Below is my maven pom configuration.
I am running "clean integration-test" and in the end no datasource
configuration is produced in "tomcat/conf/server.xml". Otherwise
everything seems ok (oracle jar is copied into common/lib).
Anyone ideas?

Many thanks
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.1.4</version>
<executions>
<execution>
<id>start</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
<configuration>
<wait>false</wait>
<!-- Container Configuration -->
<container>
<containerId>tomcat6x</containerId>
<zipUrlInstaller>
<url>https://xxxx/content/groups/global/tomcat/tomcat-6/apache-tomcat/6.0.33/apache-tomcat-6.0.33.zip</url>
<proxy>
<host>xxxx</host>
<port>8080</port>
</proxy>
</zipUrlInstaller>
<output>${project.build.directory}/cargo/container.log</output>
<append>false</append>
<log>${project.build.directory}/cargo/cargo.log</log>
<timeout>600000</timeout>
<systemProperties>
<environment>${test-environment}</environment>
<hostname>${hostname}</hostname>
<!-- Redirects the logs to the target directory. This is
referenced inside the log4j configuration. -->
<logdirectory>${project.build.directory}/tomcat/logs</logdirectory>
</systemProperties>
<dependencies>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc14</artifactId>
</dependency>
</dependencies>
</container>
<properties>
<cargo.datasource.datasource.oracle>
cargo.datasource.driver=oracle.jdbc.OracleDriver|
cargo.datasource.url=jdbc:oracle:thin:< at >xxx:1521:cdbdev|
cargo.datasource.jndi=jdbc/kuz_cdb_DS|
cargo.datasource.username=xxx|
cargo.datasource.password=xxx
</cargo.datasource.datasource.oracle>
<cargo.datasource.datasource.oracle>
cargo.datasource.driver=oracle.jdbc.OracleDriver|
cargo.datasource.url=jdbc:oracle:thin:< at >xxx:1521:cdbdev|
cargo.datasource.jndi=jdbc/kuz_kuz_DS|
cargo.datasource.username=xxx|
cargo.datasource.password=xxx
</cargo.datasource.datasource.oracle>
</properties>
<configuration>
<type>standalone</type>
<home>${project.build.directory}/tomcat</home>
<properties>
<cargo.servlet.port>8080</cargo.servlet.port>
<cargo.logging>medium</cargo.logging>
<cargo.jvmargs>-Xmx500m</cargo.jvmargs>
</properties>
<deployables>
<deployable>
<groupId>com.xxx</groupId>
<artifactId>kuzu-webapp</artifactId>
<type>war</type>
<properties>
<context>kuzu</context>
</properties>
<pingURL>http://localhost:8086/kuzu/healthCheck.jsp</pingURL>
</deployable>
</deployables>
</configuration>
</configuration>
</plugin>

Starting jetty with server configuration file

eduardoh — 2012-03-01T08:50:18

Hi there,

In our company, we have a common installation of jetty in the server, and
each application runs in a different instance of the common installation.

Deployment using maven cargo (Jetty 7x installed local deployment) is
working great - but stopping and starting the container after the deployment
has some problems, let me try to clarify.

Many properties, like jetty port, rmi port, jetty home, etc are different
for each application.
For the moment, the server admins have a file for each application which
loads these specific properties, which is called in their script before
calling the jetty.jar.

Obviously, we don't want to use same scripts to start/stop jetty, therefore
we want to use jetty + cargo capabilities to do similar.

Our initial thought was to have a specific start.ini for each app, where
they can load their variables, and all the configuration will be in the
server admin hands - not somewhere in the pom.xml of each app.
The only thing each application would have to know is the name (location) of
its start.ini in the server, and the maven cargo plugin would load that.

Quickly looking at the Jetty7xInstalledLocalContainer, I see two
incompatibilities with our approach:
1) variables are loaded from system property (ports, etc)
2) cargo doesn't load the ini file

I guess, for item 2) we can use "cargo.runtime.args".
But for item 1) we don't want to leave error prone in the maven plugin set
up, we want to leave that configuration in the server only.

I would like your thoughts about it - I can create another patch if we agree
on a solution :-)

Thank you,
Eduardo