Me too.
After a discussion, we can decide to break compatibility by removing
the routines from DomainConfig and ConfigConfig that now exist in the
subtypes.
I have created an @AMXForwardTo annotation to support backward-
compatibility, but I'd rather not mess up the code base for that if we
can swallow the change.
Lloyd
On Mar 27, 2008, at 4:32 PM, Anissa Lam wrote:
>
> Hi Lloyd,
> Thanks a lot for give us the great support.
> Personally, i like this new API better. It follows the same
> hierarchy as the dtd, just like other elements. Once you
> checkin the code, i will make the change accordingly.
>
> thanks
> Anissa.
>
> Lloyd L Chambers wrote:
>> Anissa,
>>
>> I hope to commit code this evening that supports creating resources.
>>
>> I've made an API change. The old APIs might remain compatible (*if
>> we choose to do so*), but some work is required to do this. So for
>> now, please write this (as an example):
>>
>> domainConfig
>> .getResourcesConfig().createResourceAdapterConfig( name, optional );
>>
>> (It is the getResourcesConfig() part that is new).
>>
>> INSTEAD OF the V2 style:
>>
>> domainConfig.createResourceAdapterConfig( name, optional );
>>
>> All of the getters should work as-is though eg
>> domainConfig.getXyzResourceConfigMap().
>>
>> This applies to any type of resource. Similar principle applies:
>>
>> domainConfig
>> .getApplicationsConfig().createApplicationConfig(...) // not used
>> since deployment does the creation
>> domainConfig.getConfigsConfigs().createXyz(...)
>> domainConfig.getLoadBalancersConfig().createLoadBalancerConfig(...)
>>
>> In short the intermediate grouping MBeans new exist representing
>> <resources>, <servers>, <thread-pools>, etc.
>>
>> Lloyd
>>
>> ---
>> Lloyd L Chambers
>> lloyd.chambers_at_sun.com
>> Sun Microsystems, Inc
>>
>>
>>
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc