Hi Doug,
Currently Jersey duplicates logic for processing a resource class. WADL
is generated from APT of a resource class. A runtime model is generated
from Java reflection of a resource class. NetBeans uses their own
abstract syntax tree for processing a resource class. This is a source
of bugs for both reasoning on a resource class and validating to report
warnings/errors.
The following are what i think should be the high-level requirements:
- one model that can be used at tooltime or runtime for WADL generation,
at tooltime for NetBeans and
runtime for the runtime resource model. Although abstract i suspect it
will be a requirement to
return Java reflection information or easily obtain the appropriate
Java method or Java constructor
from the abstract information.
- ensure a model can be created from non-annotation-based sources. For
example an XML document could be
supplied this document declares equivalent information to that of
annotations. Thus annotations
should be not exposed in the model API.
- validate a resource to provide very clear errors and warnings.
Validation should work from the
abstract information. Validation should not fail on the first error or
warning, as many as is capable
should be reported. Such implementation work should also help improve
the clarity of the
specification or find non-specified/under-specified areas. This is
very important as this is likely
to be the first source of errors/warnings the developer is likely to
see so we need to be as helpful
and as friendly as possible. Any validation should also be aware of
extensions by implementations,
for example Jersey currently supports additional method signatures for
HTTP methods.
Paul.