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.
>
>> 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