dev@jsr311.java.net

Re: JSR311: Issue 8 - Non-annotation model

From: Stephan Koops <Stephan.Koops_at_web.de>
Date: Wed, 25 Jun 2008 18:30:59 +0200

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
>