[
https://issues.jboss.org/browse/JBIDE-12860?page=com.atlassian.jira.plugi...
]
Alexey Kazakov commented on JBIDE-12860:
----------------------------------------
The reason of this issue is in the way how WST validation builder creates/uses
IWorkbenchContext.
When you create/change any resource in the project the very first time then a new
IWorkbenchContext is created and stored for the project.
We use this context to collect all the changed resources (created, modified, removed).
But when WST run validator jobs then it creates a new IWorkbenchContext instead of using
the context used for collecting changed resources.
It doesn't matter how many time you change your resources. WST will use the same
instance of IWorkbenchContext for entire Eclipse session and will use this instance to
register changed resources. But WST will create a new instance of IWorkbenchContext every
time it runs a validation job.
So It does not make sense.
How it affects us:
1. When you create a plain wst project then a new IWorkbenchContext is created. This
instance will be used to register changed resources until you close the Eclipse.
JAX-RS validator (or any other CommonValidator extension) is ignored since JAX-RS is
not enabled yet.
2. JAX-RS support is enabled. WST invokes a CommonValidatorManager job but provide a new
instance of IWorkbenchContext. CommonValidatorManager creates a new JAX-RS validator
(it's now enabled) and add it to the provided IWorkbenchContext instance. We already
knew that IWorkbenchContext is created every time a validator job is invoked. So we keep
all sensitive information in our own context which is provided by validator. But we the
validator does not have access to the IWorkbenchContext created in the step #1 so it will
never get the list of removed files.
It would work if WST created a new IWorkbenchContext every time it register changed
resources and invokes validation jobs. Or if it used the same instance for every use.
But this weird mixture of different approaches is a pain.
We have already spent so much time on debugging WST validation and adopting our
CommonValidation to every weird behaviour/bugs of WST that we made an ugly monster out of
our CommonValidation which is hard to support and extend. We should have created in the
first place our own independent validation builder instead of using WST. It would be much
easier.
Now I'm going to fix this problem by refactoring our extension of IWorkbenchContext.
We have to initialize validators every time the any instance of IWorkbenchContext is used.
I hope it won't affect performance.
JAX-RS validation problems are not linked
-----------------------------------------
Key: JBIDE-12860
URL:
https://issues.jboss.org/browse/JBIDE-12860
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: webservices
Affects Versions: 4.0.0.Beta1
Reporter: Jaroslav Jankovič
Assignee: Alexey Kazakov
Labels: respin-b
Fix For: 4.1.1.Beta1
This case now fails:
STEP: Create jaxrs problem with Application problem (Multiple application definition -
one class extending Application and one application servlet definition in web.xml)
STEP: comment servlet definition in web.xml
ASSERT: problem marker in web.xml disappears
ASSERT: problem marker in application class disappears
FAIL: problem marker in application class doesn't disappear, because problem markers
are not linked now -> project has to be built to correctly remove both problem markers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira