I think this maps badly to both the ConfigBeanProxy and AMX
interfaces, which represent jvm-options (JVMOptions) and other
anonymous non-singletons as a single attribute:
List<String> getJvmOptions()
The right way to do it IMO is to issue one PropertyChangeEvent (and
for JMX an AttributeChangeNotification) with the entire list (array)
of old values and the entire list (array) of new values.
Lloyd
On Apr 22, 2008, at 3:36 PM, Jerome Dochez wrote:
> yes you get a PropertyChangeEvent for each property added, I don't
> think I would be able to collapse this especially when you can add
> and remove during the same transaction
>
> jerome
>
> Lloyd L Chambers wrote:
>> If 10 <jvm-options> are set, the transactions layer issues 10
>> events, one for each <jvm-options>
>>
>> Should it be one event or 10?
>>
>> Apr 22, 2008 3:20:38 PM
>> INFO: Attribute JVMOptions<=>jvm-options is of class
>> [Ljava.lang.String;
>> Apr 22, 2008 3:20:38 PM
>> INFO: DelegateToConfigBeanDelegate.setAttributes(): 1 attributes:
>> {JVMOptions} mapped to xml names {jvm-options}
>> Apr 22, 2008 3:20:38 PM
>> INFO: AMXConfigLoader.sortAndDispatch: 2 events
>> Apr 22, 2008 3:20:38 PM
>> INFO: AMXConfigLoader.sortAndDispatch (ATTR change): name = jvm-
>> options, oldValue = null, newValue = -Dfoo=bar, source =
>> com.sun.enterprise.config.serverbeans.JavaConfig
>> Apr 22, 2008 3:20:38 PM
>> INFO: issueAttributeChange: jvm-options: {null => -Dfoo=bar}
>> Apr 22, 2008 3:20:38 PM
>> INFO: AMXImplBase: getAttributeInternal 1: __ObjectRef
>> Apr 22, 2008 3:20:38 PM
>> INFO: AMXConfigLoader.sortAndDispatch (ATTR change): name = jvm-
>> options, oldValue = null, newValue = -Dbar=foo, source =
>> com.sun.enterprise.config.serverbeans.JavaConfig
>> Apr 22, 2008 3:20:38 PM
>> INFO: issueAttributeChange: jvm-options: {null => -Dbar=foo}
>> Apr 22, 2008 3:20:38 PM
>>
>>
>>
>> ---
>> Lloyd L Chambers
>> lloyd.chambers_at_sun.com
>> Sun Microsystems, Inc
>>
>>
>>
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc