i am trying to run the maven-exec plugin with referring the jar file as classpath like this
<configuration>
<executable>java</executable>
<longClasspath>true</longClasspath>
<commandlineArgs>-classpath jarfile; Sample
</commandlineArgs>
</configuration>
but my classpath is not set properly thus thrown an classNotFoundException. How to configure this?
Your classpath shouldn't end with a semicolon. Just -classpath jarfile Sample, assuming that "Sample" is the name of the class you're trying to run. I'd also eliminate the newline at the end of that command line string to be safe.
Related
I've mobile automation test cases written in Selenium, Appium & TestNG.
Invoking test cases works fine when run from eclipse, but when I run the batch script by invoking testng.xml test fails as it's failing to find object property file.
And fails with following error stack
java.lang.NoSuchMethodError: com.google.common.collect.ImmutableSet.toImmutableSet()Ljava/util/stream/Collector;
at org.openqa.selenium.remote.ProtocolHandshake.streamW3CProtocolParameters(ProtocolHandshake.java:284)
at org.openqa.selenium.remote.ProtocolHandshake.createSession(ProtocolHandshake.java:149)
at org.openqa.selenium.remote.HttpCommandExecutor.execute(HttpCommandExecutor.java:142)
at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:637)
at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:250)
at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:236)
at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:137)
at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:174)
at com.xyz.xya.LeadTest.Launchapplication(RetailKeywords.java:47)
at com.xyz.xya.LeadTest.readData(RetailExecuteLead.java:111)
Suppressed: java.io.IOException: Incomplete document
at com.google.gson.stream.JsonWriter.close(JsonWriter.java:527)
at org.openqa.selenium.remote.ProtocolHandshake.createSession(ProtocolHandshake.java:167)
... 35 more
... Removed 27 stack
Use Maven Surefire Plugin if you are relying on running your tests from terminal mode or batch mode. And also, make sure you mention your test resources inside the build tag of your pom.xml like so.
<build>
<testResources>
<testResource>
<directory>src/test/resources</directory>
<filtering>false</filtering>
</testResource>
</testResources>
</build>
Now whenever you have to load your property file do so using an InputStream of some sorts. Or simply using the File class.
InputStream is = getClass().getResourceAsStream("/object.properties");
What the above stuff does is, during the build, maven knows where to pick the resource file from. And since you have mentioned the resources in pom, you can directly get the file using classpath without using file-systems directly.
#SteroidKing666 thanks a lot for the guidance.
As suspected by you it was due to conflict of multiple versions of Guava I had 17.0 & 21.0
I removed 17.0 and kept 21.0 version of it and then vooila it works.
I have an empty java test with Spring and Ebean
protected static ApplicationContext ctx;
#BeforeClass
public static void initSpringContext() {
ctx = new ClassPathXmlApplicationContext("spring-context.xml");
}
public class SomeTest extends SpringBase {
#Test
public void emptyTest() {}
}
I had a problem with class loading:
Caused by: javax.persistence.PersistenceException: models.Flat is NOT an Entity Bean registered with this server?
Problem was fixed with pom config
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12.4</version>
<configuration>
<useSystemClassLoader>false</useSystemClassLoader>
</configuration>
</plugin>
After this fix "mvn clean test" runs ok, but "mvn clean install" fails with exact exception
I suppose it's because integration-test phase.
I tried to config useSystemClassLoader in maven-failsafe-plugin, run with param -Dskip.integration.test=true but is makes no difference, I have feeling that this plugin did not call at all.
Also I've compared surefire-reports genereted by "mvn clean test" and "mvn clean verify" -- section "properties" within the testsuite is identical in both cases.
Skipping integration-test will be also an acceptable solution.
Maven 2.2.1 OS - Tested under Windows and Debian
If it can help, stacktrace of error:
Caused by: javax.persistence.PersistenceException: models.Flat is NOT an Entity Bean registered with this server?
at com.avaje.ebeaninternal.server.core.DefaultServer.createQuery(DefaultServer.java:1008)
at com.avaje.ebeaninternal.server.core.DefaultServer.createQuery(DefaultServer.java:965)
at com.avaje.ebeaninternal.server.core.DefaultServer.find(DefaultServer.java:1001)
at com.avaje.ebean.Ebean.find(Ebean.java:1143)
at flats.crawler.managers.CrawlerManager.initCrawlerHashes(CrawlerManager.java:25)
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.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:346)
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:299)
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:132)
... 48 more
I've run two commands "mvn clean install -X" and "mvn clean test -X" and compared test classpathes:
in first case
[DEBUG] PATH\MODULE\target\MODULE-1.0.jar
in second case
[DEBUG] PATH\MODULE\target\classes
that's why Ebean can't find classes
For integration tests the maven-failsafe-plugin is responsible and NOT the maven-surefire plugin. So you configurations to ignore the integration test couldn't work.
Did you see this FAQ entry in the failsafe plugin docs? It gives a whole bunch of options for classloading configuration.
If none of those suggestions work for you, and skipping the integration tests is okay (as you mentioned), then -DskipITs=true should do it, per the docs.
When i create simple maven project and run inside eclipse for smooks then it works fine but when i create osgi bundle for that and deploy it in servicemix then it shows following error...
I put my smook configuration file in servicemix_home/ConfigurationFiles/smook/......
Ex : org.milyn.SmooksException: Failed to apply processing unit [org.milyn.javabean.ext.PropertyChecker] to [org:milyn:smooks:unknowndoc:/smooks-resource-list/jb:bean/jb:wiring].
org.milyn.SmooksException: Failed to apply processing unit [org.milyn.javabean.ext.PropertyChecker] to [org:milyn:smooks:unknowndoc:/smooks-resource-list/jb:bean/jb:wiring].
at org.milyn.delivery.dom.SmooksDOMFilter.processVisitorException(SmooksDOMFilter.java:823)
at org.milyn.delivery.dom.SmooksDOMFilter.access$700(SmooksDOMFilter.java:134)
...
Caused by: org.milyn.cdr.SmooksConfigurationException: Bean class 'com.test.pojo.Order' not avilable on classpath.
at org.milyn.javabean.ext.PropertyChecker.getBeanClass(PropertyChecker.java:97)
at org.milyn.javabean.ext.PropertyChecker.getBeanType(PropertyChecker.java:78)
at org.milyn.javabean.ext.PropertyChecker.visitBefore(PropertyChecker.java:47)
Change Classloader
Get current class loader from getClass().getClassLoader() and set in
Thread.currentThread().setContextClassLoader(classLoader);
and
smooks.setClassLoader(classLoader);
As part of our application we are using apache's xerces jaxp parser. When we deploy the application on weblogic 9.2, we are getting the following error.
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cxf.wsdl.WSDLManager' defined in class path resource [META-INF/cxf/cxf.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw exception; nested exception is java.lang.ClassCastException: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
As per our analysis, weblogic is trying to to load its own DocumentBuilderFactoryImpl which is present in weblogic.jar instead of apache's xerces.
We tried the following to force the weblogic to load DocumentBuilderFactoryImpl from xerces
i) we have added the following tag into weblogic.xml
<prefer-web-inf-classes>true</prefer-web-inf-classes>
ii) we have put latest versions of xalan in jre/lib/endorced folder. this didn't resolve our problem.
ii) we have added entries in weblogic-application.xml
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90">
<application-param>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
<package-name>org.apache.xerces.*</package-name>
<package-name>org.apache.xerces.jaxp.*</package-name>
</prefer-application-packages>
</weblogic-application>
ii)Added the following entry in weblogic-application.xml
<xml>
<parser-factory>
<saxparser-factory>org.apache.xerces.jaxp.SAXParserFactoryImpl</saxparser-factory>
<document-builder-factory>org.apache.xerces.jaxp.DocumentBuilderFactoryImpl</document-builder-factory>
<transformer-factory>org.apache.xalan.processor.TransformerFactoryImpl</transformer-factory>
</parser-factory>
</xml>
iii) Added jaxp.properties to load DocumentBuilderFactoryImpl from xerces to the jre/lib and started the server.In this case, the weblogic didnt start.
iv) Then we started the server first and then copied the jaxp.properties file during the run time when server starts.But no success
None of the above worked for us.
Any help is highly appreciated.
You did so many things that I don't understand the exact status. My advice would be to strictly follow the Application Server Specific Configuration Guide for WebLogic that I've successfully used in the past with WLS 9.2.
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90">
<application-param>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
</prefer-application-packages>
</weblogic-application>
You'll certainly have to add more packages under prefer-application-packages to setup Weblogic ClassLoader filtering but in the current state of the question, it's impossible to provide a precise answer.
Just in case, you can maybe try to blindly use the weblogic-application.xml from this thread:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90">
<xml>
<parser-factory>
<saxparser-factory>
org.apache.xerces.jaxp.SAXParserFactoryImpl
</saxparser-factory>
<document-builder-factory>
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
</document-builder-factory>
<transformer-factory>
org.apache.xalan.processor.TransformerFactoryImpl
</transformer-factory>
</parser-factory>
</xml>
<application-param>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
<package-name>org.apache.xerces.*</package-name>
<package-name>org.apache.xalan.*</package-name>
</prefer-application-packages>
</weblogic-application>
But this is a shot in the dark.
You could try forcing the use of the specified document builder factory as a command line option:
-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
This is assuming that you have the required Xerces builder factory class in your classpath.
In general, you shouldn't use a separate xerces.jar anymore, unless required by some legacy code. The Xerces parser classes come with the JRE, the package names just start with com.sun.org.apache instead of org.apache. You could try also
-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
and remove xerces.jar from your classpath altogether (this is what we did on WLS 10.3 and Java 1.6).
I managed to resolve the issue DocumentBuilderFactory not found with simple solution.
Try to copy xercesImpl.jar to the domain specific lib directory on weblogic MyDomain\servers\MyServer\lib.
In my case the problem was that i made a dependency on commons-digester which in turn used another version of xerces (that caused the conflict). So you can review your dependencies in case some other version of xerces was transitively included.
Update
As of Hudson Findbugs plug-in version 4.3 this is no longer an issue
End Update
As an example of my problem, I'm trying to build the following project http://www.sonatype.com/books/mvnex-book/reference/multimodule.html
I added the following to simple-parent/pom.xml
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>2.3</version>
<configuration>
<findbugsXmlOutput>true</findbugsXmlOutput>
<findbugsXmlWithMessages>true</findbugsXmlWithMessages>
<xmlOutput>true</xmlOutput>
</configuration>
</plugin>
</plugins>
</reporting>
And the following to simple-weather/pom.xml and simple-webapp/pom.xml
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
</plugin>
</plugins>
</reporting>
I inserted the following horrible equals method into one of the classes to have FindBugs generate some issues (as there is no error on 0 bugs):
public boolean equals(Object o) { return true; }
I'm using Hudson with a maven2 style project. The job is aimed at the simple-parent pom with the goals
clean site
I get the following exception:
[INFO] Generating "FindBugs Report" report.
[java] Warnings generated: 2
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Cannot inherit from final class
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.VerifyError: Cannot inherit from final class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch2(RemoteClassLoader.java:370)
at sun.reflect.GeneratedMethodAccessor594.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274)
at hudson.remoting.Request$2.run(Request.java:270)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:595)
Version info:
Maven 2.2.1
Java 1.5.0_22
Hudson 1.341 (also found on 1.339) running inside JBoss 4.0.5.GA (same error on 4.2.2.GA and 5.1.0.GA)
Maven FindBugs plugin 2.3
Hudson FindBugs plugin 4.1
Any ideas on how to fix this?
According to the FindBugs FAQ, this problem occurs when the wrong version of Apache BCEL is being used (see Q2: When I click the "Find Bugs!" button, I get a NoSuchMethodError or VerifyError). In your case, I suspect that the maven-findbugs-plugin is getting the BCEL library from JBoss because of some obscure classloading issue. There are some very similar bugs in Hudson's Jira, e.g. HUDSON-5134 (the hudson findbugs plugin is also affected).
My understanding is that this problem has been introduced recently (in v1.338) and, even if there is a workaround, it is an Hudson bug (it is a regression, it's not a problem with JBoss).
Now, you have IMO two solutions:
Use a version of Hudson anterior to v1.338 (the regression was reported for this version) but using an old version and sticking with it is certainly not really a viable solution.
Remove or replace the bcel.jar of JBoss (in server/SERVERNAME/lib) with the version used by the maven-findbugs-plugin (see dependencies). I'm not able to say how this will affect JBoss exactly (If you remove it, it seems that you will loose the ability to run JBoss in debug-mode but I can't say if everything will work fine if you replace it).
Whatever you'll do, please create a new Jira issue (http://issues.hudson-ci.org/) as this is a regression in Hudson. They have marked HUDSON-5134 as "Won't fix" because there is a workaround but I don't think that messing with JBoss libraries is a good solution (I'm repeating myself but this is a Hudson bug). So, insisting and letting Hudson developers know that other users are affected by this problem will help all the entire community (at least, I hope so).
The other answers provided are better, but one alternative to add: use Ant or batch file to create a separate build step that doesn't care that the FindBugs step failed. The Hudson plug-in can still be used to display the results.
As Pascal points out, there is a similar bug filed - HUDSON-5134 - and that bug indicates the behavior started with Hudson release 1.338. Since Hudson releases once a week, it can be difficult to pin down which version introduced a bug. I notice there was a classloader related change released with Hudson version 1.337 (HUDSON-5048), and I suspect that is causing the problem here, but I don't have direct evidence of that.
But that likely means you need to roll back to 1.337 or earlier to avoid this problem.