I am working on migrating an application from RestEasy implemenation to Jersey Implementation. The main problem I am facing is in the jars required for the CDI part.
While using resteasy, we are using the following 3 resteasy related jars
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-cdi</artifactId>
<version>3.0.8-FINAL</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jaxrs</artifactId>
<version>3.0.8-FINAL</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-servlet-initializer</artifactId>
<version>3.0.8-FINAL</version>
</dependency>
Now, to migrate it to Jersey, I am using the following jars in place of the resteasy jars.
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.22.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext.cdi</groupId>
<artifactId>jersey-cdi1x-servlet</artifactId>
<version>2.22.1</version>
</dependency>
<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<version>1.1</version>
</dependency>
Now when I try to deploy the EAR on the JBOSS server, I get the following error.
15:04:48,156 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.subunit."abc-ear.ear"."xyz-service-impl.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."abc-ear.ear"."xyz-service-impl.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "xyz-service-impl.war" of deployment "abc-ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS016053: Service class org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider didn't implement the javax.enterprise.inject.spi.Extension interface
at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:48)
at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:119)
at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:79)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
... 5 more
As you can see from stack trace, the error that I am getting is org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider didn't implement the javax.enterprise.inject.spi.Extension interface
I downloaded the source of the required jar to see if the class in question implements that interface or not. Well, it does implement the Extension interface.
Right now I am not able find a solution for this error.
I have tried various permutation and combination of different jersey jars but couldn't find a fix for this.
I have ran out of ideas. Any help would be really appreciated.
Recently I've done quite similar migration (RESTEasy 3.0.8.Final -> Jersey 2.23.1), but my migration also included the abandonment of the WildFly server. So it's quite big difference.
You haven't included any information about used Weld version, so please do it as this is very important here.
Anyway, two tips from my side before you'll update your question:
There is a big chance that your error is caused by the EAR deployment. Because CDI and EAR archives sometimes don't play well together. Can you check what happen if you change your packaging to *.war?
If you don't have a very, very good reason to migrate to a non-built-in JAX-RS implementation when still using Java EE app server and CDI, please don't do it. It's a tough task.
Ps. JFYI amount of problems with Weld and App servers which I've encountered pushed me to abandon them wherever I can.
UPDATE
You said you are using Weld 1.1.23.FINAL - this is very important information. Jersey + Weld integration changed heavily since Jersey 2.15. Personally, I wasn't able to make it work without some newer Weld version (2.3.5 in my case) - probably because this combination isn't supported.
In your case, as you're using extremely old Weld version, I would advice you to try at most Jersey 2.14.
In Jersey 2.14, needed dependencies were different. Please remove jersey-cdi1x-servlet and try this instead:
<dependency>
<groupId>org.glassfish.jersey.containers.glassfish</groupId>
<artifactId>jersey-gf-cdi</artifactId>
<version>2.14</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers.glassfish</groupId>
<artifactId>jersey-gf-cdi-ban-custom-hk2-binding</artifactId>
<version>2.14</version>
</dependency>
<!-- is it needed for you?
<dependency>
<groupId>org.jboss.weld.servlet</groupId>
<artifactId>weld-servlet-core</artifactId>
</dependency>
-->
BTW: may I know why you are changing JAX-RS implementation inside JBoss?
I have migrated to latest versions last month and this works for me.
try this.
<properties>
<version.jersey>2.23.2</version.jersey>
<version.glassfish>2.4.0</version.glassfish>
</properties>
<dependencies>
<dependency>
<groupId>org.glassfish.hk2.external</groupId>
<artifactId>asm-all-repackaged</artifactId>
<version>${version.glassfish}</version>
</dependency>
<dependency>
<artifactId>hk2-utils</artifactId>
<groupId>org.glassfish.hk2</groupId>
<version>${version.glassfish}</version>
<exclusions>
<exclusion>
<artifactId>javax.inject</artifactId>
<groupId>javax.inject</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>javax.annotation</groupId>
<artifactId>javax.annotation-api</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>javax.ws.rs-api</artifactId>
<version>2.0.1</version>
</dependency>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.2.12</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-common</artifactId>
<version>${version.jersey}</version>
<exclusions>
<exclusion>
<groupId>org.glassfish.hk2</groupId>
<artifactId>osgi-resource-locator</artifactId>
</exclusion>
<exclusion>
<groupId>org.glassfish.hk2.external</groupId>
<artifactId>aopalliance-repackaged</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>${version.jersey}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-multipart</artifactId>
<version>${version.jersey}</version>
</dependency>
</dependencies>
You might be using wrong dependancies. Check this:
https://jersey.java.net/documentation/latest/modules-and-dependencies.html
Related
I was getting this exception
java.lang.NoSuchMethodError: org.apache.xml.security.utils.XMLUtils.decode
Then I updated my dependencies and moved on to another similar exception which I am unable to resolve for quite a while:
I am getting NoSuchMethodError when my module receives the request upon calling this method
WebServiceTemplate client = ...;
client.marshalSendAndReceive(req, new ActionCallback("http://samples/RequestOrder"));
it throws
java.lang.NoSuchMethodError: org.apache.xml.security.encryption.AbstractSerializer: method <init>()V not found
at org.apache.cxf.ws.security.wss4j.StaxSerializer.<init>(StaxSerializer.java:62)
the (at least I think) relevant part of my dependencies
<dependency>
<groupId>org.apache.ws.security</groupId>
<artifactId>wss4j</artifactId>
<version>1.6.15</version>
</dependency>
<dependency>
<groupId>org.springframework.ws</groupId>
<artifactId>spring-ws-security</artifactId>
<version>3.0.9.RELEASE</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-ws-security</artifactId>
<version>3.3.6</version>
</dependency>
I was looking at multiple versions of org.apache.xml.security.encryption and it doesn't look like any of those versions have such method. Any idea what would be the correct combination of versions?
as a sidenote I also found this library and thought that would be helpful , but it seems it is somewhat different than aforementioned <groupId>org.apache.ws.security</groupId>
<dependency>
<groupId>org.apache.wss4j</groupId>
<artifactId>wss4j</artifactId>
<version>2.3.0</version>
<type>pom</type>
</dependency>
I had similar issue and tried possible solutions online but to no avail.
Some of the documents suggested that dependency mismatch with other dependencies is key, like here.
In relation to this exact reported error, I kept on changing the version of the below dependency and finally reached this, which was the latest version as at the time this answer was posted.
<dependency>
<groupId>org.apache.santuario</groupId>
<artifactId>xmlsec</artifactId>
<version>2.1.4</version>
</dependency>
But remember to ensure that if you have the below dependency, exclude that of xmlsec :
<dependency>
<groupId>org.springframework.ws</groupId>
<artifactId>spring-ws-security</artifactId>
<exclusions>
<exclusion>
<groupId>org.apache.santuario</groupId>
<artifactId>xmlsec</artifactId>
</exclusion>
</exclusions>
</dependency>
We migrate from WAS 7.0 to WAS 8.5.5.4 with JRE 7.0 in my compagny, as all dependency are not open source, i haven't information on the goal of the following :
<dependency>
<groupId>ibm</groupId>
<artifactId>com.ibm.ws.runtime</artifactId>
<version>${com.ibm.ws.runtime.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>ibm</groupId>
<artifactId>etools.xsd.bean.runtime</artifactId>
<version>${etools.xsd.bean.runtime.version}</version>
</dependency>
<dependency>
<groupId>ibm</groupId>
<artifactId>j2ee</artifactId>
<version>${j2ee.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>ibm</groupId>
<artifactId>marshall</artifactId>
<version>${ibm.marshall.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>ibm</groupId>
<artifactId>wsatlib</artifactId>
<version>${ibm.wsatlib.version}</version>
<scope>provided</scope>
</dependency>
My question is, did i need to update the following dependency ( by default i think yes, because there are linked to the 7.0 was) ? In this case, what's the dependency in WAS 8555, i know that IBM has change the groupId/ArtifactId of the dependency in WAS 85554. As i don't know the utility of the denpendancy actually i'am not able to do the link with news.
Looks like you would use:
<dependency>
<groupId>com.ibm.tools.target</groupId>
<artifactId>was</artifactId>
<version>8.5.5</version>
<type>pom</type>
<scope>provided</scope>
</dependency>
See https://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.wdt.doc/topics/localrepo.htm?cp=SSEQTP_8.5.5&lang=en for POM dependencies.
Cindy
I am trying to deploy a JPA 2.1 (Hibernate) project on Weblogic 12.1.3 on Java 8 and getting this error. But works on Tomcat 8.
Caused By: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;
at org.hibernate.cfg.annotations.EntityBinder.processComplementaryTableDefinitions(EntityBinder.java:973)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:824)
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3845)
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3799)
at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1412)
Truncated. see log file for complete stacktrace
pom.xml
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>4.3.11.Final</version>
</dependency>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.2.0.RELEASE</version>
</dependency>
<!--
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.8.2.RELEASE</version>
<exclusions>
<exclusion>
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.0-api</artifactId>
</exclusion>
</exclusions>
</dependency>
-->
Update:-
As answered below, JPA 2.1 is not enabled in Weblogic 12.1.3 by default. And can be enabled as explained here http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/01-06-004-JavaEE7andWebLogicServer/javaee7.html#section1
Weblogic is a java-ee application server and comes with the full java-ee stack (and includes so JPA).
Weblogic 12.1.3 comes with jpa 2.1 with eclipselink as provider see here
including hibernate as jpa implementation have so no sense here as the server already come with it's own implmentation (maven scope provided)
I suppose that this dependencies
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
</dependency>
is so sufficient (jpa 2.1 is part of java-ee 7 stack)
Could be that Weblogic is using its own library for JPA, which is older than yours. Could be that JPA 2.1 wasn't enabled during setup. You need to configure the server to enforce your libraries instead of those provided by WLS.
How to configure prefer application packages
Can someone help me write the dependency for javax.persistence. I have googled it but nothing worked.
I bumped into this page that gives some details on how to write the dependency, but yet i am unable to write it. Can someone help me out?
This is the one for javax.persistence:
<dependency>
<groupId>javax.persistence</groupId>
<artifactId>persistence-api</artifactId>
<version>1.0.2</version>
<scope>provided</scope>
</dependency>
and this is for the whole Java EE 6 stack:
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
Edit
Note that I specified a provided scope here, which means that your dependency is available at compile- and test-time, but will not be packaged into your artifacts. This is usually needed if you want to deploy your artifacts in an application server, since they provide their own implementation of the api.
And add this dependency in your pom.xml:
<dependency>
<groupId>javax.persistence</groupId>
<artifactId>persistence-api</artifactId>
<version>1.0.2</version>
</dependency>
That "Coping with Sun JARs" page might be a little outdated, this JAR is available in the Maven Central Repository
Updated link:
https://mvnrepository.com/artifact/javax.persistence/javax.persistence-api/2.2 is here.
and the maven dependency is as below:
<dependency>
<groupId>javax.persistence</groupId>
<artifactId>javax.persistence-api</artifactId>
<version>2.2</version>
</dependency>
For the latest versions javax.persistance is not working instead of that we can use jakarta.persistence to create an entity or resolve the error Cannot resolve symbol 'Entity'. For that need to add the dependency
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>6.1.6.Final</version>
<type>pom</type>
</dependency>
I write an addition to JAX-RS and included the Java EE 6 API as a Maven dependency.
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
Then I have a little test case:
#Test
public void testIsWriteable() {
class SpecialViewable extends Viewable {
public SpecialViewable() {
super("test");
}
}
FreeMarkerViewProcessor processor = new FreeMarkerViewProcessor(null);
assertTrue(processor.isWriteable(SpecialViewable.class, null, null,
MediaType.WILDCARD_TYPE));
}
But I get an error:
java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/ws/rs/core/MediaType
...
If I include Jersey as a JAX-RS implementation instead of the Java EE API everything is fine.
Thanks to BalusC's hint I know what I had guessed: Java EE 6 is only an API without method bodies:
From the java.net blog
You can compile you code with this
jar, but of course you cannnot run
your application with it since it
contains only the Java EE 5 APIs and
does not contain any method bodies. If
you try to run, you would get this
exception:
Exception in thread "main"
java.lang.ClassFormatError: Absent
Code attribute in method that is not
native or abstract in class file
javax/mail/Session
In order to execute a Java EE 5
application, you'll still need a Java
EE 5 container, like for example the
GlassFish application server.
I've tried to add Jersy with test scope but it didn't work.
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-server</artifactId>
<version>${jersey-version}</version>
<scope>test</scope>
</dependency>
How can I test software that depends only on the official Java EE API?
Solution
The provider (Jersey) needs to be placed before the API (javeee-api) in the pom.xml.
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-server</artifactId>
<version>${jersey-version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
Not sure this will solve your problem but GlassFish Embedded provides a Java EE 6 implementation. Add this to your pom.xml:
<project>
...
<repositories>
<repository>
<id>glassfish-extras-repository</id>
<url>http://download.java.net/maven/glassfish/org/glassfish/extras</url>
</repository>
</repositories>
...
<dependencies>
<dependency>
<groupId>org.glassfish.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>3.0.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
...
</dependencies>
...
</project>
It's important to declare the glassfish-embedded-all artifact before the javaee-api.
As for me, JBoss' implementation is smaller than the whole Glassfish, so I'm using:
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee-6.0</artifactId>
<version>${version.jboss-javaee-6.0}</version>
<type>pom</type>
</dependency>
<scope>test</scope> should also do no harm.
An alternative that is JSR provider agnostic is
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>jsr311-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
This allows you to swap Jersey with a different provider. For Glassfish 3.1.2, it uses jersey-server 1.11, which uses jsr311 version 1.1 according to the jersey pom.