On Apr 6, 2007, at 1:29 AM, Dhanji R. Prasanna wrote:
>
>
> On 4/5/07, Marc Hadley <Marc.Hadley_at_sun.com > wrote:
>
> On Apr 4, 2007, at 9:57 AM, Jerome Louvel wrote:
>
> > 1) Number of packages
> >
> > 11 packages seems way too much for a high-level API that wants to
> > simplify
> > the life of developers. I was expecting one or two compact packages
> > with the
> > list of Annotation types and a couple of helper classes/interfaces
> > at most.
> >
>
> +1. This should be more intuitive than learning SAAJ for instance.
> I am always for anything that one can learn almost entirely via
> Javadoc and hands-on (which 11 packages may make difficult even if
> half can be ignored by the lay developer).
>
Oh no not SAAJ! If we end up like SAAJ we will have truly failed :-)
Given that we can limit our interaction with the DOM API i think we
might be on safer ground :-)
I think the API looks like it is starting achieve one goal, which is
to help focus discussion.
> >
> Yes, I understand that it does look a little daunting at first but
> note that 5 of the 11 are SPIs which I wouldn't expect most users to
> need. Of the remaining 6 the messages and container packages are very
> small and the majority of the API is contained in the remaining four
> packages:
>
> Is there a criteria for choosing what containers get a spi?
>
Not sure i understand the question, can you give an example?
We found the container SPI very useful and quick to integrate new
containers. So we thought it would be useful to present this to the
EG and see it this is a worth while thing to do i.e. is there a
benefit? or is it better to leave this type of thing to each
implementation?
Paul.
>
> > IMO, we should start fresh, with the minimum number of artifacts (a
> > set of
> > annotations basically) and only add support artifacts (classes/
> > interfaces)
> > when absolutely necessary.
> >
>
> +1. I would also like to see a clear separation of the REST
> contract (@URITemplate(..) etc..) from the jsr311 Web services
> framework. It is not uncommon for third party containers to bind to
> a contract but provide a completely separate usage path (example:
> JSR-220 annotations like @PersistenceUnit used in Spring
> framework's JPA support module--without the presence of an EJB
> container).
>
> > 3) HTTP dependent
> >
> >
> We're open to any ideas that would make the API less HTTP specific
> but I'd be wary of introducing some abstract layer that would require
> casting etc to build a HTTP application.
>
> I would also like it to be made HTTP independent without down
> casting each service. Perhaps the container deployment profile
> could choose the desired transport (HTTP/FTP thru config) and a
> developer can program to an abstraction layer? The downside being
> that such abstractions tend to take lowest-common-denominator
> approaches, or end up leaking if they try to support the richness
> of underlying protocols.
>