|
|
||
Marc Hadley's BlogNew Jersey FeaturesPosted by mhadley on September 07, 2007 at 09:05 AM | Comments (0)I recently merged the experimental "resourcefactory" branch back into the main Jersey trunk. The new code includes the following features and changes:
Details on these changes below Lifecycle ChangesPrior to the merge the Jersey runtime would create a single instance of a resource class and use that for all requests. Resource classes had to be re-entrant and thread safe. Following the merge the default scope for a resource object is per-request, i.e. the Jersey runtime creates a new instance of a resource class for each request. This change brings Jersey back in line with the current JSR 311 specification which requires a default per-request life-cycle. The old behavior can be recovered by annotating a resource class with the Non-empty ConstructorsPrior to the merge a resource class was required to have a zero argument constructor that the Jersey runtime would use when creating the singleton instance. Following the merge this requirement has been relaxed such that constructors can now have arguments. This in conjunction with the change to a default per-request lifecycle allows a more natural use of constructors to perform instance initialization, e.g.: @UriTemplate("entries/{id}")
public class Entry {
EntryEntity entity;
public Entry(@UriParam("id") String id) {
entity = findEntryEntity(id);
...
}
@HttpMethod
@ProduceMime({"application/json", "application/xml"})
public EntryEntity getEntity() {
return entity;
}
}
The arguments allowed in a resource class constructor depends on the resource provider used to create an instance of the resource class (see the description of the new SPI below). For default per-request resource classes you can use any combination of parameters annotated with Resource Provider SPIThe new resource provider SPI allows plugging-in of custom resource class factories and is used internally to support the per-request and singleton life-cycles. If you're not planning to develop a new resource provider you can safely stop reading here unless of course you are curious as to how the above features are implemented. A resource provider is responsible for creating instances of resource classes for the Jersey runtime to use. A resource provider implements The Jersey runtime identifies the resource provider to use for a particular resource class by examining the annotations on that resource class. It examines each class-level annotation in turn looking for a @Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@ResourceFactory(SingletonProvider.class)
public @interface Singleton {}
Note the The Its hoped that this SPI will support integration of Jersey with a variety of frameworks. Let us know if anything is unclear or needs improvement. Bookmark blog post: CommentsComments are listed in date ascending order (oldest first) | Post Comment | ||
|
|