(cc'ing Andrei for NB JPA support mechanism)
Peter Liu wrote:
> Paul Sandoz wrote:
>> Hi Peter,
>>
>> Peter Liu wrote:
>>> Jakub, thanks for the info,
>>> It looks like in order to use the validator at design time, we will
>>> first need to implement a
>>> design time version of the abstract model. I haven't kept up with the
>>> resource model, but I remember that it was designed around java
>>> reflection.
>>> Is it still the case?
>>
>> Yes, more specifically it is designed for runtime with Class and
>> Method objects available. The use-case being one could specify the
>> meta-data in alternative ways than annotations e.g. in an XML file.
>>
>>
>>> For NB, since we are working with source files,
>>> java reflection information is not available.
>>>
>>
>> Does not NB compile the source anyway to produce compile errors? Is
>> there any way to hook things up that way? Are there any other NB
>> plugins that highlight app specific runtime time errors when editing
>> source?
> Yes, it does but not to the point where class files are generated.
> Hooking the validator up to that compilation process is exactly what I
> am thinking.
> I would like to see errors shown in the editor like you see with a
> normal pojo while an user is editing the file.
I believe NetBeans JPA validation does have the capability of showing
JPA error/warning stripe quite instantly. I suspect that there are some
JPA validation or model hooks that NB persistence support implement.
Maybe Andrei (cc'ed) could shed some light on the JPA validation mechanism.
> Alternatively, we can do the validating during compile time so
> developers at least see the errors in the output window. But it would
> be very nice if we can do the first approach.
> Nam, do you think we can at least run the validator during build time
> and somehow link the errors back to the source file in the output window?
Definitely, we would need an ant task to invoke the validator.
>>
>> As i said before we could make the abstract model generic such that a
>> validator could be written independent of the actual types mapped to
>> the generic types.
>>
>> One concern i have is that we don't have much time to work on this to
>> make things more generic. Plus there are still some open areas for
>> validating method parameters we need to work on so i am unsure if
>> validation can be fully independently shared between source and
>> runtime-generated abstract models. But perhaps if you see value in
>> this approach perhaps we could work together?
>>
> I would definitely like to see the abstract model be more generic so
> we can reuse the validator instead of implementing our own validator
> because it would be hard to keep
> it in sync with the spec. We definitely won't have time during the NB
> 6.1 time frame to work on this. Perhaps we can work together on this
> for NB 7.0. We can work on
> the implementation for NB if we work out the generic abstract model.
>
>> Paul.
>>
>>> Peter
>>>
>>> Jakub Podlesak wrote:
>>>> Hi all,
>>>>
>>>> There is validation of resource models implemented in
>>>> [com.sun.ws.rest.impl.modelapi.validation].
>>>> A very basic validation currently being invoked
>>>> before runtime resource models get created is placed in
>>>> [com.sun.ws.rest.impl.modelapi.validation.BasicValidator]. People
>>>> can implement their own validators by extending
>>>> [com.sun.ws.rest.impl.modelapi.validation.BasicValidator.AbstractModelValidator]
>>>>
>>>>
>>>> The idea is, that a validator checks resources and
>>>> keeps a list of all issues found. Issues could be fatal or just
>>>> warnings.
>>>>
>>>> The way how to validate a resource would be:
>>>>
>>>> // create a validator:
>>>> BasicValidator validator = new BasicValidator();
>>>> // validate resources:
>>>> validator.validate(abstractResource1);
>>>> validator.validate(abstractResource2);
>>>> //process issues found by iterating over
>>>> validator.getIssueList();
>>>> //clean the list if you want to reuse the validator:
>>>> validator.cleanIssueList();
>>>>
>>>> It would be nice if people could review currently checked
>>>> issues and provide feedback (suggest another issues to be checked).
>>>> Also a feedback on a way of validation invocation would be nice.
>>>>
>>>> Current issues being checked (a list of sample error messages)
>>>> follows:
>>>>
>>>> ERROR: A HTTP GET method, public void
>>>> com.sun.ws.rest.impl.modelapi.validation.BasicValidatorTest$TestResourceARM.getMethod(),
>>>> MUST return a non-void type.
>>>> ERROR: A sub-resource locator, public void
>>>> com.sun.ws.rest.impl.modelapi.validation.BasicValidatorTest$TestResourceSRL.subResLocator(),
>>>> MUST return a non-void type.
>>>> ERROR: A sub-resource locator, public void
>>>> com.sun.ws.rest.impl.modelapi.validation.BasicValidatorTest$TestResourceSRL.subResLocator(),
>>>> has an invalid URI path: null
>>>> ERROR: A HTTP GET method, public void
>>>> com.sun.ws.rest.impl.modelapi.validation.BasicValidatorTest$TestResourceASRM.subResMethod(),
>>>> MUST return a non-void type.
>>>> ERROR: A sub-resource method, public void
>>>> com.sun.ws.rest.impl.modelapi.validation.BasicValidatorTest$TestResourceASRM.subResMethod(),
>>>> has an invalid URI path: null
>>>> WARNING: A resource class, class
>>>> com.sun.ws.rest.impl.modelapi.validation.BasicValidatorTest$TestResource,
>>>> does not have any resource method, sub-resource method, or
>>>> sub-resource locator.
>>>> ERROR: A root resource class, class
>>>> com.sun.ws.rest.impl.modelapi.validation.BasicValidatorTest$TestResource,
>>>> has an invalid URI path: UriPathValue(null).
>>>>
>>>> Thanks,
>>>>
>>>> ~Jakub
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>>
>>
>