[jbosstools-issues] [JBoss JIRA] (JBIDE-12860) JAX-RS validation problems are not linked

Alexey Kazakov (JIRA) jira-events at lists.jboss.org
Thu Oct 31 20:39:02 EDT 2013


    [ https://issues.jboss.org/browse/JBIDE-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826364#comment-12826364 ] 

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



More information about the jbosstools-issues mailing list