On Dec 18, 2008, at 2:40 PM, Bill Burke wrote:
>
> 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
>
What about an application that is a mixture of both EJB and POJO-based
resource classes ? Without the Application class there's no portable
way to obtain the list of classes is there ?
>
> * JAX-RS Pluggability
>
> You really need to define a new SPI for this so that we can obtain
> tighter EJB integration.
There's work in the Servlet 3 EG to define a framework pluggability
API, we were planning to use that.
> The SPI should have:
>
> 1) A way for the App Server to register something within a JAX-RS
> implementation
That's what the Servlet 3.0 pluggability SPI aims to do.
>
> 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
Servlet.invoke ?
>
> 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!)
>
HttpServletRequest ?
> 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;
> }
>
What's the advantage of this vs the existing servlet interface ?
>
> 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.
>
What component is responsible for determining the list of resource
classes ?
Thanks,
Marc.
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.