Heiko Braun wrote:
>> - 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
>
>
> It shouldn't be too hard. I think Ryan is working on that
> and I am looking at it myself. One of the things that appeared to me,
> is that we need to get rid of the ctor based injection, which the spec
> enforces on root resources.
We need to clarify this, the intent is that per-request life-cycle scope
is the *default* but not the only way. It can be overridden with
per-application (equivalent to the life-cycle scope of stateless session
beans). The RI has experimental support (as Marc referenced in a reply
to Ryan IIRC) for those wishing to experiment with life-cycle and
resource management to see how we could improve things in the JAX-RS API.
We definitely need to clarify the integration with session beans, and in
general for EE integration. I think that is possible without the session
bean life-cycle becoming the default for those that don't want to use it
and vice versa. Potentially WebBeans may be able to help here.
A per-request life-cycle model with constructors makes for a very
natural, simple and dry way to program resources (IIRC a per-request
life-cycle scope is the same for Rails, Django and Restlet). I have used
it many times to good effect in the Jersey examples, no need to worry
about state/threads, no need to repeat myself for common URI/Query
parameters, easy to check for existence of something and throw an 404
exception. IMHO it lowers the barrier of entry for efficiently and
correctly developing RESTful Web applications.
Paul.
> This makes it hard to leverage other
> container semantics. Furthermore we may think of allowing 311 annotation
> on interfaces as Bill already suggested.
>
>
>> - 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.
>
> +1
> 'Entity' is a subject widely used in J2EE, EE and persistence frameworks
> in general. I totally agree, it's confusing.
> Why not call it marshaller/unmarshaller? Or serialzer/deserialzer?
>
>> - 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.
>>
>> 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 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