Note:
Compatibility can be maintained via an internal forwarding mechanism,
if need be. Extra work, but more importantly, do we want to carry
that model forward?
Lloyd
On Mar 27, 2008, at 1:32 PM, Lloyd L Chambers wrote:
> Correction:
>
> For V3, code would look like this:
>
> domainConfig.getResources().create/remove/get<ResourceName>Config(...)
>
> vs V2 code:
>
> domainConfig.create/remove/get<ResourceName>Config(...)
>
> On Mar 27, 2008, at 1:09 PM, Lloyd L Chambers wrote:
>> In V2, even though elements like <resources> existed, they were
>> omitted as MBeans; there was no AMX "ResourcesConfig" MBean.
>>
>> In implementing V3, I want to keep things generic--no special code,
>> especially important in a modular system.
>>
>> Accordingly, I would like to move all resource related methods
>> (create/remove/get) into a ResourcesConfig MBean.
>>
>> For clients, the change would look like this:
>> domainConfig.getResources().create/remove/
>> get<ResourceName>Config(...) proposed V3 approach
>>
>> vs:
>> domainConfig.create/remove/get<ResourceName>Config(...) proposed
>> V3 approach
>>
>> Similar issues exist for other elements such as <node-agents>,
>> <configs>, <load-balancers>, etc.
>>
>>
>> Lloyd
>>
>> ---
>> Lloyd L Chambers
>> lloyd.chambers_at_sun.com
>> Sun Microsystems, Inc
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
> ---
> Lloyd L Chambers
> lloyd.chambers_at_sun.com
> Sun Microsystems, Inc
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc