Doug Kohlert wrote:
>> - 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.
If java.lang.reflect.Method is available from the underlying concrete
model, then yes.
>>
>> - 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.
>
You make a good point, the abstract error reporting needs to refer back
to the concrete model for producing meaningful errors.
The advantage to having a separate holistic validation step, rather than
when the abstract model is being built, is that a set of errors/warnings
can be reported using one set of code (also, some errors/warnings may
only be produced when all information is available). It is especially
important that we try to report as many errors as possible in one go
because sometimes resources are only processed at runtime, which is the
case for resources returned by sub-locators.
However, i suppose there are some catastrophic errors when building the
abstract model so i think it would be good to categorize what might be
fatal building errors.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109