Paul,
See my comments below.
Paul Sandoz wrote:
> 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.
Definately.
>
> - 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.
At least not directly, right. For example, I assume the model will
store the Java methods for
certain HTTP methods. So a developer can get at the annotations on the
Java method indirectly.
>
> - 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.
Thinking about this, I believe the model will end up with methods for
building up the model. I believe
that these methods should throw an exception as soon as the model
detects an error. Therefore, error
reporting might be better handled by the modelers. You would then have
different modelers depending
on the input. So a fully annotated resource would use the Annotation
based modeler. If the input
were a non-annotated resource and some other config file, then a
different modeler would be used.
Ideally these modelers could be used at either tool time or runtime.
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>