Jboss Maven plugin takes too long to deploy - maven

I use the Maven auto-deploy plugin to auto deploy to the Jboss application server.
The deployment plugin is configured as shown below:
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.0.2.Final</version>
<configuration>
<hostname>localhost</hostname>
<port>9999</port>
<filename>TestApp.war</filename>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
</plugin>
The deployment does work but the problem is that it takes quite a while for the deployment to take place. It is as though it is waiting for something to happen. I just stays there waiting and eventually it does complete.
When it gets to this point it gets stuck.
[INFO] --- jboss-as-maven-plugin:7.0.2.Final:deploy (default) # TestApp---
[INFO] Executing goal deploy on server localhost (127.0.0.1) port 9999.
29-Feb-2012 15:52:15 org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 3.2.0.Beta2
29-Feb-2012 15:52:15 org.xnio.Xnio <clinit>
INFO: XNIO Version 3.0.0.Beta2
29-Feb-2012 15:52:15 org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.0.0.Beta2
[INFO]
In some cases it just gets stuck at the above point and nothing happens unless i press the Carriage Return key on the Jboss console for something to happen.
Environment
Maven 3
Jboss 7.0.2

I just did some tests, with a small helloworld deployment, and didn't experience any slowness or hanging. The initial deployment took about 15 seconds and subsequent redploys took only a few seconds.
My test environment:
Windows 7 64-bit
Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
JBoss AS 7.0.2.Final certified web profile
JBoss AS Maven Plugin 7.0.2.Final

Related

Vaadin Custom Components/Widgets with Maven and Spring Boot

I am relatively new to vaadin and started out with a spring boot application and the vaadin spring boot plugin. Everything worked fine until I got to the point where I tried to create my own components/widgets.
Unfortunately I didn't find any "official" example/documentation how to set up custom components within a spring boot application so I had to search the web to find out how to set up additional plugin(s) in maven to compile the code for the client side widgets. As far as I can tell from the log output the compilation of these components work, but when I try to access these components on the webpage I get an error:
Widgetset 'com.vaadin.DefaultWidgetSet' does not contain implementation for net.gtidev.test.components.MyComponent. Check its component connector's #Connect mapping, widgetsets GWT module description file and re-compile your widgetset. [...]
Here is the widget compiler log:
[INFO] Using com.vaadin:vaadin-client-compiler version 7.6.4
[ERROR] Mar 22, 2016 10:22:43 AM java.util.prefs.WindowsPreferences <init>
[ERROR] WARNUNG: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
[INFO] Compiling module net.gtidev.test.components.TestWidgetset
[INFO] Computing all possible rebind results for 'com.vaadin.client.metadata.ConnectorBundleLoader'
[INFO] Rebinding com.vaadin.client.metadata.ConnectorBundleLoader
[INFO] Invoking generator com.vaadin.server.widgetsetutils.ConnectorBundleLoaderFactory
[INFO] Populating eager bundle
. . . . . 250 more lines
[INFO] Computing all possible rebind results for 'com.vaadin.client.ui.dd.VAcceptCriterionFactory'
[INFO] Rebinding com.vaadin.client.ui.dd.VAcceptCriterionFactory
[INFO] Invoking generator com.vaadin.server.widgetsetutils.AcceptCriteriaFactoryGenerator
[INFO] Detecting available criteria ...
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.AcceptAll
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.And
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.ContainsDataFlavor
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.SourceIs
[INFO] creating mapping for com.vaadin.ui.AbstractSelect.TargetItemIs
[INFO] creating mapping for com.vaadin.ui.AbstractSelect.AcceptItem
[INFO] creating mapping for com.vaadin.ui.Table.TableDropCriterion
[INFO] creating mapping for com.vaadin.ui.Tree.TreeDropCriterion
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.Not
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.Or
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.ServerSideCriterion
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.SourceIsTarget
[INFO] creating mapping for com.vaadin.event.dd.acceptcriteria.TargetDetailIs
[INFO] creating mapping for com.vaadin.ui.Tree.TargetInSubtree
[INFO] Done. (0seconds)
[INFO] Compiling 1 permutation
[INFO] Compiling permutation 0...
[INFO] Compile of permutations succeeded
[INFO] Compilation succeeded -- 59,217s
[INFO] Linking into C:\projects\misc\vaadin-boot\target\vaadin-boot-0.0.1-SNAPSHOT\net.gtidev.test.components.TestWidgetset
[INFO] Link succeeded
[INFO] Linking succeeded -- 0,492s
The files I use for my custom component were generated by the eclipse vaadin addon within a vaadin 7 project which I created only for this purpose. When I started this vaadin 7 project in eclipse the component worked. I then copied these files into my spring boot maven project where the custom component does not get loaded any more.
I know that spring boot applications have a slightly different bootstrap mechanism and layout than "classic" webapps and that amongst other things static resources are not loaded from the webapp-folder but from the classpath:/static folder. I think that the core of the problem has something to do with this fact but I don't know what to do to fix it.
My Plugin configuration (I tried with and without the commented options):
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>7.6.4</version>
<configuration>
<strict>true</strict>
<force>true</force>
<!-- Enable during development to speed compiling. -->
<!-- <draftCompile>true</draftCompile>
<style>DETAILED</style> -->
<!-- End development options -->
<!--<webappDirectory>src/main/webapp/VAADIN/widgetsets</webappDirectory>-->
<modules>
<module>net.gtidev.test.components.TestWidgetset</module>
</modules>
</configuration>
<executions>
<execution>
<goals>
<goal>resources</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
I tried different maven plugin combinations and configurations. In one example, there was also a Google-GWT Plugin mentioned, but running this plugin on the code produced the same log output as the vaadin plugin:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.5.1</version>
<!--<configuration>-->
<!--<webappDirectory>src/main/webapp/VAADIN/widgetsets</webappDirectory>-->
<!--<extraJvmArgs>-Xmx512M -Xss1024k</extraJvmArgs>-->
<!--<runTarget>clean</runTarget>-->
<!--<hostedWebapp>${project.build.directory}/${project.build.finalName}</hostedWebapp>-->
<!--<noServer>true</noServer>-->
<!--<port>8080</port>-->
<!--<soycDetailed>false</soycDetailed>-->
<!--</configuration>-->
<executions>
<execution>
<goals>
<goal>resources</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
To use custom client side extensions, Vaadin Add-ons, you'll need to add vaadin-maven-plugin to your project. It will scan the add-ons you use and GWT compile a new widgetset for your project that contains those extensions.
If you created the project with start.spring.io the maven plugin is not in your project by default. Create an example project for example using this Vaadin+Spring archetype or the official servlet based archetype and copy the vaadin-maven-plugin related parts from the pom.xml to your projects pom.xml. Then do a full build and everything should works as expected.

Jmeter Maven Plugin - Remote server config with parameters in pom.xml

I am trying to execute a jmeter test using the maven plugin on a remote server leveraging a pom.xml file that is completely parameterized as below.(I was able to successfully run a maven-jmeter remote test, where the servername, port, protocol and other info are all hard coded in the jmx file.
My pom.xml file is below
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>jmeter-demo</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>jmeter-demo</name>
<url>http://maven.apache.org</url>
<description>
Executes a JMeter test.
</description>
<properties>
<webapp.protocol>http</webapp.protocol>
<!--<webapp.host>www.mozilla.com</webapp.host>-->
<webapp.host>fsa-mia-dev2.fsalabs.io</webapp.host>
<webapp.port>80</webapp.port>
<test.duration>30</test.duration>
<test.threads>10</test.threads>
</properties>
<build>
<plugins>
<plugin>
<groupId>com.lazerycode.jmeter</groupId>
<artifactId>jmeter-maven-plugin</artifactId>
<version>1.9.0</version>
<executions>
<execution>
<!--
1)
first test run warms up the webserver.
Used to fill caches.
With a different set of properties since it runs much shorter than a normal test
and also the rate of requests/second may be much lower.
Maybe also use a different URL set.
-->
<id>warmup</id>
<phase>integration-test</phase>
<goals>
<goal>jmeter</goal>
</goals>
<configuration>
<propertiesUser>
<!--Accesses urls for warmup (compiles JSPs, fills caches, ...)-->
<!--************Setup Config for Threadgroup 23***************-->
<threadgroup23.name>S23_SFA_Org_CO</threadgroup23.name>
<threadgroup23.Transactionname>T23_SFA_Org_CO</threadgroup23.Transactionname>
<threadgroup23.ThinkTime>5000</threadgroup23.ThinkTime>
<threadgroup23.comment>T23_SFA_Org_CO</threadgroup23.comment>
<!--number of threads to use-->
<threadgroup23.numberOfThreads>5</threadgroup23.numberOfThreads>
<!--delay of the test in seconds-->
<threadgroup23.scheduledDelay>0</threadgroup23.scheduledDelay>
<!--duration of the test in seconds-->
<threadgroup23.scheduledDuration>60</threadgroup23.scheduledDuration>
<!--how long till all threads are up and running in seconds-->
<threadgroup23.rampUp>1</threadgroup23.rampUp>
<threadgroup23.dataFile>/home/ubuntu/mproj/data/S23_SFA_Org_CO.dat</threadgroup23.dataFile>
</propertiesUser>
</configuration>
</execution>
</executions>
<configuration>
<testFilesIncluded>
<testFilesIncluded>01_SA_CU_GetCPS.jmx</testFilesIncluded>
</testFilesIncluded>
<!-- protocol, server and port of tested webapp -->
<propertiesUser>
<protocol>${webapp.protocol}</protocol>
<server>${webapp.host}</server>
<port>${webapp.port}</port>
</propertiesUser>
<resultsFileFormat>csv</resultsFileFormat>
<testResultsTimestamp>false</testResultsTimestamp>
<ignoreResultFailures>true</ignoreResultFailures>
<remoteConfig>
<startServersBeforeTests>true</startServersBeforeTests>
<serverList>10.36.14.170</serverList>
</remoteConfig>
<suppressJMeterOutput>false</suppressJMeterOutput>
<propertiesSystem>
</propertiesSystem>
<propertiesJMeter><log_level.jmeter>DEBUG</log_level.jmeter></propertiesJMeter>
</configuration>
</plugin>
</plugins>
</build>
</project>
The issue is.. jmeter-server detects a request to execute and almost immediately stops.
Here is the info from log file post run
[debug] JMeter is called with the following command line arguments: -n -t /home/ubuntu/mProj/src/test/jmeter/01_SA_CU_GetCPS.jmx -l /home/ubuntu/mProj/target/jmeter/results/01_SA_CU_GetCPS.csv -d /home/ubuntu/mProj/target/jmeter -j /home/ubuntu/mProj/target/jmeter/logs/01_SA_CU_GetCPS.jmx.log -r -R 10.36.14.170
[info] Executing test: 01_SA_CU_GetCPS.jmx
[info] Created the tree successfully using /home/ubuntu/mProj/src/test/jmeter/01_SA_CU_GetCPS.jmx
[info] Configuring remote engine for 10.36.14.170
[info] Using remote object: UnicastRef [liveRef: [endpoint:[10.36.14.170:37913](remote),objID:[-10468c89:14fba100421:-7fff, -1854422229136130507]]]
[info] Starting remote engines
[info] Starting the test # Fri Sep 11 01:42:27 UTC 2015 (1441935747716)
[info] Remote engines have been started
[info] Waiting for possible shutdown message on port 4445
[info] Tidying up remote # Fri Sep 11 01:42:29 UTC 2015 (1441935749973)
[info] Completed Test: 01_SA_CU_GetCPS.jmx
[INFO]
[INFO] Test Results:
[INFO]
[INFO] Tests Run: 1, Failures: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 25.280s
[INFO] Finished at: Fri Sep 11 01:42:35 UTC 2015
[INFO] Final Memory: 11M/57M
[INFO] ------------------------------------------------------------------------
(The pom-file works well without the remoteConfig - in localhost)
(There's no networking issues any where and the remote server is able to access the host and works when servername, port, protocol is hardcoded in jmx files)
Is this a known limitation of the maven-jmeter plugin?
First use a recent version of jmeter-maven-plugin, 2.8.3 as of 15th january 2019.
To pass parameters, enter in pom.xml as child of configuration:
<propertiesJMeter>
<BUILD_TAG>${project.version}</BUILD_TAG>
<threads>7</threads>
<duration>30</duration>
</propertiesJMeter>
And in jmeter, to use threads for example, you would use __P function:
${__P(threads,5)
This blog explains the whole process.

ERROR [WsdlTestCase] Failed to create test step for [X]

I get this error ERROR [WsdlTestCase] Failed to create test step for [X] when executing my soapui project from Maven.
Tests work fine from the SOAPUI client software. My Soap-ui.error log is empty.
There doesn't seem to be enough information to let me debug this - I'm guessing there's some dependency I'm missing, but my tests are fairly simple (REST requests with a few assertions on the HTTP response). I assumed the core maven plugin would suffice.
My maven config is as below (I've also included the eviware repository -http://www.eviware.com/repository/maven2/)
<plugin>
<groupId>eviware</groupId>
<artifactId>maven-soapui-plugin</artifactId>
<version>2.0.2</version>
<executions>
<execution>
<phase>integration-test</phase>
<id>soapui-tests</id>
<configuration>
<projectFile>${basedir}/src/test/resources/MyTestSuite.xml</projectFile>
<outputFolder>${basedir}/target/soapui</outputFolder>
<junitReport>true</junitReport>
<exportwAll>true</exportwAll>
<printReport>true</printReport>
</configuration>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
the preceeding messages are :
[DefaultSoapUICore] Missing folder [/var/lib/jenkins/jobs/Build-Mule-Configuration/workspace/ext] for external libraries 2015-07-01 15:10:48,961 INFO
[DefaultSoapUICore] Creating new settings at [/var/lib/jenkins/jobs/Build-Mule-Configuration/workspace/soapui-settings.xml]
I've moved up to the 4.6.1 version of the soapui plugin as detailed here
(http://www.soapui.org/test-automation/maven/maven-2-x.html), the tests are now at least attempting to execute. As I understand it the version I've outlined above should work but perhaps it doesn't recognise the current SOAP UI project syntax.
As an aside the 4.6.1 version of the plugin seems to have a much larger number of dependancies and for me is causing memory issues.

Cannot invoke Tomcat manager w/Jenkins

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!!

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