Dhanji R. Prasanna wrote:
> Hi Paul (see inline),
>
> On 5/21/07, *Paul Sandoz* <Paul.Sandoz_at_sun.com
> <mailto:Paul.Sandoz_at_sun.com>> wrote:
>
> Hi Dhanji,
>
> One of the main advantages of using annotations is that a configuration
> step using an explicit XML deployment descriptor is not required. We can
> make use of the annotation processor.
>
>
> I agree this is a sensible approach. However, I would like to consider a
> few edge cases--such as overriding resource classes, picking up dupes
> etc. Also, in the case of custom externalizers you also have to worry
> about the order of precedence:
>
> @Externalizer(Serializable.class) vs. @Externalizer(String.class)... and
> for content types.
>
> Explicit registration also allows you to incrementally activate or hide
> deployed resources (for example those in a jar from a sister project).
> This may be a 20 case, but I'd say it is significant enough that we
> should talk about it.
>
> Also, xml descriptors are still used to indicate/extend/override
> resource classes in many annotation-based architectures. I wonder if
> they should be considered taboo? Consider JPA for instance, the
> persistence container looks for a persistence.xml/orm.xml or requires
> programmatic registration of entity beans. Even though beans are
> required to be tagged @Entity.
>
> Also consider EJB3, where session EJBs are automagically registered by
> the container, but an xml deployment descriptor can be used to specify
> global interceptor pointcuts, hide certain beans, override security
> options and so forth (I am speaking only of EJB3 descriptors).
> Vendor-specific options can also be externalized neatly in such a
> file--I dont think an xml descriptor with an annotation-based
> architecture (properly used as in JPA) is an evil thing per se. Any
> comments?
>
I guess my main objection is a developer *having* to use such a XML
descriptor to deploy something. If we can avoid the developer having to
use such a thing for the default case it would make it so much easier,
then having that extra 'something' that the developer has to create/use
for the more advanced cases (if required) as you described for EJB.
> For example, in the R2 of SWDP (R2 is the one that we provided as input
> to the group, and i will blog about it soon as it has finally been
> released), we generate a class in a specified package that returns the
> set of root resources (Java classes annotated with UriTemplate whose URI
> template begins with '/'). A container picks up this class from the
> package name passed as an argument.
>
>
> I am curious how you intend to do this in say, a servlet container? Do
> you expect the runtime to Class.forName every class in a jar and test it
> for @UriTemplate? Surely I am missing something--apt can only be used
> over the source code, right?
Yes. The R2 apt processor generates, from source, an implementation of
the ResourceConfig interface. In the web.xml a param specifies the
location of the ResourceConfig impl (see attached for a generated class
from the Simple Servlet example).
> What about manually packaged resources?
Since the ResourceConfig interface is part of the R2 API a developer can
also implement this if they so wish. For the container API we devised,
the ContainerFactory methods takes a ResourceConfig instance or the
package name to where the ResourceConfig instance is located.
>
> As Jerome mentions this also brings into question the dividing line
> between the container and the API. I think it would be good to specify
> something such that deployment can work with all the containers that are
> required to be supported by the JSR (and that can also be used by other
> containers) otherwise this will be a major pain point for developers if
> (by default) deployment is tied to a specific container.
>
>
> I certainly agree, deployment should not be tied to a specific
> container. At the risk of harping on it, JPA accomplishes this with the
> xml deployment descriptor, or alternatively a programmatic configuration
> builder. The same entities can be deployed in a JEE or SE contianer with
> no changes.
>
> Again, my main concern here is not the deployment as such but the
> specification of registering resources (and externalizers, etc.) at the
> API level. Mistakenly adding a leading "/" can lead to a deployed,
> reusable sub-resource. We've thus given a type-unsafe string insert a
> tremendous amount of importance. Im uncomfortable with that.
>
That is a fair point. Given that URIs are so fundamental i hope we could
clearly document such behaviour.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109