Aggregation(?) of "Targets for _at_*Param, _at_DefaultValue, _at_Encoded"

From: Stephan Koops <>
Date: Thu, 20 Mar 2008 21:19:16 +0100

Hi all,

*aggregation of discussion for root resource classes*
if I collect the disussion points of the last days, I think we can
aggregate this to the following points realting to @*Param:

    * Allow @*Param on parameters, fields and setters (setters are not
      required to be thread save)
    * singelton lifecycle runtime environments must reject root resource
      classes (rrcs) with annotated fields or setters. (Other
      possibilities with Numbers and CharSequences are to complicated)
    * This is close to (iv) of the proposals of Marc.

Paul, Marc, is this right? Did I forget something important?

BTW: What about other instance fields? They may cause trouble in
singelton lifecycle rrcs -> reject rrcs with any instance field?

But there are questions for
*non-root resource classes:*
While thinking about (if all agree with the point above):
Non-root resource classes have app developer managed lifecycles (see
spec). For them I propose (not discussed):

    * If the lifecycle is per-request (or the app developer otherwise
      ensures that only one thread uses it the same time, e.g. pooling):
      the app developer can use @*Param on parameters, fields and setters.
    * If the lifecycle is singelton: the app developer must only use
      them on method parameters.
    * It is the responsibility of the app developer to use them right
      here. It is good to put a related warning in the javadoc of all
      @*Param, and also in the spec.

Independent of the results for @*Param, there is the same question for
Must instances be thread save or not? Neither the specification nor the
javadoc defines anything.

    * In rrcs it depends exactly on the used lifecycle: if singelton,
      than @Context annotated fields must be thread save, if not, than not.
    * non-root resource classes may be singeltons or not, independent of
      the lifecycle of the rrcs (app developer responsibility, see above)

Here a definition is needed, if a non-root resource classses can
estimate a thread save implementation of UriBuilder, SecurityContext and
so on. BTW: This must kept in mind also for @Resource of JSR-250 (and
perhaps others).
A possibility is to not require thread safety; singelton non-root
resource classes must not use them on fields and setters (the same as
for @*Param for singelton non-root resource classes, see above); the app
developer has the responsibility to ensure, that he use it correct. This
is consistent to the proposal above.

best wishes