Hi Paul (see inline),
On 5/21/07, Paul Sandoz <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?
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? What about manually packaged resources?
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.
Dhanji.