Stefan Tilkov wrote:
> On Nov 2, 2007, at 1:45 PM, Stefan Tilkov wrote:
>
>> On Nov 2, 2007, at 1:26 PM, Paul Sandoz wrote:
>>
>>> If you get any feedback can you send a summary of it?
>
> I gave my talk at W-JAX Munich yesterday (the slides are available
> online [1], but I spent at least half the time talking about REST in
> general, so they may not be that interesting to this list.)
>
Nice set of slides.
> Quick feedback from the audience (~60 people, 95% Java developers, half
> of them with good to very good knowledge of REST):
>
> - In general, pretty much everybody liked the overall approach
> - Some people were concerned about how to integrate this with their
> existing, EJB 3-based architectures, esp. regarding the
> SessionBean-based layer they're currently exposing as SOAP web
> services. I don't believe there's any easy way because of the
> architectural differences
Agreed. The architectural constraints are fundamentally different (are
there any for WS-*? as far as i know it ain't got no style :-) )
resulting in different architectures with different trade offs and
desirable properties and thus resulting in wildly different implementations.
Potentially WebBeans may be able to help, not really with support for a
unified programming model but with access to session beans, injection
and transactions.
> - Somebody had written something similar (annotation-based REST API)
> themselves; I'm trying to get them to take a closer look and provide
> some feedback. One of the things they did differently was to annotate
> the methods with the "TypeConverter" (which is similar to
> EntityProvider) to be used.
>
> Based on this last feedback, I'd like to discuss two issues:
>
> - Maybe "EntityProvider" should be named different. I'm aware that
> "entity" is the correct term from an HTTP perspective (although to be
> exact, I think it would have be "entity body" in this context), but from
> a Java perspective it's a little unexpected.
Do you have any names in mind?
> - Maybe there should be a way to override the EntityProvider selection
> based on an annotation on a method. The one case where I believe this
> could be useful is when a MIME type such as "application/xml" is used -
> e.g. the JAXB EntityProvider could handle the default, while some
> specific cases would be overridden.
>
The intention was (as Jervis points out) to associated a entity (body
:-) ) provider with a media type and a Java type. That appears to be
sufficient for most cases, but!, not for the generic types like the
following:
Collection<T>
e.g. where T is a JAXB bean or say a ROME Entry. We have this exact case
raised on the Jersey users list.
We can know T when reading as the type is available from reflecting on
the appropriate parameter of the Java method. But for writing, because
of type erasure, T will be erased.
One way we could solve this is to pass optional information to the
supports method:
supports(Class<?> c, Object o, Type t, Annotation[] a)
If we split things up into reading/writing then it would become:
Reader.supports(Class<?> c, Type t, Annotation[] a)
Writer.supports(Class<?> c, Object o)
(Note that since the HTTP method signatures will not change the entity
provider for reading can be easily cached)
But still for Collection<T> the writer has to check each and every entry
in the collection (it could of course just check the first entry and
assume all others are the same).
An alternative would be to explicitly reference the provider to be used
perhaps by allowing an additional argument on Produce/ConsumeMime or as
has been suggested using another annotation?
Paul.
> Stefan
> --
> Stefan Tilkov, http://www.innoq.com/blog/st/
>
> [1]
> http://www.innoq.com/blog/st/presentations/2007/2007-11-06-JSR-311-W-JAX.pdf
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109