On Jun 25, 2008, at 12:30 PM, Stephan Koops wrote:
>
> the (or one) main idea was AFAIK, to support Java 1.4 and J2ME.
Support for versions prior to J2SE 5.0 is an explicit non-goal, hence
the current reliance on annotations and use of generics. We were
required to "investigate whether a subset of the API can be made to be
used with Java ME" but given the server-side nature of the API I think
a reasonable answer is "no".
> 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.
>
That is issue 18:
https://jsr311.dev.java.net/issues/show_bug.cgi?id=18
Marc.
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.