According to this NetBeans Jersey web services tutorial RESTFul , you can decide whether to
subclass javax.ws.rs.core.Application, all Rest resources will be automatically registered with this class (Java EE 6)
or
create the REST Jersey network servlet adapter in web.xml.
I always used the second option, which is to add it to your web.xml :
<servlet> <servlet-name>ServletAdaptor</servlet-name> <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>ServletAdaptor</servlet-name> <url-pattern>/resources/*</url-pattern> </servlet-mapping>
Providing your REST web service as an EJB is, in my experience, extremely helpful. You can enter it wherever you want, you can enter your EntityManager into it, and you can even use it as a DAO in some simple situations.
Regarding your question / comment about features and limitations: enterprise beans runs in an EJB container, regardless of whether they are deployed in a war file or not. You can enter JMS ConnectionFactory as a resource in them, as described in this section of the Java EE 6 tutorial. By entering ConnectionFactory, you can send JMS messages. If you want to receive JMS messages asynchronously, you need to define a Message-Driven Bean as described in this section of the above tutorial. I have never tried to extend the same EJB used for a web service in Jersey to implement the MessageListener interface, but I think it should also be possible (if not, you can insert the MDB into your root center without a bean proxy) .
Finally, you can use container-driven transactions as described here . Also from this NetBeans tutorial :
So you can see that the application will use the Java Transaction API (JTA) (transaction type = "JTA"). This indicates that responsibility for managing the life cycle of objects in the context is assigned to the container.
<persistence-unit name="em" transaction-type="JTA">
perissf
source share