10:24 a.m.
Hello Slava !
Thanks for your reply. My comments are in-line:
On 29 Jul 2014, at 21:15, Viacheslav Kabanovich <glory(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev