I am using Akka actors for Remote communication in karaf.
When I deploy the jar file generated after compiling using maven, I get the following error:
Exception in thread "Thread-113"
com.typesafe.config.ConfigException$Missing: No configuration setting found for key 'akka.version'
at com.typesafe.config.impl.SimpleConfig.findKeyOrNull(SimpleConfig.java:152)
at com.typesafe.config.impl.SimpleConfig.findOrNull(SimpleConfig.java:170)
at com.typesafe.config.impl.SimpleConfig.findOrNull(SimpleConfig.java:176)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:184)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:189)
at com.typesafe.config.impl.SimpleConfig.getString(SimpleConfig.java:246)
at akka.actor.ActorSystem$Settings.(ActorSystem.scala:168)
at akka.actor.ActorSystemImpl.(ActorSystem.scala:522)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:142)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:119)
at org.opendaylight.com.test.rem$$anon$1.run(rem.scala:19)
I even added Maven shade plugin in the pom file which was suggested in other answers, but adding the plugin makes all the karaf features to change to ''Resolved'' state. The configuration file for akka is in the classpath too. As of my knowledge, the akka configuration file is not being read at all, as I got the same exception even after removing the configuration file.
This error is most often caused by combining multiple Akka jars into a single super-jar and not handling the reference.conf files correctly. The reference.conf file in each of the Akka module jar-files needs to be concatenated into a single file in the super jar.
Follow the instructions in the docs here: https://doc.akka.io/docs/akka/current/scala/general/configuration.html#when-using-jarjar-onejar-assembly-or-any-jar-bundler
And then verify that the jar-file you use when running has the contents of all those reference.conf files concatenated into a single file.
Related
I have a vert.x maven project using the vertx-jdbc-client version 3.6.0 and according to the vertx jdbc docs there are some basic c3p0 configs you can specify in the config object passed in when creating a JDBCClient, but for the rest you need to use a c3p0.properties file on the classpath. I placed the c3p0.properties file in src/main/resources/c3p0.properties with:
initialPoolSize=1
acquireRetryAttempts=1
I verified that the c3p0.properties file is in target/classes after the build, the log output even changes on startup, where it used to say
10:52:57.388 [vert.x-eventloop-thread-0] DEBUG com.mchange.v2.cfg.MConfig - The configuration file for resource identifier '/c3p0.properties' could not be found. Skipping.
It no longer says this with the file there, so it seems it is finding it. But the values are not being respected, I still get the default initial pool size (3) and retry attempts (30).
What am I doing wrong? Any solutions for advanced c3p0 configurations in a maven vertx project?
In the last time I try to use Jenkins to build my Maven artifacts.
I have a Maven project called Imladria. It has some modules like ImladriaCore, ImladriaLibrary and ImladriaDatabase (examples, there are some more).
I have a Maven project in my Jenkins build server. Jenkins fetches all sources from my Gitlab server and builds all artifacts. After building it will publish all artifacts over FTP on my server.
It publishes them with their whole prefix so i'll have this structure on my server:
/home/user/TestServer/ImladriaCore/target/...
/home/user/TestServer/ImladriaLibrary/target/...
/home/user/TestServer/ImladriaDatabase/target/...
And so on.
I want my Jenkins to publish all built .jar in the same directory. I know that I have to remove the prefix. But this would only work without the ImladriaCore, Library, ... files when they are in they target direcory. E.g.:
/home/user/TestServer/target/ImladriaCore-1.0-Snapshot.jar
/home/user/TestServer/target/ImladriaLibrary-1.0-Snapshot.jar
/home/user/TestServer/target/ImladriaDatabase-1.0-Snapshot.jar
I tried many permutations of removing **/target/ */target/ or whatever as a prefix to publish all .jar in the same directory (/home/user/TestServer/).
I always get this error:
ERROR: Exception when publishing, exception message
[Failed to remove prefix from file named [ImladriaCore/target/imladriacore-1.0-SNAPSHOT.jar].
Prefix [*/target/] must be present in all file paths]
Does anyone know which wildcard I would have to choose?
My configuration of publishing:
Publish
Server config
Thank you and Regards
- Felix
Summary: I have a very basic Java 1.8 and Spring 4.0.5 project, I'm using Maven 3.2.3 to manage it. Maven exec cannot seem to see my Spring context, even though it appears to me that it is in the classpath.
My spring context is in
<project root>/src/main/resources/spring/ch2-beans.xml
and I load it using:
ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("/spring/ch2-beans.xml");
after a "mvn clean compile" I see
<project root>/target/classes/spring/ch2-beans.xml
and when I run:
mvn -X exec:java -Dexec.mainClass="com.wiley.beginning.spring.ch2.Main"
I see the following debug output which makes me think the classpath is indeed correct:
[DEBUG] Collected project classpath [/Users/me/Documents/workspace/BeginningSpring/chapter2/spring-book-ch2/target/classes]
[DEBUG] Adding to classpath : file:/Users/me/Documents/workspace/BeginningSpring/chapter2/spring-book-ch2/target/classes/
Yet I get the following error:
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [spring/ch2-beans.xml]; nested exception is java.io.FileNotFoundException: class path resource [spring/ch2-beans.xml] cannot be opened because it does not exist
Can anyone point me in the direction of sorting this out? What I've posted above is the result of many different attempts to solve this, and I'm stumped by the error when it certainly appears that the file path should be in the classpath, so perhaps this is something that has changed since I last coded (a while ago..). Thanks!
Update..
Thinking that it might be some classpath issue with exec:java I ran the same code inside a unit test, executed within maven. Same error. I've also tried loading the xml file as "classpath:/spring/ch2-beans.xml", did not fix it.
There was a hyphen in the file name of the Spring configuration I was trying to load, and it appears that the classloader won't accept that. Hyphens are illegal in identifier names in Java, apparently this applies also to external resources.
Once I removed the hyphen from the xml file name, it was found.
On a related note, I'm pretty annoyed with the "Beginning Spring" book example which uses these hyphenated names.
I have an problem with my code. The WSDL file was parsed by wsdl2java from apache cxf. Now I'm trying to get connection with web service but still I'm getting null pointer exception.
Exception in thread "main" java.lang.NullPointerException
at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:92)
at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:203)
at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:147)
at org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:97)
at javax.xml.ws.Service.<init>(Service.java:56)...
The url address is pointing to place from where I have downloaded the WSDL file. For building jar I'm using Maven with dependencies such as:
jaxws-api
cxf-rt-transports-http
cxf-rt-frontend-jaxws
cxf-rt-bindings-soap
jar with deps is created by maven-assembly-plugin
For sure the wsdl file exists there because it have been downloaded from there.
Any suggestions? Thanks for any help.
BTW. It's not duplicated question any of solution which I have found does not work for me.
I ran into the same issue using shadowJar in gradle. The solution is to explicitly merge bus-extensions.txt service files in the META-INF/cxf/ directory:
shadowJar {
archiveName = 'application.jar'
mergeServiceFiles{
path='META-INF/cxf'
}
}
Instead using maven-assembly-plugin when deploying Java app that depends on Apache CXF libs, I have used maven-dependency-plugin with goal set to copy-dependencies. That will not produce single JAR, but will copy all required JARs into target/ folder. It is then easy to put them all in class path and start Java app.
The soloution is quite simple, I just changed the version of Apache CXF lib to older one, and it works. So probably I had a problem in my configuration or Apache CXF have a bug.
So as a solution just check the older version of provided lib.
I am working on some migration project, involves moving around quite a few stuff from Ant/CVS/Jboss4/Java5 to Maven/SVN/Jboss7/Java6 - this gets nasty.
First step, I am working on moving the ant build to maven - that it in iteslf involve a lot of complication. Now that I get the ear file built, and I compared it with the ear from ant build, I think I got it good with the maven build.
Now, deploying on Jboss4 first, I encouter
[ejb.EJBDeployer.verifier] EJB spec violation:
Warning: The message driven bean must declare one onMessage() method.
2011-11-08 15:25:03,079 ERROR (Thread: main) [jboss.deployment.MainDeployer] Could not create deployment: file:/opt/jboss-4.0.3SP1/server/default/tmp/deploy/tmp46514Billing-EAR-1.0.ear-contents/processsubscriptionbean-1.0.jar
org.jboss.deployment.DeploymentException: Verification of Enterprise Beans failed, see above for error messages.
at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:575)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy24.create(Unknown Source)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:935)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:925)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:789)
I came across this thread jBoss deployment of message-driven bean spec violation - so I figured I was using the wrong library on my new maven build, I replaced it and made sure it's using the same javax.jms library (this now points to the same jar containing javax.jms.Message as the original ant build) - in fact I simply grabbed the jar referenced by the ant build and upload it to maven repo and reference it from my maven build.
But I still encounter the above problem. The original ant-build would deploy with no problem, but currently I am stuck at this issue for the maven-build ear.
Any suggestion on what other steps i can take to make sure there are no different class files issue? Thanks!
Is the javax.jms library being packaged in your ear (jboss-j2ee.jar, jboss-client.jar, etc)? If so, you don't want that since you want to use the one provided by the app server. You can fix this by changing the dependency in your pom to have the <scope>provided</scope> for anything that shouldn't be in your ear.