You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by gigi <gg...@gmail.com> on 2013/07/30 16:23:01 UTC

odd behavior of maven surefire plugin

Hello, Maven gurus,

We run into something very bizarre when trying to run some unit tests 
that use a embedded jetty server with  surefire and cobertura. It works 
well with our original configuration like

<build>
         <pluginManagement>
             <plugins>
                 <plugin>
                     <groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
                     <configuration>
                         <skip>${maven.test.skip}</skip>
                         <check>
                             <branchRate>30</branchRate>
                             <lineRate>30</lineRate>
<haltOnFailure>true</haltOnFailure>
<totalBranchRate>55</totalBranchRate>
<totalLineRate>55</totalLineRate>
<packageLineRate>50</packageLineRate>
<packageBranchRate>50</packageBranchRate>
                         </check>
                     </configuration>
                     <executions>
                         <execution>
                             <goals>
                                 <goal>clean</goal>
                                 <goal>check</goal>
                             </goals>
                         </execution>
                     </executions>
                 </plugin>
             </plugins>
         </pluginManagement>
         <plugins>
             <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
                 <configuration>
                     <source>1.6</source>
                     <target>1.6</target>
                 </configuration>
             </plugin>
             <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
                 <configuration>
                     <warName>cxf</warName>
                 </configuration>
             </plugin>
             <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
                 <executions>
                     <execution>
                         <id>install</id>
                         <phase>install</phase>
                     </execution>
                 </executions>
             </plugin>
             <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
                 <configuration>
                     <argLine>-Xms512m -Xmx1024m 
-XX:MaxPermSize=512m</argLine>
<junitArtifactName>junit:junit</junitArtifactName>
                     <includes>
                         <include>**/*UnitTest*</include>
<include>**/*JettyTest*</include>
                     </includes>
                 </configuration>
             </plugin>
             <plugin>
                 <groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven-plugin</artifactId>
                 <version>2.0</version>
             </plugin>
         </plugins>
         <extensions>
             <extension>
<groupId>org.apache.maven.wagon</groupId>
                 <artifactId>wagon-ssh</artifactId>
                 <version>1.0-beta-6</version>
             </extension>
         </extensions>
     </build>


But when I tried to separate the running of UnitTest and JettyTest like 
the following, so UnitTest are run all the time and JettyTests are only 
run in a specific profile,

     <build>
         <pluginManagement>
             <plugins>
                 <!-- surefire stays here or it overrides the definition 
in profiles -->
                 <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
                     <configuration>
                         <argLine>-Xms512m -Xmx1024m 
-XX:MaxPermSize=512m</argLine>
<junitArtifactName>junit:junit</junitArtifactName>
                         <includes>
<include>**/*UnitTest*</include>
                         </includes>
                     </configuration>
                 </plugin>
             </plugins>
         </pluginManagement>
         <plugins>
             <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
                 <configuration>
                     <source>1.6</source>
                     <target>1.6</target>
                 </configuration>
             </plugin>
             <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
                 <configuration>
                     <warName>cxf</warName>
                 </configuration>
             </plugin>
             <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
                 <executions>
                     <execution>
                         <id>install</id>
                         <phase>install</phase>
                     </execution>
                 </executions>
             </plugin>
             <plugin>
                 <groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven-plugin</artifactId>
                 <version>2.0</version>
             </plugin>
         </plugins>
         <extensions>
             <extension>
<groupId>org.apache.maven.wagon</groupId>
                 <artifactId>wagon-ssh</artifactId>
                 <version>1.0-beta-6</version>
             </extension>
         </extensions>
     </build>

and get the JettyTest and Cobertura in a profile called all-test

<profiles>
         <profile>
             <id>all-test</id>
             <build>
                 <pluginManagement>
                     <plugins>
                         <plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
                             <configuration>
<skip>${maven.test.skip}</skip>
<check>
<branchRate>30</branchRate>
<lineRate>30</lineRate>
<haltOnFailure>true</haltOnFailure>
<totalBranchRate>55</totalBranchRate>
<totalLineRate>55</totalLineRate>
<packageLineRate>50</packageLineRate>
<packageBranchRate>50</packageBranchRate>
                                 </check>
                             </configuration>
                             <executions>
                                 <execution>
                                     <goals>
<goal>clean</goal>
<goal>check</goal>
                                     </goals>
                                 </execution>
                             </executions>
                         </plugin>
                     </plugins>
                 </pluginManagement>
                 <plugins>
                     <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
                             <configuration>
                                 <argLine>-Xms512m -Xmx1024m 
-XX:MaxPermSize=512m</argLine>
<junitArtifactName>junit:junit</junitArtifactName>
                                 <includes>
<include>**/*UnitTest*</include>
<include>**/*JettyTest*</include>
                                 </includes>
                             </configuration>
                         </plugin>
                 </plugins>
             </build>
         </profile>
     </profiles>

It runs fine in my centos 5.5 x86_64. But if I submit it to centos 5.7 
x86_64, jetty tests are giving me all kinds of errors, like the jetty 
server cannot be initiated right. Even worse, it only happens to some 
tests, some jetty tests would pass, and there is always a set of jetty 
tests fail. The failing set would vary each time. By looking at the 
failing logs, it looks like the jetty cannot be started because the port 
is used. Like the previous tests are not terminated well. But with the 
original configuration, jetty tests are OK. I'm so confused. Totally out 
of clues.

Can any one please give me some hint/insights? Anything would be deeply 
appreciated. I am so desparate :-(

Re: odd behavior of maven surefire plugin

Posted by gigi <gg...@gmail.com>.
I did check the availability of the port numbers. And also, it is not 
the same set of tests that are failing, given they use different port 
numbers

On 7/30/13 12:25 PM, Martin Gainty wrote:
> NIYF              (netstat is your friend)
>   
> NETSTAT [-a] [-b] [-e] [-f] [-n] [-o] [-p proto] [-r] [-s] [-t] [interval]
>    -a            Displays all connections and listening ports.
>    -b            Displays the executable involved in creating each connection or
>                  listening port. In some cases well-known executables host
>                  multiple independent components, and in these cases the
>                  sequence of components involved in creating the connection
>                  or listening port is displayed. In this case the executable
>                  name is in [] at the bottom, on top is the component it called,
>                  and so forth until TCP/IP was reached. Note that this option
>                  can be time-consuming and will fail unless you have sufficient
>                  permissions.
>    -e            Displays Ethernet statistics. This may be combined with the -s
>                  option.
>    -f            Displays Fully Qualified Domain Names (FQDN) for foreign
>                  addresses.
>    -n            Displays addresses and port numbers in numerical form.
>    -o            Displays the owning process ID associated with each connection.
>    -p proto      Shows connections for the protocol specified by proto; proto
>                  may be any of: TCP, UDP, TCPv6, or UDPv6.  If used with the -s
>                  option to display per-protocol statistics, proto may be any of:
>                  IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6.
>    -r            Displays the routing table.
>    -s            Displays per-protocol statistics.  By default, statistics are
>                  shown for IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, and UDPv6;
>                  the -p option may be used to specify a subset of the default.
>    -t            Displays the current connection offload state.
>    interval      Redisplays selected statistics, pausing interval seconds
>                  between each display.  Press CTRL+C to stop redisplaying
>                  statistics.  If omitted, netstat will print the current
>                  configuration information once.
>   
> before starting any process which requires exclusive use of any port  run netstat
>
> bash>netstat -an
>
> Martin
> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
>
>   
>> Date: Tue, 30 Jul 2013 12:07:34 -0400
>> From: ggtech888@gmail.com
>> To: mgainty@hotmail.com; users@maven.apache.org
>> Subject: Re: odd behavior of maven surefire plugin
>>
>> Sorry for sending the question twice. I thought it was not posted the
>> first time so I tried again.
>>
>> I think I figured out why it is failing. As we have surefire and
>> cobertura both and it is a well known issue that the tests will be run
>> twice, the jetty tests are OK the first time with surefire but failed
>> with cobertura as jetty from first run are not terminated yet/correctly.
>> But I'm still confused why it works with the original configuration
>> :-(   Can anyone please give me some hints? Unfortunately, we cannot do
>> very much with the centos 5.7 server. it is our building env and would
>> take more power than I have to change anything there
>>
>> Here are the error msgs
>>
>>
>> 10:01:01,226 ERROR JettyHTTPServerEngine - Could not start Jetty server
>> on port 7,789: Address already in use
>> 10:01:01,280 ERROR TestContextManager - Caught exception while allowing
>> TestExecutionListener
>> [org.springframework.test.context.support.DependencyInjectionTestExecutionListener@801b120]
>> to prepare test instance [com.myapp.services.JettyTest@2713affb]
>> java.lang.IllegalStateException: Failed to load ApplicationContext
>>       at
>> org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:157)
>>       at
>> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109)
>>       at
>> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75)
>>       at
>> org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:321)
>>       at
>> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:211)
>>       at
>> org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:288)
>>       at
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>>       at
>> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:290)
>>       at
>> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
>>       at
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>>       at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>>       at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>>       at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>>       at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>>       at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>>       at
>> org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
>>       at
>> org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
>>       at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>>       at
>> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
>>       at
>> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
>>       at
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115)
>>       at
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
>>       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.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
>>       at com.sun.proxy.$Proxy0.invoke(Unknown Source)
>>       at
>> org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
>>       at
>> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
>>       at
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
>> Caused by: org.springframework.beans.factory.BeanCreationException:
>> Error creating bean with name 'restServer': Invocation of init method
>> failed; nested exception is
>> org.apache.cxf.service.factory.ServiceConstructionException
>>       at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1455)
>>       at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
>>       at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
>>       at
>> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
>>       at
>> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
>>       at
>> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
>>       at
>> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
>>       at
>> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)
>>       at
>> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:913)
>>       at
>> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:464)
>>       at
>> org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:103)
>>       at
>> org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:1)
>>       at
>> org.springframework.test.context.support.DelegatingSmartContextLoader.loadContext(DelegatingSmartContextLoader.java:228)
>>       at
>> org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:124)
>>       at
>> org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:148)
>>       ... 30 more
>> Caused by: org.apache.cxf.service.factory.ServiceConstructionException
>>       at
>> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:194)
>>       at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
>>       at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>       at java.lang.reflect.Method.invoke(Method.java:597)
>>       at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1581)
>>       at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1522)
>>       at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
>>       ... 44 more
>> Caused by: org.apache.cxf.interceptor.Fault: Could not start Jetty
>> server on port 7,789: Address already in use
>>       at
>> org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.addServant(JettyHTTPServerEngine.java:383)
>>       at
>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.activate(JettyHTTPDestination.java:171)
>>       at
>> org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:48)
>>       at
>> org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:97)
>>       at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131)
>>       at
>> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:185)
>>       ... 50 more
>> Caused by: java.net.BindException: Address already in use
>>       at sun.nio.ch.Net.bind(Native Method)
>>       at
>> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:124)
>>       at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
>>       at
>> org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:172)
>>       at
>> org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:300)
>>       at
>> org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:249)
>>       at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
>>       at org.eclipse.jetty.server.Server.doStart(Server.java:272)
>>       at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
>>       at
>> org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.addServant(JettyHTTPServerEngine.java:372)
>>       ... 55 more
>> 10:01:01,346 ERROR JettyHTTPServerEngine - Could not start Jetty server
>> on port 7,789
>> ....
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 7/30/13 11:10 AM, Martin Gainty wrote:
>>> since centos 5.5 works and  centos 5.7 doesn't work the culprit is either
>>>
>>> 1a)centos 5.7 64bit Operating System was not installed and or
>>> configured property
>>>
>>> 1b)OR 64 bit JDK for 5.7 centos was not installed and or configured
>>> properly
>>>
>>> 1)Get centos 5.7 64bit OS setup correctly
>>>
>>> http://www.howtoforge.com/perfect-server-centos-5.7-x86_64-ispconfig-2
>>>
>>> 2)download 64bit JDK from (note oracle supports 32 and 64 bit binaries for windows, solaris and Linux)  so centos binaries will be necessary
>>> http://mirror.centos.org/centos/5/os/x86_64/CentOS/
>>> 3)verify JDK works correctly before testing any app that platforms on JDK
>>>
>>> once these 2 critical steps have been completed and tested ..feel free to ping list for 'maven specific installation' issues
>>>
>>> Martin-
>>>
>>>
>>>> Date: Tue, 30 Jul 2013 10:23:01 -0400
>>>> From: ggtech888@gmail.com
>>>> To: users@maven.apache.org
>>>> Subject: odd behavior of maven surefire plugin
>>>>
>>>> Hello, Maven gurus,
>>>>
>>>> We run into something very bizarre when trying to run some unit tests
>>>> that use a embedded jetty server with surefire and cobertura. It works
>>>> well with our original configuration like
>>>>
>>>> <build>
>>>> <pluginManagement>
>>>> <plugins>
>>>> <plugin>
>>>> <groupId>org.codehaus.mojo</groupId>
>>>> <artifactId>cobertura-maven-plugin</artifactId>
>>>> <configuration>
>>>> <skip>${maven.test.skip}</skip>
>>>> <check>
>>>> <branchRate>30</branchRate>
>>>> <lineRate>30</lineRate>
>>>> <haltOnFailure>true</haltOnFailure>
>>>> <totalBranchRate>55</totalBranchRate>
>>>> <totalLineRate>55</totalLineRate>
>>>> <packageLineRate>50</packageLineRate>
>>>> <packageBranchRate>50</packageBranchRate>
>>>> </check>
>>>> </configuration>
>>>> <executions>
>>>> <execution>
>>>> <goals>
>>>> <goal>clean</goal>
>>>> <goal>check</goal>
>>>> </goals>
>>>> </execution>
>>>> </executions>
>>>> </plugin>
>>>> </plugins>
>>>> </pluginManagement>
>>>> <plugins>
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>> <configuration>
>>>> <source>1.6</source>
>>>> <target>1.6</target>
>>>> </configuration>
>>>> </plugin>
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-war-plugin</artifactId>
>>>> <configuration>
>>>> <warName>cxf</warName>
>>>> </configuration>
>>>> </plugin>
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-dependency-plugin</artifactId>
>>>> <executions>
>>>> <execution>
>>>> <id>install</id>
>>>> <phase>install</phase>
>>>> </execution>
>>>> </executions>
>>>> </plugin>
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-surefire-plugin</artifactId>
>>>> <configuration>
>>>> <argLine>-Xms512m -Xmx1024m
>>>> -XX:MaxPermSize=512m</argLine>
>>>> <junitArtifactName>junit:junit</junitArtifactName>
>>>> <includes>
>>>> <include>**/*UnitTest*</include>
>>>> <include>**/*JettyTest*</include>
>>>> </includes>
>>>> </configuration>
>>>> </plugin>
>>>> <plugin>
>>>> <groupId>org.codehaus.mojo</groupId>
>>>> <artifactId>sonar-maven-plugin</artifactId>
>>>> <version>2.0</version>
>>>> </plugin>
>>>> </plugins>
>>>> <extensions>
>>>> <extension>
>>>> <groupId>org.apache.maven.wagon</groupId>
>>>> <artifactId>wagon-ssh</artifactId>
>>>> <version>1.0-beta-6</version>
>>>> </extension>
>>>> </extensions>
>>>> </build>
>>>>
>>>>
>>>> But when I tried to separate the running of UnitTest and JettyTest like
>>>> the following, so UnitTest are run all the time and JettyTests are only
>>>> run in a specific profile,
>>>>
>>>> <build>
>>>> <pluginManagement>
>>>> <plugins>
>>>> <!-- surefire stays here or it overrides the definition
>>>> in profiles -->
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-surefire-plugin</artifactId>
>>>> <configuration>
>>>> <argLine>-Xms512m -Xmx1024m
>>>> -XX:MaxPermSize=512m</argLine>
>>>> <junitArtifactName>junit:junit</junitArtifactName>
>>>> <includes>
>>>> <include>**/*UnitTest*</include>
>>>> </includes>
>>>> </configuration>
>>>> </plugin>
>>>> </plugins>
>>>> </pluginManagement>
>>>> <plugins>
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>> <configuration>
>>>> <source>1.6</source>
>>>> <target>1.6</target>
>>>> </configuration>
>>>> </plugin>
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-war-plugin</artifactId>
>>>> <configuration>
>>>> <warName>cxf</warName>
>>>> </configuration>
>>>> </plugin>
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-dependency-plugin</artifactId>
>>>> <executions>
>>>> <execution>
>>>> <id>install</id>
>>>> <phase>install</phase>
>>>> </execution>
>>>> </executions>
>>>> </plugin>
>>>> <plugin>
>>>> <groupId>org.codehaus.mojo</groupId>
>>>> <artifactId>sonar-maven-plugin</artifactId>
>>>> <version>2.0</version>
>>>> </plugin>
>>>> </plugins>
>>>> <extensions>
>>>> <extension>
>>>> <groupId>org.apache.maven.wagon</groupId>
>>>> <artifactId>wagon-ssh</artifactId>
>>>> <version>1.0-beta-6</version>
>>>> </extension>
>>>> </extensions>
>>>> </build>
>>>>
>>>> and get the JettyTest and Cobertura in a profile called all-test
>>>>
>>>> <profiles>
>>>> <profile>
>>>> <id>all-test</id>
>>>> <build>
>>>> <pluginManagement>
>>>> <plugins>
>>>> <plugin>
>>>> <groupId>org.codehaus.mojo</groupId>
>>>> <artifactId>cobertura-maven-plugin</artifactId>
>>>> <configuration>
>>>> <skip>${maven.test.skip}</skip>
>>>> <check>
>>>> <branchRate>30</branchRate>
>>>> <lineRate>30</lineRate>
>>>> <haltOnFailure>true</haltOnFailure>
>>>> <totalBranchRate>55</totalBranchRate>
>>>> <totalLineRate>55</totalLineRate>
>>>> <packageLineRate>50</packageLineRate>
>>>> <packageBranchRate>50</packageBranchRate>
>>>> </check>
>>>> </configuration>
>>>> <executions>
>>>> <execution>
>>>> <goals>
>>>> <goal>clean</goal>
>>>> <goal>check</goal>
>>>> </goals>
>>>> </execution>
>>>> </executions>
>>>> </plugin>
>>>> </plugins>
>>>> </pluginManagement>
>>>> <plugins>
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-surefire-plugin</artifactId>
>>>> <configuration>
>>>> <argLine>-Xms512m -Xmx1024m
>>>> -XX:MaxPermSize=512m</argLine>
>>>> <junitArtifactName>junit:junit</junitArtifactName>
>>>> <includes>
>>>> <include>**/*UnitTest*</include>
>>>> <include>**/*JettyTest*</include>
>>>> </includes>
>>>> </configuration>
>>>> </plugin>
>>>> </plugins>
>>>> </build>
>>>> </profile>
>>>> </profiles>
>>>>
>>>> It runs fine in my centos 5.5 x86_64. But if I submit it to centos 5.7
>>>> x86_64, jetty tests are giving me all kinds of errors, like the jetty
>>>> server cannot be initiated right. Even worse, it only happens to some
>>>> tests, some jetty tests would pass, and there is always a set of jetty
>>>> tests fail. The failing set would vary each time. By looking at the
>>>> failing logs, it looks like the jetty cannot be started because the
>>> port
>>>> is used. Like the previous tests are not terminated well. But with the
>>>> original configuration, jetty tests are OK. I'm so confused. Totally
>>> out
>>>> of clues.
>>>>
>>>> Can any one please give me some hint/insights? Anything would be deeply
>>>> appreciated. I am so desparate :-(
>   		 	   		


RE: odd behavior of maven surefire plugin

Posted by Martin Gainty <mg...@hotmail.com>.
NIYF              (netstat is your friend)
 
NETSTAT [-a] [-b] [-e] [-f] [-n] [-o] [-p proto] [-r] [-s] [-t] [interval]
  -a            Displays all connections and listening ports.
  -b            Displays the executable involved in creating each connection or
                listening port. In some cases well-known executables host
                multiple independent components, and in these cases the
                sequence of components involved in creating the connection
                or listening port is displayed. In this case the executable
                name is in [] at the bottom, on top is the component it called,
                and so forth until TCP/IP was reached. Note that this option
                can be time-consuming and will fail unless you have sufficient
                permissions.
  -e            Displays Ethernet statistics. This may be combined with the -s
                option.
  -f            Displays Fully Qualified Domain Names (FQDN) for foreign
                addresses.
  -n            Displays addresses and port numbers in numerical form.
  -o            Displays the owning process ID associated with each connection.
  -p proto      Shows connections for the protocol specified by proto; proto
                may be any of: TCP, UDP, TCPv6, or UDPv6.  If used with the -s
                option to display per-protocol statistics, proto may be any of:
                IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6.
  -r            Displays the routing table.
  -s            Displays per-protocol statistics.  By default, statistics are
                shown for IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, and UDPv6;
                the -p option may be used to specify a subset of the default.
  -t            Displays the current connection offload state.
  interval      Redisplays selected statistics, pausing interval seconds
                between each display.  Press CTRL+C to stop redisplaying
                statistics.  If omitted, netstat will print the current
                configuration information once.
 
before starting any process which requires exclusive use of any port  run netstat

bash>netstat -an 

Martin 
______________________________________________ 
Verzicht und Vertraulichkeitanmerkung

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.

 
> Date: Tue, 30 Jul 2013 12:07:34 -0400
> From: ggtech888@gmail.com
> To: mgainty@hotmail.com; users@maven.apache.org
> Subject: Re: odd behavior of maven surefire plugin
> 
> Sorry for sending the question twice. I thought it was not posted the 
> first time so I tried again.
> 
> I think I figured out why it is failing. As we have surefire and 
> cobertura both and it is a well known issue that the tests will be run 
> twice, the jetty tests are OK the first time with surefire but failed 
> with cobertura as jetty from first run are not terminated yet/correctly. 
> But I'm still confused why it works with the original configuration 
> :-(   Can anyone please give me some hints? Unfortunately, we cannot do 
> very much with the centos 5.7 server. it is our building env and would 
> take more power than I have to change anything there
> 
> Here are the error msgs
> 
> 
> 10:01:01,226 ERROR JettyHTTPServerEngine - Could not start Jetty server 
> on port 7,789: Address already in use
> 10:01:01,280 ERROR TestContextManager - Caught exception while allowing 
> TestExecutionListener 
> [org.springframework.test.context.support.DependencyInjectionTestExecutionListener@801b120] 
> to prepare test instance [com.myapp.services.JettyTest@2713affb]
> java.lang.IllegalStateException: Failed to load ApplicationContext
>      at 
> org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:157)
>      at 
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109)
>      at 
> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75)
>      at 
> org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:321)
>      at 
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:211)
>      at 
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:288)
>      at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>      at 
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:290)
>      at 
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
>      at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>      at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>      at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>      at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>      at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>      at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>      at 
> org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
>      at 
> org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
>      at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>      at 
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
>      at 
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
>      at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115)
>      at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
>      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.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
>      at com.sun.proxy.$Proxy0.invoke(Unknown Source)
>      at 
> org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
>      at 
> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
>      at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
> Caused by: org.springframework.beans.factory.BeanCreationException: 
> Error creating bean with name 'restServer': Invocation of init method 
> failed; nested exception is 
> org.apache.cxf.service.factory.ServiceConstructionException
>      at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1455)
>      at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
>      at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
>      at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
>      at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
>      at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
>      at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
>      at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)
>      at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:913)
>      at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:464)
>      at 
> org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:103)
>      at 
> org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:1)
>      at 
> org.springframework.test.context.support.DelegatingSmartContextLoader.loadContext(DelegatingSmartContextLoader.java:228)
>      at 
> org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:124)
>      at 
> org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:148)
>      ... 30 more
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException
>      at 
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:194)
>      at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
>      at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1581)
>      at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1522)
>      at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
>      ... 44 more
> Caused by: org.apache.cxf.interceptor.Fault: Could not start Jetty 
> server on port 7,789: Address already in use
>      at 
> org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.addServant(JettyHTTPServerEngine.java:383)
>      at 
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.activate(JettyHTTPDestination.java:171)
>      at 
> org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:48)
>      at 
> org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:97)
>      at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131)
>      at 
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:185)
>      ... 50 more
> Caused by: java.net.BindException: Address already in use
>      at sun.nio.ch.Net.bind(Native Method)
>      at 
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:124)
>      at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
>      at 
> org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:172)
>      at 
> org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:300)
>      at 
> org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:249)
>      at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
>      at org.eclipse.jetty.server.Server.doStart(Server.java:272)
>      at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
>      at 
> org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.addServant(JettyHTTPServerEngine.java:372)
>      ... 55 more
> 10:01:01,346 ERROR JettyHTTPServerEngine - Could not start Jetty server 
> on port 7,789
> ....
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 7/30/13 11:10 AM, Martin Gainty wrote:
> > since centos 5.5 works and  centos 5.7 doesn't work the culprit is either
> >
> > 1a)centos 5.7 64bit Operating System was not installed and or 
> > configured property
> >
> > 1b)OR 64 bit JDK for 5.7 centos was not installed and or configured 
> > properly
> >
> > 1)Get centos 5.7 64bit OS setup correctly
> >
> > http://www.howtoforge.com/perfect-server-centos-5.7-x86_64-ispconfig-2
> >
> > 2)download 64bit JDK from (note oracle supports 32 and 64 bit binaries for windows, solaris and Linux)  so centos binaries will be necessary
> > http://mirror.centos.org/centos/5/os/x86_64/CentOS/
> > 3)verify JDK works correctly before testing any app that platforms on JDK
> >
> > once these 2 critical steps have been completed and tested ..feel free to ping list for 'maven specific installation' issues
> >
> > Martin-
> >
> >
> > > Date: Tue, 30 Jul 2013 10:23:01 -0400
> > > From: ggtech888@gmail.com
> > > To: users@maven.apache.org
> > > Subject: odd behavior of maven surefire plugin
> > >
> > > Hello, Maven gurus,
> > >
> > > We run into something very bizarre when trying to run some unit tests
> > > that use a embedded jetty server with surefire and cobertura. It works
> > > well with our original configuration like
> > >
> > > <build>
> > > <pluginManagement>
> > > <plugins>
> > > <plugin>
> > > <groupId>org.codehaus.mojo</groupId>
> > > <artifactId>cobertura-maven-plugin</artifactId>
> > > <configuration>
> > > <skip>${maven.test.skip}</skip>
> > > <check>
> > > <branchRate>30</branchRate>
> > > <lineRate>30</lineRate>
> > > <haltOnFailure>true</haltOnFailure>
> > > <totalBranchRate>55</totalBranchRate>
> > > <totalLineRate>55</totalLineRate>
> > > <packageLineRate>50</packageLineRate>
> > > <packageBranchRate>50</packageBranchRate>
> > > </check>
> > > </configuration>
> > > <executions>
> > > <execution>
> > > <goals>
> > > <goal>clean</goal>
> > > <goal>check</goal>
> > > </goals>
> > > </execution>
> > > </executions>
> > > </plugin>
> > > </plugins>
> > > </pluginManagement>
> > > <plugins>
> > > <plugin>
> > > <groupId>org.apache.maven.plugins</groupId>
> > > <artifactId>maven-compiler-plugin</artifactId>
> > > <configuration>
> > > <source>1.6</source>
> > > <target>1.6</target>
> > > </configuration>
> > > </plugin>
> > > <plugin>
> > > <groupId>org.apache.maven.plugins</groupId>
> > > <artifactId>maven-war-plugin</artifactId>
> > > <configuration>
> > > <warName>cxf</warName>
> > > </configuration>
> > > </plugin>
> > > <plugin>
> > > <groupId>org.apache.maven.plugins</groupId>
> > > <artifactId>maven-dependency-plugin</artifactId>
> > > <executions>
> > > <execution>
> > > <id>install</id>
> > > <phase>install</phase>
> > > </execution>
> > > </executions>
> > > </plugin>
> > > <plugin>
> > > <groupId>org.apache.maven.plugins</groupId>
> > > <artifactId>maven-surefire-plugin</artifactId>
> > > <configuration>
> > > <argLine>-Xms512m -Xmx1024m
> > > -XX:MaxPermSize=512m</argLine>
> > > <junitArtifactName>junit:junit</junitArtifactName>
> > > <includes>
> > > <include>**/*UnitTest*</include>
> > > <include>**/*JettyTest*</include>
> > > </includes>
> > > </configuration>
> > > </plugin>
> > > <plugin>
> > > <groupId>org.codehaus.mojo</groupId>
> > > <artifactId>sonar-maven-plugin</artifactId>
> > > <version>2.0</version>
> > > </plugin>
> > > </plugins>
> > > <extensions>
> > > <extension>
> > > <groupId>org.apache.maven.wagon</groupId>
> > > <artifactId>wagon-ssh</artifactId>
> > > <version>1.0-beta-6</version>
> > > </extension>
> > > </extensions>
> > > </build>
> > >
> > >
> > > But when I tried to separate the running of UnitTest and JettyTest like
> > > the following, so UnitTest are run all the time and JettyTests are only
> > > run in a specific profile,
> > >
> > > <build>
> > > <pluginManagement>
> > > <plugins>
> > > <!-- surefire stays here or it overrides the definition
> > > in profiles -->
> > > <plugin>
> > > <groupId>org.apache.maven.plugins</groupId>
> > > <artifactId>maven-surefire-plugin</artifactId>
> > > <configuration>
> > > <argLine>-Xms512m -Xmx1024m
> > > -XX:MaxPermSize=512m</argLine>
> > > <junitArtifactName>junit:junit</junitArtifactName>
> > > <includes>
> > > <include>**/*UnitTest*</include>
> > > </includes>
> > > </configuration>
> > > </plugin>
> > > </plugins>
> > > </pluginManagement>
> > > <plugins>
> > > <plugin>
> > > <groupId>org.apache.maven.plugins</groupId>
> > > <artifactId>maven-compiler-plugin</artifactId>
> > > <configuration>
> > > <source>1.6</source>
> > > <target>1.6</target>
> > > </configuration>
> > > </plugin>
> > > <plugin>
> > > <groupId>org.apache.maven.plugins</groupId>
> > > <artifactId>maven-war-plugin</artifactId>
> > > <configuration>
> > > <warName>cxf</warName>
> > > </configuration>
> > > </plugin>
> > > <plugin>
> > > <groupId>org.apache.maven.plugins</groupId>
> > > <artifactId>maven-dependency-plugin</artifactId>
> > > <executions>
> > > <execution>
> > > <id>install</id>
> > > <phase>install</phase>
> > > </execution>
> > > </executions>
> > > </plugin>
> > > <plugin>
> > > <groupId>org.codehaus.mojo</groupId>
> > > <artifactId>sonar-maven-plugin</artifactId>
> > > <version>2.0</version>
> > > </plugin>
> > > </plugins>
> > > <extensions>
> > > <extension>
> > > <groupId>org.apache.maven.wagon</groupId>
> > > <artifactId>wagon-ssh</artifactId>
> > > <version>1.0-beta-6</version>
> > > </extension>
> > > </extensions>
> > > </build>
> > >
> > > and get the JettyTest and Cobertura in a profile called all-test
> > >
> > > <profiles>
> > > <profile>
> > > <id>all-test</id>
> > > <build>
> > > <pluginManagement>
> > > <plugins>
> > > <plugin>
> > > <groupId>org.codehaus.mojo</groupId>
> > > <artifactId>cobertura-maven-plugin</artifactId>
> > > <configuration>
> > > <skip>${maven.test.skip}</skip>
> > > <check>
> > > <branchRate>30</branchRate>
> > > <lineRate>30</lineRate>
> > > <haltOnFailure>true</haltOnFailure>
> > > <totalBranchRate>55</totalBranchRate>
> > > <totalLineRate>55</totalLineRate>
> > > <packageLineRate>50</packageLineRate>
> > > <packageBranchRate>50</packageBranchRate>
> > > </check>
> > > </configuration>
> > > <executions>
> > > <execution>
> > > <goals>
> > > <goal>clean</goal>
> > > <goal>check</goal>
> > > </goals>
> > > </execution>
> > > </executions>
> > > </plugin>
> > > </plugins>
> > > </pluginManagement>
> > > <plugins>
> > > <plugin>
> > > <groupId>org.apache.maven.plugins</groupId>
> > > <artifactId>maven-surefire-plugin</artifactId>
> > > <configuration>
> > > <argLine>-Xms512m -Xmx1024m
> > > -XX:MaxPermSize=512m</argLine>
> > > <junitArtifactName>junit:junit</junitArtifactName>
> > > <includes>
> > > <include>**/*UnitTest*</include>
> > > <include>**/*JettyTest*</include>
> > > </includes>
> > > </configuration>
> > > </plugin>
> > > </plugins>
> > > </build>
> > > </profile>
> > > </profiles>
> > >
> > > It runs fine in my centos 5.5 x86_64. But if I submit it to centos 5.7
> > > x86_64, jetty tests are giving me all kinds of errors, like the jetty
> > > server cannot be initiated right. Even worse, it only happens to some
> > > tests, some jetty tests would pass, and there is always a set of jetty
> > > tests fail. The failing set would vary each time. By looking at the
> > > failing logs, it looks like the jetty cannot be started because the 
> > port
> > > is used. Like the previous tests are not terminated well. But with the
> > > original configuration, jetty tests are OK. I'm so confused. Totally 
> > out
> > > of clues.
> > >
> > > Can any one please give me some hint/insights? Anything would be deeply
> > > appreciated. I am so desparate :-(
> 
 		 	   		  

Re: odd behavior of maven surefire plugin

Posted by gigi <gg...@gmail.com>.
Sorry for sending the question twice. I thought it was not posted the 
first time so I tried again.

I think I figured out why it is failing. As we have surefire and 
cobertura both and it is a well known issue that the tests will be run 
twice, the jetty tests are OK the first time with surefire but failed 
with cobertura as jetty from first run are not terminated yet/correctly. 
But I'm still confused why it works with the original configuration 
:-(   Can anyone please give me some hints? Unfortunately, we cannot do 
very much with the centos 5.7 server. it is our building env and would 
take more power than I have to change anything there

Here are the error msgs


10:01:01,226 ERROR JettyHTTPServerEngine - Could not start Jetty server 
on port 7,789: Address already in use
10:01:01,280 ERROR TestContextManager - Caught exception while allowing 
TestExecutionListener 
[org.springframework.test.context.support.DependencyInjectionTestExecutionListener@801b120] 
to prepare test instance [com.myapp.services.JettyTest@2713affb]
java.lang.IllegalStateException: Failed to load ApplicationContext
     at 
org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:157)
     at 
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109)
     at 
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75)
     at 
org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:321)
     at 
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:211)
     at 
org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:288)
     at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
     at 
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:290)
     at 
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
     at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
     at 
org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
     at 
org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
     at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
     at 
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
     at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
     at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115)
     at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
     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.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
     at com.sun.proxy.$Proxy0.invoke(Unknown Source)
     at 
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
     at 
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
     at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
Caused by: org.springframework.beans.factory.BeanCreationException: 
Error creating bean with name 'restServer': Invocation of init method 
failed; nested exception is 
org.apache.cxf.service.factory.ServiceConstructionException
     at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1455)
     at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
     at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
     at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
     at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
     at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
     at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
     at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)
     at 
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:913)
     at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:464)
     at 
org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:103)
     at 
org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:1)
     at 
org.springframework.test.context.support.DelegatingSmartContextLoader.loadContext(DelegatingSmartContextLoader.java:228)
     at 
org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:124)
     at 
org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:148)
     ... 30 more
Caused by: org.apache.cxf.service.factory.ServiceConstructionException
     at 
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:194)
     at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
     at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1581)
     at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1522)
     at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
     ... 44 more
Caused by: org.apache.cxf.interceptor.Fault: Could not start Jetty 
server on port 7,789: Address already in use
     at 
org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.addServant(JettyHTTPServerEngine.java:383)
     at 
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.activate(JettyHTTPDestination.java:171)
     at 
org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:48)
     at 
org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:97)
     at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131)
     at 
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:185)
     ... 50 more
Caused by: java.net.BindException: Address already in use
     at sun.nio.ch.Net.bind(Native Method)
     at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:124)
     at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
     at 
org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:172)
     at 
org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:300)
     at 
org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:249)
     at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
     at org.eclipse.jetty.server.Server.doStart(Server.java:272)
     at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59)
     at 
org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.addServant(JettyHTTPServerEngine.java:372)
     ... 55 more
10:01:01,346 ERROR JettyHTTPServerEngine - Could not start Jetty server 
on port 7,789
....











On 7/30/13 11:10 AM, Martin Gainty wrote:
> since centos 5.5 works and  centos 5.7 doesn't work the culprit is either
>
> 1a)centos 5.7 64bit Operating System was not installed and or 
> configured property
>
> 1b)OR 64 bit JDK for 5.7 centos was not installed and or configured 
> properly
>
> 1)Get centos 5.7 64bit OS setup correctly
>
> http://www.howtoforge.com/perfect-server-centos-5.7-x86_64-ispconfig-2
>
> 2)download 64bit JDK from (note oracle supports 32 and 64 bit binaries for windows, solaris and Linux)  so centos binaries will be necessary
> http://mirror.centos.org/centos/5/os/x86_64/CentOS/
> 3)verify JDK works correctly before testing any app that platforms on JDK
>
> once these 2 critical steps have been completed and tested ..feel free to ping list for 'maven specific installation' issues
>
> Martin-
>
>
> > Date: Tue, 30 Jul 2013 10:23:01 -0400
> > From: ggtech888@gmail.com
> > To: users@maven.apache.org
> > Subject: odd behavior of maven surefire plugin
> >
> > Hello, Maven gurus,
> >
> > We run into something very bizarre when trying to run some unit tests
> > that use a embedded jetty server with surefire and cobertura. It works
> > well with our original configuration like
> >
> > <build>
> > <pluginManagement>
> > <plugins>
> > <plugin>
> > <groupId>org.codehaus.mojo</groupId>
> > <artifactId>cobertura-maven-plugin</artifactId>
> > <configuration>
> > <skip>${maven.test.skip}</skip>
> > <check>
> > <branchRate>30</branchRate>
> > <lineRate>30</lineRate>
> > <haltOnFailure>true</haltOnFailure>
> > <totalBranchRate>55</totalBranchRate>
> > <totalLineRate>55</totalLineRate>
> > <packageLineRate>50</packageLineRate>
> > <packageBranchRate>50</packageBranchRate>
> > </check>
> > </configuration>
> > <executions>
> > <execution>
> > <goals>
> > <goal>clean</goal>
> > <goal>check</goal>
> > </goals>
> > </execution>
> > </executions>
> > </plugin>
> > </plugins>
> > </pluginManagement>
> > <plugins>
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-compiler-plugin</artifactId>
> > <configuration>
> > <source>1.6</source>
> > <target>1.6</target>
> > </configuration>
> > </plugin>
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-war-plugin</artifactId>
> > <configuration>
> > <warName>cxf</warName>
> > </configuration>
> > </plugin>
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-dependency-plugin</artifactId>
> > <executions>
> > <execution>
> > <id>install</id>
> > <phase>install</phase>
> > </execution>
> > </executions>
> > </plugin>
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-surefire-plugin</artifactId>
> > <configuration>
> > <argLine>-Xms512m -Xmx1024m
> > -XX:MaxPermSize=512m</argLine>
> > <junitArtifactName>junit:junit</junitArtifactName>
> > <includes>
> > <include>**/*UnitTest*</include>
> > <include>**/*JettyTest*</include>
> > </includes>
> > </configuration>
> > </plugin>
> > <plugin>
> > <groupId>org.codehaus.mojo</groupId>
> > <artifactId>sonar-maven-plugin</artifactId>
> > <version>2.0</version>
> > </plugin>
> > </plugins>
> > <extensions>
> > <extension>
> > <groupId>org.apache.maven.wagon</groupId>
> > <artifactId>wagon-ssh</artifactId>
> > <version>1.0-beta-6</version>
> > </extension>
> > </extensions>
> > </build>
> >
> >
> > But when I tried to separate the running of UnitTest and JettyTest like
> > the following, so UnitTest are run all the time and JettyTests are only
> > run in a specific profile,
> >
> > <build>
> > <pluginManagement>
> > <plugins>
> > <!-- surefire stays here or it overrides the definition
> > in profiles -->
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-surefire-plugin</artifactId>
> > <configuration>
> > <argLine>-Xms512m -Xmx1024m
> > -XX:MaxPermSize=512m</argLine>
> > <junitArtifactName>junit:junit</junitArtifactName>
> > <includes>
> > <include>**/*UnitTest*</include>
> > </includes>
> > </configuration>
> > </plugin>
> > </plugins>
> > </pluginManagement>
> > <plugins>
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-compiler-plugin</artifactId>
> > <configuration>
> > <source>1.6</source>
> > <target>1.6</target>
> > </configuration>
> > </plugin>
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-war-plugin</artifactId>
> > <configuration>
> > <warName>cxf</warName>
> > </configuration>
> > </plugin>
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-dependency-plugin</artifactId>
> > <executions>
> > <execution>
> > <id>install</id>
> > <phase>install</phase>
> > </execution>
> > </executions>
> > </plugin>
> > <plugin>
> > <groupId>org.codehaus.mojo</groupId>
> > <artifactId>sonar-maven-plugin</artifactId>
> > <version>2.0</version>
> > </plugin>
> > </plugins>
> > <extensions>
> > <extension>
> > <groupId>org.apache.maven.wagon</groupId>
> > <artifactId>wagon-ssh</artifactId>
> > <version>1.0-beta-6</version>
> > </extension>
> > </extensions>
> > </build>
> >
> > and get the JettyTest and Cobertura in a profile called all-test
> >
> > <profiles>
> > <profile>
> > <id>all-test</id>
> > <build>
> > <pluginManagement>
> > <plugins>
> > <plugin>
> > <groupId>org.codehaus.mojo</groupId>
> > <artifactId>cobertura-maven-plugin</artifactId>
> > <configuration>
> > <skip>${maven.test.skip}</skip>
> > <check>
> > <branchRate>30</branchRate>
> > <lineRate>30</lineRate>
> > <haltOnFailure>true</haltOnFailure>
> > <totalBranchRate>55</totalBranchRate>
> > <totalLineRate>55</totalLineRate>
> > <packageLineRate>50</packageLineRate>
> > <packageBranchRate>50</packageBranchRate>
> > </check>
> > </configuration>
> > <executions>
> > <execution>
> > <goals>
> > <goal>clean</goal>
> > <goal>check</goal>
> > </goals>
> > </execution>
> > </executions>
> > </plugin>
> > </plugins>
> > </pluginManagement>
> > <plugins>
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-surefire-plugin</artifactId>
> > <configuration>
> > <argLine>-Xms512m -Xmx1024m
> > -XX:MaxPermSize=512m</argLine>
> > <junitArtifactName>junit:junit</junitArtifactName>
> > <includes>
> > <include>**/*UnitTest*</include>
> > <include>**/*JettyTest*</include>
> > </includes>
> > </configuration>
> > </plugin>
> > </plugins>
> > </build>
> > </profile>
> > </profiles>
> >
> > It runs fine in my centos 5.5 x86_64. But if I submit it to centos 5.7
> > x86_64, jetty tests are giving me all kinds of errors, like the jetty
> > server cannot be initiated right. Even worse, it only happens to some
> > tests, some jetty tests would pass, and there is always a set of jetty
> > tests fail. The failing set would vary each time. By looking at the
> > failing logs, it looks like the jetty cannot be started because the 
> port
> > is used. Like the previous tests are not terminated well. But with the
> > original configuration, jetty tests are OK. I'm so confused. Totally 
> out
> > of clues.
> >
> > Can any one please give me some hint/insights? Anything would be deeply
> > appreciated. I am so desparate :-(