Re: Lifecycle options

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Tue, 10 Jul 2007 11:30:55 -0400

On Jul 10, 2007, at 6:42 AM, Dhanji R. Prasanna wrote:
> 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...
> }
I like the general direction of deferring to a factory for resource
class instantiation, it offers a nice interception point for plugging
in other frameworks.

JAX-RS could define a couple of standard factories (per-request and
singleton) but it would be left open ended for other frameworks to
supply their own. Each factory can define its own set of restrictions
on the resource classes it can create and we'd need to do that for
the standard ones we define. Would it be reasonable for the default
factory to vary depending on the deployment environment, e.g. in an
EE container you'd get the EE factory, in an SE environment you'd get
a less capable SE factory ?

As Paul suggests we could use meta-annotations to achieve this rather
than the above so, e.g., you could write:

public class PersonResource {

where @Singleton is defined as:

public @interface @Singleton {}

and SingletonFactory is defined as

public class SingletonFactory implements ResourceFactoryProvider {
   // ResourceFactory methods

Somebody can then write a @SpringManaged annotation with an
associated SpringFactory and developers would annotate their resource
classes with @SpringManaged to take advantage of that framework. The
extra level of indirection provided by the meta-annotation approach
lets you group together a set of annotations without requiring them
to be echoed on every resource class.

Of course the tricky part is getting the ResourceFactoryProvider
interface right since a factory requires access to all the resources
that can be injected into constructor fields. We'd also need to
define the lifecycle and scope of a ResourceFactory instance.


Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.