[jbosstools-dev] Suggestion needed to improve the JAX-RS change processing and validation

Viacheslav Kabanovich glory at exadel.com
Tue Jul 29 15:15:51 EDT 2014


Hello, Xavier

In CDI, the model is updated only on build. We have cache of Java 
libraries, which listens to changes in Java classpath with 
IElementChangedListener and on a change we only mark that the cache is 
to be updated before the next build (Eclipse starts the build right 
after listeners are notified about the classpath change). In this way, 
we only rebuild libraries that are changed.

For as-you-type validation, we create each time new CDI model which 
wraps the main model and for all resources but the one to be validated 
it just redirects requests to the main model. For the validated resource 
we call builder with current content. CDI model objects remain unchanged 
in the main model, but as-you-type validation gets up-to-date objects 
from the temporary model.

All other features, e.g. content assist, search, etc. do not have access 
to the up-to-date model and get aware of changes only after save/rebuild.

If I had to manage model that would change both in build and on unsaved 
resource modifications, I would have extended this approach with main 
and wrapper models. Each modification would update model objects for the 
resource in the wrapper model but would not touch the main model. Build 
would update model objects for the resource in the main model and 
cleared that resource from the wrapper model making it to redirect 
requests to the main model for that resource. The operations to be 
synchronized would be only those marking resource in wrapper model as 
either modified (with up-to-date objects associated) or saved (to be 
requested from the main model).

Unfortunately, I see that this will not help you to avoid parsing the 
compilation unit in as-you-type validator, as it runs in a separate 
thread and can be called before Java element changed event. In CDI, we 
do not use CompilationUnit AST, only IType, so that we do not have to 
parse the source.

Best regards,
Slava Kabanovich

On 07/29/2014 06:53 AM, Xavier Coulon wrote:
> Hello,
>
> I recently opened https://issues.jboss.org/browse/JBIDE-17290 because 
> I realised that since I added the "as-you-type" validation in the 
> JAX-RS tooling, I have two concurrent updates in the JAX-RS model: a 
> JavaElementChangedListener that updates the JAX-RS elements in the 
> model after the user edited a compilation unit, but the 'as-you-type' 
> validator needs to perform the same updates in order to be sure that 
> the validation occurs after the last changes have been taken into 
> account. Actually, the two processes occur in parallel and I have no 
> idea how to make sure that the JavaElementListener-related task is 
> executed and completes before the validation start. I should point 
> that the JavaElementChangedListener is not related to the JAX-RS 
> Builder which is called when a file is saved - that's another story, 
> since there are also updates at this level.
>
> I don't want to get rid of the JavaElementChangedListener because the 
> notification event provides me with the modified CompilationUnit AST, 
> which is required for later processing (I don't want to parse the 
> compilation unit unless it's absolutely necessary). Furthermore, it 
> feels weird that the updates would only occur during the validation, 
> so I'd rather avoid such updates in the validator.
>
> Do you have any suggestion on how I could simplify and improve this 
> part of the tooling ? Since we're now preparing for CR1, an 
> easy-and-acceptable-by-Max solution would be preferred ;-)
>
> How is the situation handled in the CDI tooling ?
>
> Thanks for reading this mail and thanks for your help !
> Best regards,
> /Xavier
>
>
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140729/f2e8da73/attachment.html 


More information about the jbosstools-dev mailing list