On Mar 7, 2008, at 2:10 PM, Bill Burke wrote:
>
> Marc Hadley wrote:
>> It would bother me if we added new targets but didn't define what
>> should happen if a developer uses those targets. E.g. if we added
>> FIELD as a target for @PathParam then I think we'd have to require
>> implementations to support that annotation on resource class
>> fields. That's fine for the per-request resource life cycle but
>> what about singleton resources...
>
> IMO, not a big deal. Just say that the annotations are probably
> unsupported on a singleton. EJB spec has similar documented
> constraints. For example @PersistenceContext(EXTENDED) is not
> allowed to be injected into SLSBs.
>
I guess. Implementations would still have to add support for field-
base injection of request data though.
> Anyways, why not document it as a placeholder for features the
> committee couldn't agree on or didn't have time for, but that may be
> introduced as value-adds through vendor implementations.
>
That's what I intended with my suggestion for a meta-annotation, see
below.
> FYI, I wanted to use it for POJO parameter mappings and form object
> mappings. Gives me a chance to see how users like the feature and
> whether or not its something that should be added to the next
> version of the spec. I also think per-request resource field
> injection might make things easier for an async model I've been
> thinking of. I don't know if its better until I try it. The big
> problem with Java EE in general is that it is a horrible place to
> innovate portably, which is why proprietary projects like Spring
> exist in competition to it.
>
>
>> @Source(HEADER)
>> public @interface HeaderParam {
>> String value();
>> }
>> The spec would specify the relationship between @Source and the
>> target annotation value. It would also specify where to look for
>> @Source-annotated annotations but wouldn't restrict where else they
>> could be used. Then you could add:
>> @Source(HEADER)
>> public @interface BillsInnovativeHeaderParam {
>> String value();
>> }
>
> This doesn't help as I would end up with duplicate @*Param
> hierarchies where the only difference is the @Target. Might as well
> not even use JAX-RS annotations and have my own proprietary apis.
>
But if you used the meta-annotation and a subsequent version of the
spec expanded the places that an implementation was required to look
for that annotation then your new annotations would essentially be
grandfathered in. I.e. an application using the annotations you define
would become portable when the scope of the meta-annotation was
expanded to cover the annotations you define.
What I want to avoid is using the annotations defined in JSR 311 in
places not covered by the spec because that could be quite confusing
for developers. I'm less worried about a meta-annotation since those
are generally hidden from developers.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.