Tim,
Thanks, good feedback.
The names might be (as we decide) the same, but they'll exist in an
entirely new element, and probably will contain at least some
different attributes. So keeping them the same class might not
maintain backward compatibility anyway, or at least will be confusing.
What I'm referring to at present is what can be found under the AMX
ApplicationsConfig interface, which looks like what is seen below
(comments stripped). Note that getApplicationConfigMap() is the only
useful thing at present; it returns a Map of all <application> elements.
AFAIK, the following are no longer used, because generic <application>
is used.
getJ2EEApplicationConfigMap()
getEJBModuleConfigMap()
getWebModuleConfigMap()
getRARModuleConfigMap()
getAppClientModuleConfigMap()
getLifecycleModuleConfigMap()
getExtensionModuleConfigMap()
getConnectorModuleConfigMap()
...........
public interface ApplicationsConfig extends ApplicationsConfigBase {...}
public interface ApplicationsConfigBase
extends ConfigElement, Container, ConfigCreator, ConfigRemover,
ConfigCollectionElement, Singleton, DefaultValues
{
public static final String J2EE_TYPE = XTypes.APPLICATIONS_CONFIG;
public Map<String,J2EEApplicationConfig> getJ2EEApplicationConfigMap();
public Map<String,ApplicationConfig> getApplicationConfigMap();
public Map<String,EJBModuleConfig> getEJBModuleConfigMap( );
public Map<String,WebModuleConfig> getWebModuleConfigMap( );
public Map<String,RARModuleConfig> getRARModuleConfigMap();
public Map<String,AppClientModuleConfig> getAppClientModuleConfigMap();
public Map<String,LifecycleModuleConfig> getLifecycleModuleConfigMap();
public Map<String,ExtensionModuleConfig> getExtensionModuleConfigMap();
public Map<String,ConnectorModuleConfig> getConnectorModuleConfigMap();
public CustomMBeanConfig createCustomMBeanConfig(
String name,
String implClassname,
String objectName,
@ResolveTo(Boolean.class) String
enabled,
Map<String,String> reserved );
public void removeCustomMBeanConfig( String name );
public Map<String,CustomMBeanConfig> getCustomMBeanConfigMap();
public LifecycleModuleConfig createLifecycleModuleConfig( String name,
String description,
String classname,
String classpath,
@ResolveTo(Integer.class) String loadOrder,
@ResolveTo(Boolean.class) String
isFailureFatal,
@ResolveTo(Boolean.class) String enabled,
Map<String,String> reserved );
public void removeLifecycleModuleConfig( String name );
}
Lloyd
On Sep 25, 2008, at 3:14 PM, Tim Quinn wrote:
> Lloyd,
>
> I'm not positive, but does the AMX interface WebModuleConfig
> correspond to the admin/config-api interface WebModule? There is no
> admin/config-api interface EJBModule because prelude does not
> support stand-alone EJB modules, but that interface will appear for
> the final release.
>
> This is another example of subinterfaces (WebModule) of an "abstract
> superinterface" (Module) in the sense that the domain.xml will
> probably never contain <module> but will contain <web-module>.
> I believe that, post-prelude, each <application> will be able to
> contain one or more concrete subelements of <module>, so that we
> might see
>
> <application>
> <web-module ...>
> ...
> </web-module>
> <ejb-module...>
> ...
> </ejb-module>
> </application>
>
> I'm not positive, but I think that's the plan. So although the AMX
> interfaces such as EJBModuleConfig might not be used now they
> probably will be post-prelude. Whether to clean them out now and re-
> add them later is a separate question.
>
> - Tim
>
> Lloyd Chambers wrote:
>> Kedar,
>>
>> Sorry I wasn't clear. We have old AMX interfaces WebModuleConfig,
>> EJBModuleConfig, etc. AFAIK, these are never used now, all being
>> supplanted by ApplicationConfig (<application>) (not to be
>> confused with ApplicationConfigConfig (<application-config>)).
>>
>> Lloyd
>>
>> On Sep 25, 2008, at 2:31 PM, Kedar Mhaswade wrote:
>>
>>>
>>>> Correct. I am not planning on rocking the boat.
>>>
>>> thank you, Thank You, THANK YOU.
>>>
>>>> HOWEVER, based on what Anissa told me, I probably should *remove*
>>>> some interfaces that are supplanted by new ones, like
>>>> ApplicationConfig.
>>>
>>> Didn't we decide at arch that we are not exposing this feature of
>>> overriding
>>> deployment descriptors in the GUI?
>>>
>>>
>>> -Kedar
>>>
>>>> Lloyd
>>>> On Sep 25, 2008, at 2:24 PM, Kedar Mhaswade wrote:
>>>>> Right, no changes for Prelude though, correct?
>>>>>
>>>>> Lloyd Chambers wrote:
>>>>>> June,
>>>>>> No, they were not.
>>>>>> However, my current view is that they *should* be changed
>>>>>> because of enough incompatible changes.
>>>>>> Also, an additional package name *is* being used:
>>>>>> org.glassfish.api.amx
>>>>>> Finally, other modules can use whatever package name they want
>>>>>> for AMX interfaces.
>>>>>> Lloyd
>>>>>> On Sep 25, 2008, at 1:37 PM, June.Parks_at_Sun.COM wrote:
>>>>>>> Lloyd,
>>>>>>>
>>>>>>> Were the package names changed? I don't remember hearing
>>>>>>> anything about it after this message.
>>>>>>>
>>>>>>> June
>>>>>>>
>>>>>>> On 04/15/08 15:16, Lloyd L Chambers wrote:
>>>>>>>> It turns out there there are going to be many
>>>>>>>> incompatibilities with V3 in AMX.
>>>>>>>>
>>>>>>>> This starts with our change to <applications> in domain.xml,
>>>>>>>> the need to generically support elements like <configs>,
>>>>>>>> <servers>, <clusters>, etc, and various other little things
>>>>>>>> that "add up" to a fair number of changes.
>>>>>>>>
>>>>>>>> PROPOSAL:
>>>>>>>>
>>>>>>>> Change package names for the entire AMX API:
>>>>>>>>
>>>>>>>> com.sun.appserv.management => org.glassfish.admin.amx
>>>>>>>>
>>>>>>>> There are a number of sub-packages underneath
>>>>>>>> com.sun.appserv.management.
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: admin-
>>>>>> help_at_glassfish.dev.java.net
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>