Issue 8 concerns the addition of a standard resource model API:
https://jsr311.dev.java.net/issues/show_bug.cgi?id=8
"Should we support APIs to allow dynamic configuration of resource
classes not based on annotations - this would provide an alternative
to annotations for platforms where they are not available (ME, earlier
versions of Java, scripting languages). We'll be adding such an API in
the RI, the EG can take a look at it once its ready and decide if its
appropriate for the JSR or not."
The Jersey Model classes can be found here:
https://jersey.dev.java.net/source/browse/jersey/trunk/jersey/jersey/src/api/com/sun/jersey/api/model/
I've also generated the Javadoc for easier browsing and uploaded it
here:
https://jsr311.dev.java.net/nonav/sketches/model/index.html
While we've found these model classes useful in our implementation,
primarily for unifying our internal model of a JAX-RS application for
use by both request dispatching logic and WADL generation code, I'm
not convinced that we need to standardize them in JSR 311. Here's why:
(i) I think that sub resource locators and limited=false @Path
annotations provide everything you need for dynamically matching a URI
to a resource class instance.
(ii) Several JVM-based languages now support specification of runtime
annotations and I think this is a better direction than standardizing
a parallel non-annotation based API for every technology.
(iii) Its would add a lot of new API surface that wouldn't be used by
the vast majority of applications.
With the above in mind I propose to close issue 8 with no action.
Objections ?
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.