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

[Xavier Coulon]

Hello Slava !

Thanks for your reply. My comments are in-line: 

On 29 Jul 2014, at 21:15, Viacheslav Kabanovich <glory at exadel.com> wrote:

> 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.

That looks close to the concept of "Working Copies" that JDT uses, and this is something I was about to try, actually. Keeping the "Primary Copy" for a given resource unchanged, and creating a "Working Copy" during the as-you-type-validation.

> 
> 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.

That would not work for me. For example:

@Path("/")
public class CarResource {
	
	@PathParam("id")
	private Integer id;
	
	
	@GET
	@Path("{id}")
	public Object getCar() {
		return null;
	}
}

if the user changes @Path("{id}") to something like @Path("{carId}"), then the content assist on the value for @PathParam (on the 'id' field above) should propose "carId" instead of "id". So the model needs to be updated before the resource was changed.

> 
> 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).
> 

Yes, again, this reminds me the way JDT works with primary copies and working copies, AFAIU. I may consider this option and see how much it impacts the current code. 

> 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.

I know that the AST is slower to compute, but it includes binding resolution, which is really helpful in cases where the user would use constants instead of String values, for example. And it also helps resolving fully qualified name for Java elements.



Best regards,
/Xavier

> 
> 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/20140730/5249484f/attachment-0001.html