Cannot invoke Tomcat manager w/Jenkins - maven

I'm managing the builds for a web service with Jenkins, and I've run into a problem with Tomcat. I'm getting the following error and stack trace:
mavenExecutionResult exceptions not empty
message : Failed to execute goal org.codehaus.mojo:tomcat-maven-plugin:1.1:redeploy(default-cli) on project rnr: Cannot invoke Tomcat manager
cause : Cannot invoke Tomcat manager
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:tomcat-maven-plugin:1.1:redeploy (default-cli) on project rnr: Cannot invoke Tomcat manager
Here's my pom configuration for the Tomcat maven plugin:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<version>1.1</version>
<configuration>
<url>http://localhost:8080/manager/text</url>
<server>TomcatServer</server>
<path>/</path>
</configuration>
</plugin>
EDIT: I'm using Tomcat 7.0.42.
I'm not sure exactly what the problem is or if I've provided enough information, so let me know if more is needed. This is the first time I've run into this problem, and to my knowledge nothing in the pom or jenkins setup has changed, so I don't know where this error is coming from.
Thank you!!

Related

What Build Module in IntelliJ actually does for maven module

When I run
mvn clean install
for my maven module then it compiles fine. No issues.
But when I open my pom.xml file in IntelliJ and I choose to Build -> Build module then I get following issues:
Information:javac 1.8.0_144 was used to compile java sources
Information:Module "mymodule" was fully rebuilt due to project configuration/dependencies changes
Information:09.10.2017 21:16 - Compilation completed with 3 errors and 3 warnings in 23s 991ms
C:\somepath\mymodule\pom.xml
Error:Error:osgi: [mymodule] Exception: java.lang.ClassNotFoundException: org.apache.sling.bnd.models.ModelsScannerPlugin not found, parent: java.net.URLClassLoader#29453f44 urls:[] exception:java.lang.ClassNotFoundException: org.apache.sling.bnd.models.ModelsScannerPlugin
Error:Error:osgi: [mymodule] Failed to load plugin org.apache.sling.bnd.models.ModelsScannerPlugin;generatePackagesHeader=true, error: java.lang.ClassNotFoundException: org.apache.sling.bnd.models.ModelsScannerPlugin not found, parent: java.net.URLClassLoader#29453f44 urls:[] exception:java.lang.ClassNotFoundException: org.apache.sling.bnd.models.ModelsScannerPlugin
Error:Error:osgi: [mymodule] Cannot load the plugin org.apache.sling.bnd.models.ModelsScannerPlugin
This is a module with AEM code and it uses maven-sling-plugin. It works fine for other developers in the project. Because it's working when executed directly from maven I'm trying to understand what IntelliJ does in the background. But actually, my problem is those compilation issues.
From what I've found IntelliJ does not call maven when Build is done. Any ideas how can I find differences between running from IntelliJ and directly from Maven?
What happens here is that the ModelScanner plugin can't be found using the current ClassLoader. The reason for this can be that you are using IntelliJ IDEA Ultimate which comes with a OSGI plugin already pre-installed called 'Osmorc'. If this OSGI plugin is active it will determine the classloader to be used for building OSGI related projects.
So simply de-activating this Osmorc plugin in IntelliJ should allow your build to revert to the classloader from the ModelScannerPlugin mentioned in the configuration of your the maven-bundle-plugin in your projects POM.xml file which should solve the problem.
If this still results in a similar Maven build error, then make sure to add a Maven dependency 'org.apache.sling.bnd.model' to your maven-bundle-plugin in your POM.xml file.
<!-- Apache Felix Bundle Plugin -->
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>3.3.0</version>
<inherited>true</inherited>
<extensions>true</extensions>
<executions>
<!-- Configure extra execution of 'manifest' in process-classes phase to make sure SCR metadata is generated before unit test runs -->
<execution>
<id>scr-metadata</id>
<goals>
<goal>manifest</goal>
</goals>
<configuration>
<supportIncrementalBuild>true</supportIncrementalBuild>
</configuration>
</execution>
</executions>
<configuration>
<exportScr>true</exportScr>
<instructions>
<!-- Enable processing of OSGI DS component annotations -->
<_dsannotations>*</_dsannotations>
<!-- Enable processing of OSGI metatype annotations -->
<_metatypeannotations>*</_metatypeannotations>
<_plugin>org.apache.sling.bnd.models.ModelsScannerPlugin;generatePackagesHeader=true</_plugin>
</instructions>
</configuration>
<dependencies>
<dependency>
<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.bnd.models</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</plugin>
could you please check your core pom file. it should contain a plugin section like this:
<plugin> <!-- Enable registration of Sling Models classes via bnd plugin --> org.apache.sling.bnd.models.ModelsScannerPlugin, <!-- Allow the processing of SCR annotations via a bnd plugin --> org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=${project.build.outputDirectory} </plugin>
but if you created a project using aem archetype the tag looks like' <_plugin>

Create an EAR using Maven

I want to create an EAR using Maven, but since I'm in a pure Tycho world, I can't use the maven-ear-plugin, just the maven-assembly-plugin (which is fine).
There are multiple questions even on this very site that indicate that the maven-assembly-plugin can build EARs, even though the documentation says no.
However, when I use define the EAR format like this:
<formats>
<format>ear</format>
</formats>
I get the following exception:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:3.0:single (make-assembly) on project org.acme.application: Failed to create assembly: Error creating assembly archive default: appxml attribute is required -> [Help 1]
(I tried a couple of versions for the maven-assembly-plugin, so it's not that.)
Since a EAR is just a renamed JAR, I'm now using the JAR format and this other Maven plug-in:
<plugin>
<groupId>com.coderplus.maven.plugins</groupId>
<artifactId>copy-rename-maven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>rename-ear</id>
<phase>verify</phase>
<goals>
<goal>rename</goal>
</goals>
<configuration>
<sourceFile>${basedir}/target/${earName}.jar</sourceFile>
<destinationFile>${basedir}/target/${earName}.ear</destinationFile>
</configuration>
</execution>
</executions>
</plugin>
Which works nicely in creating an EAR, however with mvn install it brings the following exception:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-install-plugin:2.5.2:install (default-install) on project org.acme.application: Failed to install artifact group:org.acme.application:jar:1.9.126-SNAPSHOT: C:\workspace\Application\target\Application.jar (Das System kann die angegebene Datei nicht finden) -> [Help 1]
(It's German for "Cannot find file", one day I'll get him to print out readable error messages.)
Of course, now I could copy the JAR to an EAR instead of just renaming it, but I thought I get a 2nd oppinion first: Is it possible to create an EAR with the maven-assembly-plugin? If so, how?

Error initializing enunciate - generate step error

I have configured my REST/Spring/Jersey project to generate documentation for APIs using enunciate.
The relevant changes in my pom.xml are
<plugin>
<groupId>org.codehaus.enunciate</groupId>
<artifactId>maven-enunciate-spring-plugin</artifactId>
<version>1.28</version>
<configuration>
<generateDir>${project.build.directory}/enunciate-generate</generateDir>
<configFile>enunciate.xml</configFile>
<exports>
<jaxws.client.library.binaries>client.jar</jaxws.client.library.binaries>
</exports>
</configuration>
<executions>
<execution>
<goals>
<goal>assemble</goal>
</goals>
</execution>
</executions>
</plugin>
.....
<dependency>
<groupId>org.codehaus.enunciate</groupId>
<artifactId>maven-enunciate-spring-plugin</artifactId>
<version>1.28</version>
</dependency>
My enunciate.xml is as follows
<?xml version="1.0"?>
<enunciate xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://enunciate.codehaus.org/schemas/enunciate-1.28.xsd">
<api-classes>
<include pattern="com.xxx.rest.*"/>
</api-classes>
<modules>
<docs docsDir="api" title="REST WebServices API"/>
<spring-app>
<war mergeWebXML="war/WEB-INF/web.xml"/>
<springImport file="war/WEB-INF/applicationContext-jdbc.xml"/>
</spring-app>
</modules>
</enunciate>
When I run my maven project I get the following error initializing enunciate. As you can see the error is not very helpful. Any hints what could be wrong in my configuration.
--- maven-enunciate-spring-plugin:1.28:assemble (default) # xxx ---
initializing enunciate.
[csharp] C# compilation is disabled, but the source code will still be generated.
invoking enunciate:generate step...
BUILD FAILURE
Total time: 3.324s
Failed to execute goal org.codehaus.enunciate:maven-enunciate-spring-plugin:1.28:assemble (default) on project xxx: Problem assembling the enunciate app. String index out of range: 0 -> [Help 1]
To see the full stack trace of the errors, re-run Maven with the -e switch.
Re-run Maven using the -X switch to enable full debug logging.
For more information about the errors and possible solutions, please read the following articles:
[Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
That StringIndexOutOfBoundsException was reported and fixed here.
The "invocation of API has failed" is almost always caused by some compile failure. Maybe when you messed with your dependencies to get around the first problem, you introduced a compile failure in your code base?

Howto use Maven Cargo Plugin to deploy a Web Application Bundle (WAB, OSGI + JavaEE) into Glassfish 3.x

I'm trying to use the Maven Cargo Plugin to deploy a set of OSGI bundles and an hybrid application .war (Webapplication with Restservice which uses OSGI) also called a Web Application Bundle (or WAB) (e.g. see https://glassfish.java.net/public/GF-OSGi-Features.pdf).
Deploying of OSGI bundles into a Glassfish 3.1.x works fine, but I haven't found a way to deploy the Web Application Bundle.
It's packaging is "war", but I have to deploy it as OSGI bundle. So how can I tell this the Cargo Plugin?
The maven configuration I tried to use:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.4.0</version>
<configuration>
<wait>false</wait>
<container>
<containerId>glassfish3x</containerId>
<home>${glassfish.home}</home>
<type>installed</type>
</container>
<configuration>
<type>existing</type>
<home>${glassfish.home}</home>
<properties>
<cargo.hostname>localhost</cargo.hostname>
<cargo.rmi.port>4848</cargo.rmi.port>
<cargo.domain.name>${glassfish.domain}</cargo.domain.name>
</properties>
</configuration>
<deployables>
<deployable>
<groupId>com.acme.rest</groupId>
<artifactId>rest-api</artifactId>
<type>bundle</type>
</deployable>
</deployables>
</configuration>
</plugin>
But the following error shows up:
[ERROR] Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.4.0:redeploy (default-cli) on project rest-api: Artifact [com.acme.rest:rest-api:bundle] is not a dependency of the project. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.4.0:redeploy (default-cli) on project rest-api: Artifact [com.acme.rest:rest-api:bundle] is not a dependency of the project.
Deploying as component type "web" works, but then I can't use the OSGI bundles...
Does anybody have experience with deploying Web Application Bundle and OSGI bundles?
I don't know about cargo plugin, but to deploy a wab using asadmin client, one has to pass a --type=osgi option as shown below:
asadmin deploy --type=osgi foo.war
So, see if you can configure cargo plugin to pass this option.
Sahoo
The trick is :
<deployable>
<groupId>com.acme.rest</groupId>
<artifactId>rest-api</artifactId>
<type>war</type>
<implementation>org.codehaus.cargo.container.deployable.Bundle</implementation>
</deployable>
You still have a WAR artifact, but Bundle will trick Cargo to deploy it as OSGi.
Try using version 1.4.7 which added support for sending asadmin params in conjunction with the param that #Sahoo mentioned.
<cargo.glassfish.deploy.arg.1>--type=osgi foo.war</cargo.glassfish.deploy.arg.1>
Allow passing extra parameters for glassfish deployment
https://jira.codehaus.org/browse/CARGO-1245

Unable to deploy to Tomcat7 from cargo

I'm trying to deploy to a remote Tomcat7 with Cargo from Maven over https.
I've set up manager-script role and I've succeeded so far as to have been able to undeploy an app remotely.
What I have looks like this:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.1.2</version>
<configuration>
<container>
<containerId>tomcat7x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.remote.uri>https://xxx/manager/text</cargo.remote.uri>
<cargo.remote.username>${tomcat.username}</cargo.remote.username>
<cargo.remote.password>${tomcat.password}</cargo.remote.password>
</properties>
</configuration>
<deployer>
<type>remote</type>
<deployables>
<deployable>
<groupId>mycomp</groupId>
<artifactId>myartifact</artifactId>
<type>war</type>
<properties>
<context>/</context>
</properties>
</deployable>
</deployables>
</deployer>
</configuration>
</plugin>
Well, I know the credentials and everything is setup correctly, and I have used the new /text interface and I have been able to undeploy an existing app. But when trying to run deploy:
mvn cargo:deployer-deploy -e
I get an error with root cause:
Caused by: java.io.IOException: Error writing request body to server
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:2809)
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:2792)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.pipe(TomcatManager.java:605)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:501)
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:101)
... 25 more
I get it quite immediately so it can't be a timeout.
Can the file be to large? It's a 60 MB war. I made sure my nginx allows bigger:
client_max_body_size 200M;
I also added multipart config to the text manager in the manager webapps web.xml like this:
servlet>
Manager
org.apache.catalina.manager.ManagerServlet
debug
2
<multipart-config>
<max-file-size>209715200</max-file-size>
<max-request-size>209715200</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config>
http://nexnet.wordpress.com/2011/04/27/large-war-file-cannot-be-deployed-in-tomcat-7/
I love Maven in many ways, but the error reporting is really terrible. Any help highly appreciated.
I was bitten by this error recently, when I tried to cargo:deploy an artifact. Usually we stop, clean and start the webapps directory before deploying, but this time I noticed that one artifact was not removed.
After switching to cargo:redeploy the error was solved.
I ran into this same error message when deploying to a tomcat 8 server using the ant deploy task. The issue in my case was that I was running out of space on the server. Checking tomcat's manager log is what clued me in:
10-Jul-2014 10:15:38.065 INFO [http-nio-8080-exec-2] org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web application '/abc_beta'
10-Jul-2014 10:15:38.065 INFO [http-nio-8080-exec-2] org.apache.catalina.core.ApplicationContext.log Manager: Uploading WAR file to /usr/share/apache-tomcat-8.0.9/webapps/abc_beta.war
10-Jul-2014 10:15:57.962 SEVERE [http-nio-8080-exec-2] org.apache.catalina.core.ApplicationContext.log Manager: managerServlet.check[/abc_beta]
java.io.IOException: No space left on device
... stacktrace ...
I don't remember if or how I solved this, but as rascio has the same problem, I'll post a an idea. Maybe it's the wagon-extension for ssl that's needed:
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh</artifactId>
<version>2.2</version>
</extension>
</extensions>
Wild guess though. I think you didn't need it before Maven 3.0.
Another reason for this exception that we stumbled upon suddenly on monday, when deployment jobs on our Jenkins instance using the cargo plugin plugin stopped working. Not all of them, but some. The main difference was a a custom settings.xml in the jobs for a Nexus repository to download deployables from.
The successful deployment jobs had it configured like described in https://support.sonatype.com/entries/20943003-configure-maven-to-download-from-nexus, the failed ones were missing the repository and pluginRepository
I'm still not sure why the behavior changed at one point. Any tipps?

Resources