I am using CDI to inject things into my JAX-RS MessageBodyWriters and MessageBodyReaders. This works well for the MessageBodyWriters but not for the MessageBodyReaders. Also, Interceptors work on the writers, but not on the readers.
Can anyone explain whether this is desired behavior or what I might be doing wrong?
I am using JBOSS 6, so Weld is my CDI implementation.
Jan
Ha! Never mind - I totally forgot that I was instantiating the reader directly in my testing code. When I obtain e reference via CDI, the injection works fine -> http://facepalm.org
Related
I'm trying to get rid of XML in my project.
I already tried to add this:
JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
sf.setResourceClasses(CustomerService.class);
sf.setAddress("http://localhost:9000/");
sf.create();
to my Activator class, but my bundle wont start with this.
So, how usually people configuring endpoints?
(Sorry, no code, just some high level insights from my experience/projects)
I use jersey and its integration into the OSGi environment. I.e. org.glassfish.jersey.servlet.ServletContainer to which I register all jax-rs resources. This way, I can use whatever HTTP server implementation is available (for example, jetty) and configure it via the OSGi system environment properties.
For simplicity, I re-register annotated OSGi (declarative) services as singleton resources/endpoints into that ServletContainer.
Maybe, CXF has also a similar approach.
I've found conflicting answers to this question and I've failed to successfully run an example.
Can JAX-RS be implemented using Servlet 3.0 (in particular, Tomcat 7) with annotations, only, without having to implement another Servlet Container?
If no, please explain why the following quote from this book is either, incorrect or I'm interpreting it, wrong.
Because this example deploys within a Java EE application server or
standalone Servlet 3.x container, all we need is an empty web.xml
file. The server will detect that an Application class is within your
WAR and automatically deploy it. (RESTful Java with JAX-RS 2.0, Bill Burke)
To clarify what I don't need help with... I've, successfully, implemented JAX-RS in Tomcat 7 with Jersey using a web.xml, so, I don't need any explanation of how to do so. Also, I'm fully aware that other Java EE/Servlet Containers (TomEE, Glassfish, Jersey, Websphere, etc...) are all JAX-RS aware out of the box. I just need to know if I'm chasing my tail trying to get Tomcat 7 (Servlet 3.0) to work with JAX-RS without adding a Servlet Container and without web.xml entries.
In a Servlet environment, Jersey runs as a servlet or servlet filter. No way around that. So how does it work without declaring it in the web.xml? Two main components to this functionality
Programmatic registration of Servlet components (i.e. servlets and fitlers). You can do a Google search, and you should find some hits of examples.
Servlet pluggability introduced in Servlet 3.x. How it works is you implement a ServletContainerInitializer, list that implementation in a file named javax.servlet.ServletContainerInitializer, and put that file in the META-INF/services directory of the jar. The servlet container should scan jars looking for this file. When it finds on, it sees the implementation, finds the implementation, instantiates it, then calls it onStartup method.
Jersey has such an implementation of the SevletContainerInitializer in the JerseyServletContainerInitializer. This class is located in the jersey-container-servlet jar. So you need this jar for this to work. If you look at this method, this is where you will see the programmatic registration of the ServletContainer (the same one that yo would declare in the web.xml
But that's not all. We still need some way of configuring our application, at the least declare the servlet mapping. That's where the Application class and the #ApplicationPath annotation come in. We would extend the Application class and and annotate the #ApplicationPath("/path") where "path" is the same as the servlet mapping in the web.xml
#ApplicationPath("/api")
public class MyApplication extends Application {}
This is standard JAX-RS. With Jersey normally instead of an Application class, we use a ResourceConfig class (which is a subclass of Application)
#ApplicationPath("/api")
public class MyApplication extends ResourceConfig {
public MyApplication() {
packages("package.to.scan");
}
}
You can see more about Jersey deployment options in a Servlet 3.x environment, here.
It should also be noted, that a Java EE server has the JAX-RS implementation, so we only need to add the javaee-api jar to our application as provided dependency. But in a servlet container, we need to provide our own implementation, Jersey being such an implementation.
If you are using Maven, the main dependency you'll need is this one
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>${jersey2.version}</version>
</dependency>
This will pull a bunch of other jars in. You you aren't using Maven, then you can download all the jars here (the JAX-RS 2.0 RI bundle), and put all those into your application.
See Also:
How to use Jersey as JAX-RS implementation without web.xml?
I am using jax-rs for restful service. And I am trying to find out how I can use a contextlistener for webapp ? I am specifically using jax-rs 2.0 . Any suggestions on how to go about it , would be helpful. Thank you.
I'm not sure what linkage problem you have with servlet.jar. It should actually be in your classpath already, since JAX-RS uses it, too.
Also, if you use a framework such as Hibernate (or another JPA implementation for your MySQL database access), you may want to rely on the events that they trigger after insert/update/delete operations: see https://docs.jboss.org/hibernate/orm/4.0/manual/en-US/html/events.html for example.
Just my 2c.
I am trying to unit test message handlers for NServiceBus 4.0.4. The bus is configured to use JSON serializer in the application using the Configure.Serialization.Json(); method call.
Whenever I call the Test.Initialize() method from the unit tests assembly I get the following exception: System.Configuration.ConfigurationErrorsException : Multiple serializers are not supported. Please make sure to only enable one
I tried calling Configure.Serialization.Json() and Serializers.SetDefault<JsonSerialization>() before calling the Test.Initialize() method without any success.
Does anyone know what am I doing wrong? All examples I see on the internet do not mention any Configure calls.
This issue has been reported previously here and looks like it will be fixed in the next NServiceBus build (both 4.0.5 and 4.1.0)
A workaround is to explicitly disable the xml serializer when enabling the json one.
Configure.Serialization.Json();
Feature.Disable<XmlSerialization>(); // hack to make NSB unit tests work
I try to deploy ejb2 on weblogic 10.3 but I face a problem the deployed ear can't see new methods added to any ejb session bean. I added the method to remote interface and I added the implementation to bean class. I hope anyone can help. Thanks
I believe WebLogic 10.3 supports EJB3, so you'll have to do some modification. You already have the evidence to prove it.
As you say the old EJBs are working, but it's not reflecting updated methods - I think this is cached.
Drill down on your server to the following path or a similar one
DefaultDomain\servers\DefaultServer\cache\EJBCompilerCache
There will be many folders in there with random names like ff7i19ot3cg6 and l443b5vws35h
Clear out all these folders and redeploy the app