Dhanji R. Prasanna wrote:
>
>
> On 7/10/07, *Paul Sandoz* <Paul.Sandoz_at_sun.com
> <mailto:Paul.Sandoz_at_sun.com>> wrote:
>
> Dhanji R. Prasanna wrote:
>
>
> What do you mean by 'canned cases'?
>
>
> If you look below at the singleton example, Im saying we could provide
> that out of the box. =)
>
OK, so scoping rules would still be specified by 311, just differently.
> Surely we have to specify some scoping rules for portable deployment?
> And since a developer will write a POJO for a particular scope
> presumably the scope and the POJO go together?
>
>
> Here's a simple idea off the top of my head:
>
> @URITemplate("/person/{id}")
> @ProvidedBy(PersonFactory.class)
> public class PersonResource {
>
> //http methods and so on...
> }
>
>
> //this factory is semantically a singleton provider but JaxRs knows
> nothing about scope nor forces a developer to learn a new IoC profile
> public class PersonFactory implements ObjectProvider<PersonResource> {
> private final PersonResource res = new PersonResource(...);
>
> public PersonResource get() {
> return res;
> }
> }
>
What instantiates the factory? What is the scope of the factory? Is
there only one instance of the factory per Web application or per JVM?
It seems at least for a common case that you have made the developer do
more work.
But yet this approach can overcome the restriction you pointed out when
using an empty constructor, although it is not entirely clear to me
where the factory would get information to pass to the constructor that
an empty constructor could not get, unless there is some container
specific context in play that is unspecified by 311, then it is not
clear to me how 311 can specify ProvidedBy without introducing more
APIs/SPIs.
>
> Now it is easy to conceive of:
>
> @URITemplate("/person/{id}")
> @ProvidedBy(SpringPersonFactory.class)
> public class PersonResource {
>
> //http methods and so on...
> }
>
> Or perhaps a general ResourceFactory that can be implemented to hook
> into spring.
>
BTW in the original API/SPI we had a resolver SPI that allows pluggable
container-based resolving according to scope e.g. i implemented HTTP
session scope as a test using a proprietary annotation on a root
resource class. (However, i do not think we should encourage the use of
session scope since it breaks an important constraint in REST.)
JAX-WS impl supports pluggable scope by use of a meta-annotation [1].
> I'll post a more detailed example on why we should let spring (or
> <insert_ioc_flavor_of_month>) create these objects in the 3rd party
> containers thread.
>
OK. I don't disagree with you on letting spring etc create instances.
But i am not sure we have to do anything in 311 and it could be left up
to 311 implementations to decide how best to integrate with Spring,
given that Spring is not part of EE.
Paul.
[1]
https://jax-ws-commons.dev.java.net/http-session-scope/
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109