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.
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.
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com