IS there a way to make RestEasy use Jackson 2+ ? It seems that RestEasy Jackson provider uses Jackson 1.9.9 and it's still a case for ResetEasy 3.
It occured to be quite simple. There are Jackson JAXRS providers in Jackson 2 already.
jackson-jaxrs-xml-provider
jackson-jaxrs-json-provider
jackson-jaxrs-smile-provider
So on the pom.xml
<dependency>
<groupId>com.fasterxml.jackson.jaxrs</groupId>
<artifactId>jackson-jaxrs-json-provider</artifactId>
<version>2.2.2</version>
</dependency>
It's also good to exclude resteasy-jettison-provider to make sure you have no conflicts fo JSON handling.
Unfortunately, it isn't possible to use Jackson 2.x with RESTEasy 2.x because the integration of Jackson 1.x is fairly tight.
However, RESTEasy supports Jackson 2.x as of version 3.0-beta-5 - please see this issue for details or do a repository search if you're using Maven.
Related
I need to use cache system on my web application under JBoss EAP 7.2
My purpose is to configure cache at application level, therefore no server configuration should be required.
The cache provider is Infinispan
This is my pom.xml:
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-hibernate-cache-v53</artifactId>
<version>${version.infinispan}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-core</artifactId>
<version>${version.infinispan}</version>
<scope>provided</scope>
</dependency>
${version.infinispan} is 9.3.3.Final, the version shipped by JBoss EAP 7.2 (see also https://access.redhat.com/articles/112673)
When I try to start the AS, i have got this error:
[...] a class it references was not found: org.infinispan.manager.EmbeddedCacheManager
Guess I have to configure it on manifest or something else,
however I haven't found how.
Any help would be appreciated
EDIT
On RedHat page is reported the following sentence:
Infinispan is delivered as a private module in EAP to provide the caching capabilities of EAP. Infinispan is not supported for direct use by application
Does it mean that I can't use infinispan cache directly ?
If you want to add caching to EAP for your own data, you should use JBoss Datagrid (downstream) or Infinispan (upstream) modules, so that you have full control over the version and capabilities of the caching layer. See this quickstart to do just that.
The version that ships with EAP is fixed and does not contain all the Infinispan modules, so we recommend against directly using this.
I searched a lot regarding this. Still I didn't get any definite answer for this. Someone Please explain me on how to do this. Please mention the compatible versions also.
You can use the Selenium 2 java robot framework.
Just add the following dependency to the pom file (if you use maven)
<dependency>
<groupId>com.github.markusbernhardt</groupId>
<artifactId>robotframework-selenium2library-java</artifactId>
<version>1.4.0.6</version>
</dependency>
If you don't use maven, just download the jar from
https://github.com/MarkusBernhardt/robotframework-selenium2library-java
(You can find a link there to the jar with the dependencies in it)
This is compatible with all jython versions (since it's java based)
I have prepared a sample camel rest web application. When i deploy it in Glassfish, i'm getting error as like below. How to resolve this?
<ns1:XMLFault xmlns:ns1="http://cxf.apache.org/bindings/xformat"><ns1:faultstring xmlns:ns1="http://cxf.apache.org/bindings/xformat">java.lang.ClassCastException: com.sun.jersey.core.spi.factory.ResponseImpl cannot be cast to org.apache.cxf.jaxrs.impl.ResponseImpl</ns1:faultstring></ns1:XMLFault>
The WAR file you're deploying probably contains Apache CXF. Both Jersey and CXF are JAX-RS implementations and Jersey is built into Glassfish. Having two JAX-RS implementations on the classpath is causing a problem.
Assuming that you're using Maven, try replacing your CXF dependency with a dependency on the JAX-RS API or on Jersey. Mark the dependency as <scope>provided</scope> to avoid including it in your WAR file since Glassfish will provide it.
We have a library that contains small additions to functionality provided by JSF (things like additional ResourceHandlers).
As it uses JSF classes (from javax.faces.* packages), it naturally must depend on the JSF API. The library is packaged as a Maven project, and depends on com.sun.faces:jsf-api.
This works fine for compiling, and for use in projects that use Mojarra. However, if we include the library in a JSF application that uses MyFaces, we get errors, as described in Exception: could not find Factory: javax.faces.context.FacesContextFactory .
Apparently, if an application uses MyFaces, it must use myfaces-api.jar and myfaces-impl.jar (or the corresponding Maven deps), and not jsf-api.jar or jsf-impl.jar.
This leaves me a bit confused.
Why do Mojarra and MyFaces use different API jars? Both implement the same API (JSF), so shouldn't they use the same API jars?
I thought the whole point of having seperate "api" and "impl" jars was that only the "impl" part has to be switched to use a different implementation. Did I misunderstand something?
More concretely: What is the right Maven dependency for a library that should only depend on the JSF API? Right now, we depend on jsf-api, and projects that use MyFaces must use <exclusions> to throw out jsf-api and include myfaces-api. That works, but surely there is a better way?
Maybe they use different API jars because of some distribution / licensing issues. I dont know exactly.
But the API is the same, your FacesContextFactory can be found in the myfaces-api jar as well.
I would try to create profiles (or even two separate modules) that define the according set of dependencies. Using profiles you would need to activate one of them manually to switch the dependencies. With modules both would be built but the question where to put your sources will arise but the dependencies can be set to compile so it will be easier to create a deliverable.
It may be worth looking at Gradle here - I always had issues with projects that need to adopt different sets of dependencies and I've seen some nice features there.
Sorry I have no good solution found yet for this setup either.
edit: while thinking: you may just create two branches in your SCM and merge changes between them? (beside the dependencies of course)
Why do Mojarra and MyFaces use different API jars? Both implement the
same API (JSF), so shouldn't they use the same API jars?
They are seperate implementations of JSF. JSF is a Specification. See this Question.
More concretely: What is the right Maven dependency for a library that
should only depend on the JSF API? Right now, we depend on jsf-api,
and projects that use MyFaces must use to throw out
jsf-api and include myfaces-api. That works, but surely there is a
better way?
What you are terming "The JSF API" is the Sun/Oracle implementation of it (Mojarra). The dependencies for these are:
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.1.2</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.1.2</version>
</dependency>
As far as I understand Google Guice 2.0 is out not so long ago. But I see that central repo still has outdated 1.0 version. Please, tell where can I find maven2 repository with Google Guice 2.0.
Guice 3.0 is now available on central. You'll need the following to depend on it.
<dependency>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>
<version>3.0</version>
</dependency>
Sadly, they haven't uploaded source jars, and the class files have been compiled with Java 6. This may be a show-stopper for you…
Guice 2.0 is now available in the official google-maven-repository. To use it, add the following to your pom.xml inside of the <dependencies> tag (you'll need to add one if there isn't one):
<dependency>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>
<version>2.0</version>
</dependency>
You shouldn't need to, but you can add a reference to the official google-maven-repository in your pom.xml by following the instructions here.
Since I don't see Guice 2.0 in central I thought I'd include a stable repo where I found it:
https://repository.jboss.org/nexus/content/repositories/thirdparty-uploads/
The Grails OpenID plugin references http://guice-maven.googlecode.com/svn/trunk/ but that doesn't have it (currently).
They will put it to the central repository soon, as they promised here: http://groups.google.com/group/google-guice/browse_thread/thread/6707a887ed5ef2e3
Never mind. Guice-maven is intended to provide this.
Until it reaches the central repository, I've been getting it from here: http://guice-maven.googlecode.com/svn/trunk