Marc Hadley wrote:
> On Dec 8, 2008, at 3:35 PM, Joel Smith wrote:
>
>>
>> Why is metadata being defined to provide for a JNDI name which will be
>> used to bind the JAX-RS/EJB instance?
>>
> To solve problem (i) described below. Basically a JAX-RS runtime needs a
> portable way to get an instance to dispatch requests to.
>
Am I too late to discuss this? Sorry... I didn't realize 1.1
discussions were going on and was ignoring my email folder on this.
I don't like any of your current proposals. There's really 2 orthogonal
issues here:
* JAX-RS integration with EJB. What you want the user experience to be.
* JAX-RS thirdparty pluggability into Java EE. (i.e. Plugging in JBoss
RESTEasy into Glassfish and overriding Glassfish's implementation).
This inadvertently effects EJB integration.
You man want to allow thirdparty unpluggable implementations via Servlet
adapters, but disallow integrated thirdparty pluggability (as this would
require defining an SPI).
Let's discuss them both
*JAX-RS + EJB Integration*
There should be tighter, more seemless integration of JAX-RS and EJB.
it should be as simple as using JAX-RS annotations on an EJB
class/interface. There should be no requirement to use the Application
class. In fact, it should be disallowed.
There's really 3 scenarious you need to define:
1. A JAX-RS annotated EJB deployed within a standalone JAR
2. A JAX-RS annotation EJB deployed within a JAR within an EAR
3. A JAX-RS annotation EJB deployed within a JAR within WEB-INF/lib
The issues are:
a) What is the root context?
b) I can't think of any more
* JAX-RS Pluggability
You really need to define a new SPI for this so that we can obtain
tighter EJB integration. The SPI should have:
1) A way for the App Server to register something within a JAX-RS
implementation
2) A way for JAX-RS to inject JAX-RS specific objects into fields of a
component
3) A way to dispatch web requests to the JAX-RS implementation
4) A way to get information about the HTTP request (I don't think we
want to require JAX-RS implementations to provide an HTTP server
implementation!)
You will need a Registry and Dispatcher interface for #1 and #3. Since
in EE 6 EJBs are also Web Beans, the Web Beans specification can help
with #1 and #2.
public interface ImplementationInitialization
{
void initialize(WebBeansContextWhateverItsNameIs context);
}
public interface RegistrationContext
{
String getBaseURI();
Class getScannableClass();
Object getTargetForRequest();
}
public interface Registry
{
void register(RegistrationContext context);
void unregister(RegistrationContext context);
}
public interface Dispatcher
{
void dispatch(HttpServletRequest request, HttpServletResponse
response) throws IOException;
}
All JAX-RS injection annotations could be defined in terms of Web Beans.
The ImplemenationInitialization interface would be a callback by the
App Server at startup to allow the JAX-RS implementation to register its
Web Bean annotation handlers. (I don't know this SPI off the top of my
head).
The JAX-RS implementaiton would receive callbacks to register(). From
the registration, the JAX-RS implementation can find out the base uri
and the scannable class for the component so it can set up its
registries. The getTargetForRequest() returns an object that JAX-RS can
reflect on to invoke the appropriate resource method.
FYI, I have a similar SPI so that I can support seemless Spring and Seam
integration. Its a little different though because I have JAX-RS
responsible for injecting JAX-RS specific things rather than relying on
Web Beans. I can expand on that SPI if you like.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com