On Aug 26, 2008, at 12:44 PM, Tim Quinn wrote:
> Jerome Dochez wrote:
>>
>> On Aug 26, 2008, at 10:42 AM, Tim Quinn wrote:
>>
>>> If I have
>>>
>>> @Inject
>>> DasConfig dasConfig;
>>>
>>> how do I register my VetoableChangeListener to detect and possibly
>>> reject changes?
>>>
>> good question
>>
>> VetoableChangeListener bean = (VetoableChangeListener)
>> ConfigSupport.getImpl(dasConfig);
>> bean.addListener(... my vetoable change listener instance...)
>>
> Hmm.
> ConfigSupport.getImpl returns either a ConfigBean or a ConfigView,
> neither of which extends VetoableChangeListener that I can see. And
> VetoableChangeListener does not have an addListener method anyway.
> So this is closer:
>
> ConfigBean bean = (ConfigBean) ConfigSupport.getImpl(dasConfig);
> bean.addListener( myVetoableChangeListener);
>
> except that ConfigBean extends Dom which has an
> addListener(ConfigListener) method but no
> addListener(VetoableChangeListener) method, and I did not see that
> ConfigListener extends VetoableChangeListener.
> Or am I missing something?
>> remember to remove yourself if needed.
>>
>> The only issue is that I have not turned on support for this yet
>> (!) since nobody needed it. If you need it I can do it tomorrow.
> I'm guess I am undecided about this.
> For example, the dasConfig has the
> getAutodeployPollingIntervalInSeconds() method which returns a
> String that we want to parse as an int. Registering a
> VetoableChangeListener on the dasConfig would allow us to make sure
> that attempts to change the value using the admin GUI or the admin
> CLI set command used legal values.
> But there is nothing to prevent the user from hand-editing the
> domain.xml - whether the server is running or stopped - and
> inserting an invalid value. So the autodeployer needs to tolerate
> an illegal value that is loaded initially, as well as reject
> attempts to change it to an invalid value while the server is up.
> For user convenience it is probably best to register the
> VetoableChangeListener on dasConfig but that doesn't save the rest
> of the code from having to protect itself also.
yes I think I would rather keep this type of validation to a Validator
object that would be registered on the ConfigBean, something like
@Configured
@ValidatedBy(DasConfigValidator.class)
public interface DasConfig ... {
}
and have DasConfigValidator implements something like this
public Validator<T> {
public boolean isValid(T newObject);
}
I think we could do something like this post-prelude. Also the bean
validation JSR that Emanuel Bernard is writing is very very
interesting...
jerome
>
>>
>>> Sorry if this is obvious.
>>>
>>> 2. The change method declared on the ConfigListener interface
>>> returns an UnprocessedChangeEvents object. If a module cannot
>>> process a config change, should it throw an exception of some
>>> particular type, or should it create and populate and return an
>>> UnprocessedChangeEvents object?
>>>
>> the latter.
> Good info. Thanks.
>
> - Tim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>