Hi, It depends on how you create problem markers. If you create markers using ValidationErrorManager.addError(...) then you have to remove the markers before validating the resource. You can use ValidationErrorManager.removeAllMessagesFromResource(IResource) We use these methods in our CDI validator. On 09/24/2012 12:26 PM, Xavier Coulon wrote: > Hello Alexey, > > I have another question common-validation that I use for the JAX-RS tooling. This is in relation with https://issues.jboss.org/browse/JBIDE-12595 ("Disabling JAX-RS validator doesn't affect resources validation"). As Jaroslav reported, when a user disables the JAX-RS validation, the problem markers (which are now persistent) are not removed, which is not the expected behavior. The only way to remove them is to delete them from the "Problems" view. > > When validation is disabled, is there any call to a method that I could override to remove the JAX-RS problem markers on all the resources of the project ? > Or, how do you handle that case in the CDI tooling ? > > > Thanks > Best regards, > /Xavier > > >

Ah, sorry Xavier, now I got it. This is a problem with integration between Common Validation framework and WST. I do not see any way to hook into validation "disablement" but I don't think we have to "fix" it in that way. The problem is that we register ValidatorManager as a WST validator and it has its own marker type ID. But our JBT validators (CDI, JSF, ...) which are not WST validators and used as plugins for ValidationErrorManager have their own IDs which are not available for WST validation builder. So we need to register our validators IDs as problem types for WST validation builder. I will try to fix. On 09/25/2012 12:52 AM, Xavier Coulon wrote: > Hi Alexey, > > Yes, I use the ValidationErrorManager.addProblem(..) methods and I remove the existing markers when running a new validation on a resource. > But my question was: how can I hook into the validation "disablement" to remove all existing markers at the same time ? Because for now, after validation has been disabled, the markers are still in place and there's only one way to remove them: manually... > > Thanks. > > Best regards, > /Xavier > > > > On Sep 24, 2012, at 10:43 PM, Alexey Kazakov wrote: > >> Hi, >> >> It depends on how you create problem markers. If you create markers using ValidationErrorManager.addError(...) then you have to remove the markers before validating the resource. You can use ValidationErrorManager.removeAllMessagesFromResource(IResource) >> >> We use these methods in our CDI validator. >> >> >> On 09/24/2012 12:26 PM, Xavier Coulon wrote: >>> Hello Alexey, >>> >>> I have another question common-validation that I use for the JAX-RS tooling. This is in relation with https://issues.jboss.org/browse/JBIDE-12595 ("Disabling JAX-RS validator doesn't affect resources validation"). As Jaroslav reported, when a user disables the JAX-RS validation, the problem markers (which are now persistent) are not removed, which is not the expected behavior. The only way to remove them is to delete them from the "Problems" view. >>> >>> When validation is disabled, is there any call to a method that I could override to remove the JAX-RS problem markers on all the resources of the project ? >>> Or, how do you handle that case in the CDI tooling ? >>> >>> >>> Thanks >>> Best regards, >>> /Xavier >>> >>> >>> >> >

I've committed the fix for https://issues.jboss.org/browse/JBIDE-12595 to trunk. Please, let me know if you still have some problems with it. On 09/25/2012 01:28 PM, Xavier Coulon wrote: > Hi Alexey, > > Great ;-) > > Thanks again for your help ! > > Best regards, > /Xavier > > > > On Sep 25, 2012, at 10:20 PM, Alexey Kazakov wrote: > >> Ah, sorry Xavier, now I got it. >> This is a problem with integration between Common Validation framework and WST. >> I do not see any way to hook into validation "disablement" but I don't think we have to "fix" it in that way. >> The problem is that we register ValidatorManager as a WST validator and it has its own marker type ID. But our JBT validators (CDI, JSF, ...) which are not WST validators and used as plugins for ValidationErrorManager have their own IDs which are not available for WST validation builder. >> So we need to register our validators IDs as problem types for WST validation builder. >> I will try to fix. >> >> On 09/25/2012 12:52 AM, Xavier Coulon wrote: >>> Hi Alexey, >>> >>> Yes, I use the ValidationErrorManager.addProblem(..) methods and I remove the existing markers when running a new validation on a resource. >>> But my question was: how can I hook into the validation "disablement" to remove all existing markers at the same time ? Because for now, after validation has been disabled, the markers are still in place and there's only one way to remove them: manually... >>> >>> Thanks. >>> >>> Best regards, >>> /Xavier >>> >>> >>> >>> On Sep 24, 2012, at 10:43 PM, Alexey Kazakov wrote: >>> >>>> Hi, >>>> >>>> It depends on how you create problem markers. If you create markers using ValidationErrorManager.addError(...) then you have to remove the markers before validating the resource. You can use ValidationErrorManager.removeAllMessagesFromResource(IResource) >>>> >>>> We use these methods in our CDI validator. >>>> >>>> >>>> On 09/24/2012 12:26 PM, Xavier Coulon wrote: >>>>> Hello Alexey, >>>>> >>>>> I have another question common-validation that I use for the JAX-RS tooling. This is in relation with https://issues.jboss.org/browse/JBIDE-12595 ("Disabling JAX-RS validator doesn't affect resources validation"). As Jaroslav reported, when a user disables the JAX-RS validation, the problem markers (which are now persistent) are not removed, which is not the expected behavior. The only way to remove them is to delete them from the "Problems" view. >>>>> >>>>> When validation is disabled, is there any call to a method that I could override to remove the JAX-RS problem markers on all the resources of the project ? >>>>> Or, how do you handle that case in the CDI tooling ? >>>>> >>>>> >>>>> Thanks >>>>> Best regards, >>>>> /Xavier >>>>> >>>>> >>>>> >>>> >>> >> >