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
*_at_Context*
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
Stephan