I would like to have the following kind of resource class work when deployed under RestEasy in JBoss 6:
#Path("Something")
public class Foo {
#EJB
private SomeService service
#GET
public Object frobnicate() {
assert service != null;
// JBoss blows up here
return result;
}
}
Two questions:
It is a limitation of RestEasy, not of the Java EE specification, right, that RestEasy can't inject anything annotated with #EJB?
What have people done to work around this limitation?
My developers are about to surge forward with hard-coded JNDI lookups (e.g. context.lookup(someHardCodedNameHere)) because no one can find a workaround to this specification violation at the present time. I really want to avoid this.
Lastly, I've looked at using CDI, but the story here isn't much better as RestEasy and CDI still aren't talking to each other.
Thanks in advance for any pointers.
The JBoss guys tell me this is being worked on on the trunk. So as of JBoss 6 milestone 3 this is impossible.
Related
I am trying to use a #Transactional method inside a CDI class, instead of an EJB:
#javax.inject.Named
// fails #javax.enterprise.context.ApplicationScoped
// fails #javax.enterprise.context.SessionScoped
// works #javax.ejb.Singleton
// works #javax.ejb.Stateless
public class SomeClass {
#javax.persistence.PersistenceContext
private EntityManager em;
#javax.annotation.PostConstruct
#javax.transaction.Transactional
public void someMethod() {
em.persist(someEntity);
}
}
When I annotate SomeClass with #Singleton or #Stateless, everything works.
When I annotate SomeClass with #ApplicationScoped or #SessionScoped, WildFly 13 displays the following error message:
Transaction is required to perform this operation (either use a transaction or extended persistence context)
I was under the impression that #Transactional works with CDI since Java EE 7. Have I been mistaken? Or am I simply missing some additional configuration?
I'll try to give a short list of things to look when trying to make #Transactional work with CDI, so as to give the answer a bit more value than the comment:
We are discussing javax.transaction.Transactional, not javax.ejb.TransactionAttribute, which works for EJBs!
It does NOT work out-of-the-box in non-JEE applications!
And by JEE applications we mean those running a full JEE application server; Tomcat out-of-the-box does NOT support it!
Beware of classpath problems, specifically make sure no jar containing the annotation javax.transaction.Transactional exists e.g. in WEB-INF/lib, when running in a full JEE application server. If you want to utilize it in a non-full-JEE environment, you will need to have it in the classpath.
#Transactional is implemented as a CDI interceptor by the latest JTA specifications. As such:
It's not there in JEE < 7!
It has the same limitations as any interceptor. E.g. it cannot be called for initializer methods - #PostConstruct [THIS WAS THE PROBLEM IN THIS QUESTION], and it is NOT activated when invoking methods of this object, BEWARE!!!
I am quite confident that more errors may exist!!!
I'm trying to add a RESTful web service with RESTeasy to our application running on JBoss 7.x, using Seam2.
I wanted to use as little Seam as possible, but I need it for Dependancy Injection.
My REST endpoints are as follows:
#Name("myEndpoint")
#Stateless
#Path("/path")
#Produces(MediaType.APPLICATION_JSON+"; charset=UTF-8")
public class MyEndpoint {
#In private FooService fooService;
#GET
#Path("/foo/{bar}")
public Response foobar(#CookieParam("sessionId") String sessionId,
#PathParam("bar") String bar)
{ ... }
}
I'm using a class extending Application. There is no XML config.
I can use the web service methods and they work, but I always get an IllegalStateException:
Exception processing transaction Synchronization after completion: java.lang.IllegalStateException: No event context active
Complete StackTrace
I did try everything in the documentation, but I can't get it away. If I leave out the #Stateless annotation, I don't get any Injection done. Adding #Scope doesn't do jack. Accessing the service via seam/resource/ doesn't even work (even without the Application class with #ApplicationPath).
It goes away if I don't use Dep. Injection, but instead add to each and every method
fooService = Component.getInstance("fooService");
Lifecycle.beginCall();
...
Lifecycle.endCall();
which isn't really a good solution. Nah, doesn't work either...
I have resolved the issue. For some reason (still not sure why, maybe because I tried to use Annotations and code exclusivly and no XML config), my REST service was availiable under a "non-standard" URL.
Usually it'd be something like "/seam/resources/rest".
Anyway, if you have a "custom" path, Seam doesn't know it should inject a context. You need to add <web:context-filter url-pattern="something" /> to your component.xml.
Specifically we already had this tag, but with the attribute regex-url-pattern and I extended it to match the REST URL.
I just started playing around with OSGi services and have the following situation. I have a project which contains 2 services. Service A requires Service B, so I tried to inject the dependent service using
#Inject
private ServiceB svc;
but the framework wont inject. If I setup the following two methods in Service A
and set these methods as "bind / undbind" in my OSGi componentA.xml the framework calls
these methods and I can use Service B in Service A.
public synchronized void bind(IServiceB service)
{
this.svc = service;
}
public synchronized void unbind(IServiceB service)
{
if (this.svc == service)
{
this.svc = null;
}
}
The question is, why does it not work with #Inject ? Sorry if this is a stupid question, I'm quite new to this whole topic. Many thanks in advance!
It looks like you are using Declarative Services, which does not support field injection or the JSR-330 annotations. Field injection has limited utility in OSGi, where services may be injected or "un-injected" at any time. Method injection is more generally useful because it gives you an opportunity to do something when this happens.
However I do urge you to use the annotations for Declarative Services. This will save you from having to write the component.xml by hand.
Could someone help me understand the use of beanInterface parameter of #EJB annotation in JavaEE 6?
I have a situation in which I have an EJB and I want it to be accessed locally and remotely as well.
I have a MyBaseInterface and then both MyEJBLocalInterface and MyEJBRemoteInterface extending MyBaseInterface. Now I have MyEJB which is implementing both MyEJBLocalInterface and MyEJBRemoteInterface.
Now I have a situation in which I want only to access MyEJB locally.
Could I achieve the same with the following?
#EJB(beanInterface=MyEJBLocalInterface.class)
private MyBaseInterface instanceOfLocallyAccessedMyEJB;
Could someone help me understand the use of beanInterface parameter of #EJB attribute?
Thanks.
the beanInterface attribute of the #EJB annotation is used for different purposes depending on the EJB version you are using:
In EJB 3.X you can use it to specify whether you want to use the remote of local reference of the EJB you are referring to, which is your case.
In EJB 2.X it is used to specify the Home/LocalHome interface of the session/entity bean
To sum up, yes. You should be able to use it to inject the desired interface.
This might not be supported in older versions of JBoss though.
Sorry, this questions sounds silly, but after developing some of my RESTful services using Jersey, I asked myself the question -- If REST is just an architecture, and not a protocol like SOAP, why do we need a specification like JAX-RS?
I actually googled for questions like "What is the difference between servlets and RESTful services over HTTP" and to sum up the community answers, I got:
RESTful service development (on Jersey) is an architecture, which inherently uses servlets.
JAX-RS compliant tools like Jersey provide easy marshalling-unmarshalling of XML/JSON data, helping the developers.
REST helps us use GET/POST/PUT/DELETE in a fashion that is far efficient than normal servlets.
According to these answers, I guess if I write a servlet which uses JAXB (for dealing with automatic serialization), and I efficiently use GET/POST/PUT/DELETE in my servlet code, I don't use a tool like Jersey, and hence JAX-RS.
I know I am terribly wrong passing this statement, please correct me.
PS: This doubt actually came in when I had to develop some RESTful services in PHP. After going on through some of the RESTful PHP codes, I realized they are just the same old PHP scripts, with some helper methods for handling XML/JSON.
Why use JAX-RS / Jersey?
Short Answer
Because it makes the development of RESTful services easier.
Long Answer
JAX-RS is a standard that makes it easy to create a RESTful service that can be deployed to any Java application server: GlassFish, WebLogic, WebSphere, JBoss, etc.
JAX-RS is part of Java EE, and when JAX-RS is used with other Java EE technologies it becomes even easier to create your RESTful service:
EJB - A session bean is used as the service implementation and also handles the transaction semantics.
JAX-RS - Used to expose the session bean as a RESTful service
JPA - Used to persist the POJOs to the database. Note how the EntityManager is injected onto the session bean.
JAXB - Used to convert the POJO to/from XML (in GlassFish it can also be used to convert the POJO to/from JSON). JAX-RS by default handles the interaction with the JAXB implementation.
Sample JAX-RS Service
package org.example;
import java.util.List;
import javax.ejb.*;
import javax.persistence.*;
import javax.ws.rs.*;
import javax.ws.rs.core.MediaType;
#Stateless
#LocalBean
#Path("/customers")
public class CustomerService {
#PersistenceContext(unitName="CustomerService",
type=PersistenceContextType.TRANSACTION)
EntityManager entityManager;
#POST
#Consumes(MediaType.APPLICATION_XML)
public void create(Customer customer) {
entityManager.persist(customer);
}
#GET
#Produces(MediaType.APPLICATION_XML)
#Path("{id}")
public Customer read(#PathParam("id") long id) {
return entityManager.find(Customer.class, id);
}
#PUT
#Consumes(MediaType.APPLICATION_XML)
public void update(Customer customer) {
entityManager.merge(customer);
}
#DELETE
#Path("{id}")
public void delete(#PathParam("id") long id) {
Customer customer = read(id);
if(null != customer) {
entityManager.remove(customer);
}
}
#GET
#Produces(MediaType.APPLICATION_XML)
#Path("findCustomersByCity/{city}")
public List<Customer> findCustomersByCity(#PathParam("city") String city) {
Query query = entityManager.createNamedQuery("findCustomersByCity");
query.setParameter("city", city);
return query.getResultList();
}
}
For More Information:
http://blog.bdoughan.com/2010/08/creating-restful-web-service-part-45.html
REST is an architecture, which inherently uses servlets.
No, it is not. REST is an architecture style which can be implemented using servlets, but does not inherently use them, nor inherently have anything to do with Java.
JAX-RS is a JSR Specification defining a Java API for RESTful Web Services.
Jersey is a specific implementation of JAX-RS.
As to whether to use Jersey or try to be compliant to the JAX-RS specification, that's sort of up to you. If it makes your work easier, great! If not no one's forcing you.