I just want to clarify the requirements on the Netbeans side.
For NetBeans, we need the ability to create the model directly from the
source files
instead of class files. NB has its own infrastructure called Retouche
for doing this which
is based on javac and javax.lang.model. In addition, we need the
ability to update
the model dynamically as the users modify the source code.
I think one way to do this is provide some spi that will allow us to
plugin NB's version
of the model builder. Note that the validation should be a layer above
that so we don't
have to reimplement the same logic in the model builder.
Peter
Doug Kohlert wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>