Hi,
the (or one) main idea was AFAIK, to support Java 1.4 and J2ME. A
solution could be, that we could create an XML file for the annotations
on every class containing annotations.
Example:
@Path(value="abc")
public class MainResCl {
@GET
@ProduceMime({"text/xml", "application/xml", "application/json"})
public Object getXml() {
return ...;
}
@POST
@ConsumeMime({"text/xml", "application/xml", "application/json"})
public Response create(WhatEverClass entity) {
return ...;
}
@GET
@Path(value="search")
@ProduceMime("text/html")
public Object search(@QueryParam("searchString") String searchString) {
return ...;
}
}
To support this file on Java 1.4 / J2ME, all annotations are removed by
a converter and the following XML file is generated by a tool:
<classes xml..=... what all is needed here>
<class name="MainResCl">
<path value="abc" />
<methods>
<method name="getXml">
<parameters/> <!-- no parameters -->
<GET/>
<ProduceMime value="{'text/xml', 'application/xml',
'application/json'}" />
<!-- other may no better serialisation of arrays -->
</method>
<method name="create">
<parameters>
<parameter/> <!-- parameter has no annotation -->
</parameters>
<POST/>
<ConsumeMime value="{'text/xml', 'application/xml',
'application/json'}" />
<!-- other may no better serialisation of arrays -->
</method>
</method>
<method name="search">
<parameters>
<parameter>
<QueryParam value="searchString" />
</parameter>
</parameters>
<GET/>
<ProduceMime value="{'text/xml', 'application/xml',
'application/json'}" />
<!-- other may no better serialisation of arrays -->
</method>
<methods>
<!-- bean setters are also methods -->
<fields>
...
</fields>
<class>
...
</classes>
Or does some conventions like this?
But I think a runtime environment is not required to support this XML
files; it should be only used for backup, if annotations are not
supported by the runtime envirnment.
Marc Hadley schrieb:
> 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.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>