Hmm, I registered for the user message digest but I guess that is a different list.
Thanks for the response. It makes perfect sense that the
WebApplication would need a have a definitive list of resource classes when it
initializes. Using the list of resource classes it can introspect them,
discover the list of URI templates, and define optimize routing rules for
requests to the resource instances.
I think what I will do now is that each time a new ResourceClass
needs to be added to or removed from an existing WebApplication I will simply
discard the existing WebApplication and create a new one with the proper
resource instances and classes. At first I was concerned about doing this
because I was concerned about losing state information and at the surface it seems
inefficient. On second thought REST services are by definition stateless and
the act of recreating a new WebResolver would not entail that much overhead if
I use a copy constructor. I’ll try this approach and inform the list on how it
works out.
Thanks
Aaron
----- Original Message ----
From: Paul Sandoz <Paul.Sandoz@Sun.COM>
To: users@jersey.dev.java.net; nickmalthus@yahoo.com
Sent: Tuesday, July 17, 2007 6:07:41 AM
Subject: Re: Embedding Jersey
> Is
> there any other approach that I could use to dynamically register
> resource classes with a Jersey WebApplication when all of the resource
> classes are not known in advanced?
>
How about i add the following methods to WebApplication:
/**
* Register resource classes to an initiated Web application.
* <p>
* This method enables a container to dynamically register
* further resource classes to those resource classes that
* were registered at initiation.
*/
register(Set<Class> resourceClasses)
register(Class... resourceClasses)
Will that work for you?
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/