I am working on a project with multiple JDBC data sources and JTA. I use Maven as a build tool, and I'd like to use the Jetty plugin (6.1.20) to run the application during development.
I am trying to configure Jetty to use Atomikos as the transaction manager. I'm following the Atomikos documentation from Jetty, but the Jetty startup fails with what looks like a class loader issue.
Here are the relevant bits of my configuration.
runtime scope dependencies in my pom.xml:
<dependency>
<groupId>com.atomikos</groupId>
<artifactId>transactions-jta</artifactId>
<version>3.5.7</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.atomikos</groupId>
<artifactId>transactions-jdbc</artifactId>
<version>3.5.7</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>javax.transaction</groupId>
<artifactId>jta</artifactId>
<version>1.1</version>
<scope>runtime</scope>
</dependency>
My jetty-env.xml located in /WEB-INF (autodiscovered by Jetty):
<New id="userTxImpl" class="com.atomikos.icatch.jta.UserTransactionImp" />
<New id="tx" class="org.mortbay.jetty.plus.naming.Transaction">
<Arg>
<Ref id="userTxImpl" />
</Arg>
</New>
The instantiation of tx at the end is the bit that fails, if I leave it out, Jetty starts up fine (but does not expose UserTransaction via JNDI, of course).
The Stacktrace:
2009-09-02 18:42:18.910::WARN: Config error at <New id="tx" class="org.mortbay.jetty.plus.naming.Transaction"><Arg>
<Ref id="userTxImpl"/>
</Arg></New>
2009-09-02 18:42:18.910::WARN: Failed startup of context org.mortbay.jetty.plugin.Jetty6PluginWebAppContext#12515db{/administrator,C:\workspace\administrator\src\main\webapp}
java.lang.IllegalStateException: No Constructor: <New id="tx" class="org.mortbay.jetty.plus.naming.Transaction"><Arg>
<Ref id="userTxImpl"/>
</Arg></New> on org.mortbay.jetty.plugin.Jetty6PluginWebAppContext#12515db{/administrator,C:\workspace\administrator\src\main\webapp}
at org.mortbay.xml.XmlConfiguration.newObj(XmlConfiguration.java:631)
at org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:256)
at org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:190)
at org.mortbay.jetty.plus.webapp.EnvConfiguration.configureWebApp(EnvConfiguration.java:130)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1247)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441)
at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383)
at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210)
at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
This looks like a classloader issue, as org.mortbay.jetty.plus.naming.Transaction has got a Constructor taking a javax.transaction.UserTransaction, and com.atomikos.icatch.jta.UserTransactionImp implements javax.transaction.UserTransaction, yet Jetty complains it does not have a proper constructor to use.
I'm obviously missing something here, but what is it?
Thanks!
You may have multiple copies of the UserTransaction class kicking around in your deployment. If these are loaded from different classloaders, then you can end up with this sort of error.
Check Jetty's libraries for UserTransaction, and then check your application's libraries. You should only have one copy.
I believe that you should not be specifying the JTA jar as a 'runtime' requirement, but rather as a 'provided' requirement. Similar to servlet-api and JMS, the individual implementers provide their own copies of the API and providing the Sun jar can muck them up.
I realize this is already answered, but I wanna put up my experience to save others the grief I just went through.
I had a similar problem, but it was caused by a conflict in versions of geronimo-jta spec. Specifically the one depended on by atomikos wasn't getting along with the one used by jetty. I had to exclude the one from atomikos, e.g.:
com.atomikos
transactions-essentials-all
3.5.9
org.apache.geronimo.specs
geronimo-jta_1.0.1B_spec
Like Taylor, I just blew a couple hours on this exact same issue. I use Hibernate as a JPA provider and it had a Maven depdency on its own JTA User Tranaction. Once I excluded this dependency I got past the issue.
Related
I'm deploying an EAR application built with Maven which has the following dependency in one of the modules:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>5.1.0.Final</version>
</dependency>
When I try to deploy the application in a Glassfish Server 4.1 I get the following error:
Fatal: java.lang.NoSuchMethodError: org.jboss.logging.Logger.debugf(Ljava/lang/String;I)V
at org.hibernate.internal.NamedQueryRepository.checkNamedQueries(NamedQueryRepository.java:149)
I made some research to solve this problem and made the following attempts:
First Attempt
I found this question and used the script in this article to clean the Glassfish's osgi-cache, as suggested in the question and in this issue of the Glassfish/Payara Github repository. Restarted the server. Same error.
Second Attempt
I found this question and tried the suggestion of the first answer, like this: looking at the dependency tree, I see that hibernate-entitymanager has the following dependency:
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.3.0.Final</version>
<scope>compile</scope>
</dependency>
So I searched at my Server installation and found the jboss-logging.jar. The installed version was 3.1.0-GA (I'm not sure right now, but surely it was a previous version of the dependency). I downloaded jboss-logging-3.3.0.Final.jar from the Maven Central Repository and replaced the one in my Server installation. Restarted the server. Same error.
Third Attempt
Some comments in the previous post (and others) suggested to add a property org.jboss.logging.provider=slf4j as I'm using these dependencies for logging:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.21</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.21</version>
<scope>test</scope>
</dependency>
I found some .properties files in the /glassfish/domains/domain1/config/ folder but none of them contains such a property and I don't know in which file to add that property. I also made some search in the Admin Console but I didn't found where to add properties. The only logging configuration I found was to configure logging levels.
After that I found where to put some JVM options for the Glassfish Server in the Admin Console and added -Dorg.jboss.logging.provider=slf4j as an option but did not work for me (even more, I had to reboot my computer to get Glassfish in ground zero)
Fourth Attempt
Before all this I had a problem and made another question in StackOverflow. Guided by this comment in that post I changed the project configuration but nothing happened (I solved that problem with a little change in my dependencies, answer still pending)
After all the attempts, I'm running out of ideas and the problem remains. I don't know what could be the problem. Any guide, help or answer will be really appreciated. If anybody needs more details about the situation just let me know.
Thanks in advance for your collaboration.
EDIT 1
I was searching and found this article which says something similar to what I did and adds a provided dependency for jboss-logging like this:
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.3.0.Final</version>
<scope>provided</scope>
</dependency>
But the error remains. Apparently it's something with the Server but I can't figure out what. I'm using GlassFish Server Open Source Edition 4.1 (build 13)
I was using JBoss server 7.1 to deploy my project. In my case this error was due to the fact that the I was using jboss-logging-3.3.0.Final.jar in my project but the JBoss 7 had a jboss-logging-3.1.0.GA.jar (/opt/jboss-as-7.1.1.Final/modules/org/jboss/logging/main/) by default. So, may be this was due to the jar conflict or method was not present in the jboss-logging-3.1.0.GA.jar, I am not sure. But replacing the jboss-logging-3.1.0.GA.jar with jboss-logging-3.3.0.Final.jar and change mapping in module.xml (at the same above mentioned location) as follows
<module xmlns="urn:jboss:module:1.1" name="org.jboss.logging">
<resources>
<resource-root path="jboss-logging-3.3.0.Final.jar"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="org.jboss.logmanager"/>
</dependencies>
</module>
And the error was gone. Hope it helps.
This is because GlassFish ships with an earlier version of JBoss Logging and this is being picked up by your application hence the NoSuchMethod error. The version of JBoss Logging shipped with GlassFish 4.1 does not have the method defined. You can try and replace the version of jboss-logging in the modules directory of glassfish this may or may not work but it looks like you tried and failed with this approach.
Another option is to upgrade to the latest Payara 4.1.1.162 which ships with JBoss Logging 3.3.0.Final.
Block Glassfish for using its own lib when project lib is provided
Just create a glassfish-web.xml file in the WEB-INF directory. The contents of the file are shown below:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
<class-loader delegate="false"/>
</glassfish-web-app>
This ensures that glassfish does not load it's internal libraries, but libraries from your project.
I need some features from Infinispan 8+. Therefore I have updated my company app pom.xml with the newest Infinispan pom.
It was quite straightforward, but the app uses jgroups (or its default config in default-configs/default-jgroups-udp.xml - this location is different from previous versions of infinispan). The default versions have some parameters (and the XSD from Jgroups version 3.6) - so I also bumped jgroups to 3.6.8.Final as it looks like it is the intended version (and the version that does not complain about unknown parameters in default config in infinispan 8.2)
so the pom is the following:
<dependency>
<groupId>org.jgroups</groupId>
<artifactId>jgroups</artifactId>
<version>3.6.8.Final</version>
</dependency>
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-core</artifactId>
<version>8.2.0.Final</version>
</dependency>
Anyway - this application starts with no problems using spring-boot with Jetty. I am pretty sure it would start on any application server.
But then I have no choice but to run it on JBoss 6.4.
There I got an exception involving some jboss.as classes (this is kind of unexpected) during the deployment:
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:859)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:628)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:617)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:542)
at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:234)
... 141 more
Caused by: java.lang.ExceptionInInitializerError
at org.jgroups.conf.XmlConfigurator.<clinit>(XmlConfigurator.java:35)
at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:62)
at org.jgroups.JChannel.<init>(JChannel.java:129)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:419)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:320)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:366)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:190)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
... 146 more
Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: org.jboss.as.clustering.jgroups.LogFactory from [Module "deployment.mymodule-5.0.0.0-SNAPSHOT.ear.appName.war:main" from Service Module Loader]
at org.jgroups.logging.LogFactory.<clinit>(LogFactory.java:31)
... 158 more
Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.jgroups.LogFactory from [Module "deployment.mymodule-5.0.0.0-SNAPSHOT.ear.appName.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.jgroups.logging.LogFactory.<clinit>(LogFactory.java:28)
... 158 more
My guess is that org.jgroups.logging.LogFactory somehow discovers that is is running on a Jboss and tries to use org.jboss.as.clustering.jgroups.LogFactory but this version of Jboss does not have one. (the server directory EAP-6.4.0\modules\system\layers\base\org\jgroups\main contains jgroups version 3.2.X).
Is there any walkaround to use this jgroups version (and so Infinispan 8.2) in Jboss 6.4?
This is (the application) an ear file so I can manipulate jboss-deployment-structure.xml file, but so far I only came with excluding Jboss original jgroups, and this did not help.
<exclusions>
<module name="org.jgroups"/>
</exclusions>
This is currently bug with Infinispan 8 + EAP 6.4 combination. The reason is exactly as #Flavius says in comments. Currently there is discussion where to fix it, but it'll mostly likely be fixed in EAP 6.4. I'm sure it will be done soon.
I can only offer you a working workarounds.
Use WildFly - the issue is not present there anymore
Little nasty workaround, but it works:
Call System.clearProperty("jgroups.logging.log_factory_class"); in the deployment
Include JBoss Logging of version specified in infinispan-bom in your deployment (e.g. add jboss-logging Maven dependency in your pom.xml)
Provide jboss-deployment-structure.xml to your deployment, which excludes the server's JBoss logging, see below:
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.jboss.logging" />
</exclusions>
</deployment>
</jboss-deployment-structure>
Another possibility if none of the above workarounds work (for instance the app uses other log mechanisms) is to implement an own
http://www.jgroups.org/javadoc/org/jgroups/logging/CustomLogFactory.html
The log factory must return a log instance, implementing it for any other logger is straightforward with methods trace/error/debug etc.
Then this logger class can be set with System.setProperty("jgroups.logging.log_factory_class","my.company.logging.MyJgroupsLog");
I followed example from: https://inserpio.wordpress.com/2014/04/30/extending-the-neo4j-server-with-spring-data-neo4j/
Created 1 Repo, 1 Controller (with get and put rest endpoints. get /test/get/{name} uses 'name' property to get the node, put /test/create is just a test endpoint for now that always should create same node which later on i want to get...) and 1 Domain class.. Together with the PluginInitializer, that exposed Neo4jTemplate and my custom repo.
My app-context:
<context:annotation-config />
<context:spring-configured />
<context:component-scan base-package="uk.co.neo4j.extension.tvshow">
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>
<neo4j:config base-package="uk.co.neo4j.extension.tvshow.domain" graphDatabaseService="graphDatabaseService" />
<neo4j:repositories base-package="uk.co.neo4j.extension.tvshow.repository" />
<tx:annotation-driven mode="proxy" />
Pom file dependencies:
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-neo4j</artifactId>
<version>${spring-data-neo4j.version}</version>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-neo4j-rest</artifactId>
<version>${spring-data-neo4j.version}</version>
</dependency>
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
<version>${commons-configuration.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.neo4j.app</groupId>
<artifactId>neo4j-server</artifactId>
<version>${neo4j.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>${javax.validation.version}</version>
</dependency>
<dependency>
<groupId>javax.transaction</groupId>
<artifactId>jta</artifactId>
<version>${javax.transaction.version}</version>
</dependency>
Followed by maven-compiler-plugin to copy all dependant jar files into lib folder. Add PluginInit fqp to PluginLifecycle file, as well as added package to neo4j server config:
org.neo4j.server.thirdparty_jaxrs_classes=uk.co.neo4j.extension.tvshow=/tv
I copied my jar file + all dependant jar files into neo4j server plugin folder, started it successfully:
**2015-03-22 21:49:37.411+0000 INFO [o.n.s.m.ThirdPartyJAXRSModule]: Mounted unmanaged extension [uk.co.neo4j.extension.tvshow] at [/tv]**
2015-03-22 21:49:37.535+0000 INFO [o.n.s.w.Jetty9WebServer]: Mounting static content at [/webadmin] from [webadmin-html]
2015-03-22 21:49:37.625+0000 INFO [o.n.s.w.Jetty9WebServer]: Mounting static content at [/browser] from [browser]
2015-03-22 21:49:40.361+0000 INFO [o.n.s.CommunityNeoServer]: Server started on: http://localhost:7474/
2015-03-22 21:49:40.361+0000 INFO [o.n.s.CommunityNeoServer]: Remote interface ready and available at [http://localhost:7474/]
2015-03-22 21:49:40.361+0000 INFO [o.n.k.i.DiagnosticsManager]: --- SERVER STARTED END ---
BUT! When I try to use it via rest, i.e. :PUT /tv/test/create OR :GET /tv/test/get/testnode i always get:
Error: 500 - Internal Server Error
In logs I found this, and it happens for both get and put:
SEVERE: The RuntimeException could not be mapped to a response, re-throwing to the HTTP container
org.springframework.dao.InvalidDataAccessApiUsageException: Could not resolve dependency of type:javax.transaction.TransactionManager; nested exception is java.lang.IllegalArgumentException: Could not resolve dependency of type:javax.transaction.TransactionManager
at org.springframework.data.neo4j.support.Neo4jExceptionTranslator.translateExceptionIfPossible(Neo4jExceptionTranslator.java:48)
at org.springframework.dao.support.ChainedPersistenceExceptionTranslator.translateExceptionIfPossible(ChainedPersistenceExceptionTranslator.java:59)
at org.springframework.dao.support.DataAccessUtils.translateIfNecessary(DataAccessUtils.java:213)
at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:147)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207)
at com.sun.proxy.$Proxy72.save(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:201)
at com.sun.proxy.$Proxy74.save(Unknown Source)
at uk.co.neo4j.extension.tvshow.rest.TestController.createTestNode(TestController.java:64)
...
So basically, whenever any operation is done against my repository:
testRepository.getTestNodeByName(name);
testRepository.save(testNode);
It treats it as transaction and the Transaction Manager is not found... From the doc's of SDN I've read that neo4jTransactionManager bean is already configured as part of Neo4jConfiguration, and yes I've checked - it is already there:
#Bean(name = {"neo4jTransactionManager","transactionManager"})
#Qualifier("neo4jTransactionManager")
public PlatformTransactionManager neo4jTransactionManager() throws Exception {
return new JtaTransactionManagerFactoryBean(getGraphDatabaseService()).getObject();
}
So what am I missing? :(
I've been getting a very strange error when trying to start a Jersey app on Tomcat. The same code works on other computers. I tried reinstalling tomcat, all my maven dependencies, even Eclipse and Java itself, no luck. It seems like a bad Jersey version is being loaded, I think?
Any pointers in the right direction will be appreciated.
Here's the effective pom: http://pastebin.com/NacsWTjz
And the actual pom: http://pastebin.com/H6sHe4ce
2015-02-13 13:43:40,870 [localhost-startStop-1] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/middleware-server] - StandardWrapper.Throwable
java.lang.NoSuchMethodError: javax.ws.rs.core.Application.getProperties()Ljava/util/Map;
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:304)
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:285)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:311)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
at javax.servlet.GenericServlet.init(GenericServlet.java:158)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1231)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1031)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4901)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5188)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1409)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1399)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Note: Please see above comments for further discussion and tips.
This error usual means that you have a both a JAX-RS 1 and JAX-RS 2 jar on the classpath. Jersey 2 uses JAX-RS 2 (javax.ws.rs-api-2.0.1.jar), but if you have the jsr311-api.jar also, which is JAX-RS 1, there is a javax.ws.rs.core.Application in each jar. But the jsr311-api Application doesn't have the method getProperties() (hence NoSuchMethodError).
I've come to the conclusion that all you need to do is add the above exclusion to the swagger dependency. The Jackson 2.0 provider (which depends on JAX-RS 1) seems to be overridden by a 2.4.1 provider (which uses the new version). So we don't need to add it ourselves. When it's overridden, it seems to leave behind the jsr311-api.jar. So if we exclude it, no one can attempt to use it, which looks to be the current problem
<dependency>
<groupId>com.wordnik</groupId>
<artifactId>swagger-core_2.10</artifactId>
<version>1.3.11</version>
<exclusions>
<exclusion>
<groupId>javax.ws.rs</groupId>
<artifactId>jsr311-api</artifactId>
</exclusion>
</exclusions>
</dependency>
We are using jersey-json 1.9 which has a dependency on jersey-core which also happen to have a javax.ws.rs.core.Application class.
So our fix is to exclude the jersey-core from jersey-json:
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-json</artifactId>
<version>1.9</version>
<exclusions>
<exclusion>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-core</artifactId>
</exclusion>
</exclusions>
</dependency>
the problem is related about "com.sun.jersey:jersey-core:jar:1.18.3" (or any 1.* version) because old versions of Jersey didn't have that "public Map getProperties()" method.
And one of your dependencies use Jersey version 1 (you can check that in running mvn dependency:tree and search all jersey-core version used)
Me I have resolved the problem deleting all com.sun.jersey dependancies (old api) and using the new one org.glassfish.jersey API
https://mvnrepository.com/artifact/org.glassfish.jersey.core
I'm struggling with JBOss and I'm stuck on a problem which seems trival to fix but it turns out I can't.
When I try to deploy a simple java web app I encounter an exception:
org.hibernate.ejb.HibernatePersistence cannot be cast to avax.persistence.spi.PersistenceProvider
I know that this is a problem with having more then one persistence.jar. So in my pom I did something like that:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>3.4.0.GA</version>
<exclusions>
<exclusion>
<groupId>org.hibernate</groupId>
<artifactId>ejb3-persistence</artifactId>
</exclusion>
</dependency>
But I'm unlucky with it. I still get the error. Could anybody help me kindly to solve this task?
Agata
It looks like you want to package your own version of Hibernate within your application. This is possible but you'll have to setup classloader scoping for your application. From ClassLoadingConfiguration:
Isolation with Overriding Server Classes
Use the following constructs to
enabled scoped class loading with the
deployment classes overriding the
server classes.
...
For jboss-web.xml:
<jboss-web>
<class-loading java2ClassLoadingCompliance="false">
<loader-repository>
com.example:archive=unique-archive-name
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
</class-loading>
...
In other words, either include all your Hibernate libraries and disable parent class loader delegation or exclude them all and use the one from JBoss.
See also
http://community.jboss.org/wiki/JBossClassLoadingUseCases
http://community.jboss.org/wiki/ClassLoadingConfiguration