I think the users probably want to know what containers the application
has been deployed to.
Jerome: what do you think?
- Hong
Lloyd L Chambers wrote:
> Hong,
>
> But will users of AMX ever need to know or care about <engine>? If
> not, perhaps we should omit it.
>
> Lloyd
>
> On Mar 21, 2008, at 1:11 PM, Hong Zhang wrote:
>
>> Hi, Kedar/Lloyd
>> Engines represent the containers that the components of the
>> application are targeted to. I think readable will be ok.
>>
>> - Hong
>>
>> Lloyd L Chambers wrote:
>>
>>> Kedar,
>>>
>>> I don't know. It's in domain.xml, so I assumed that it should be
>>> manageable, or at least visible (readable) through AMX.
>>>
>>> Hong?
>>>
>>> Lloyd
>>>
>>> On Mar 21, 2008, at 11:18 AM, Kedar Mhaswade wrote:
>>>
>>>> Lloyd L Chambers wrote:
>>>>
>>>>> To clarify: the name of the <engine> need only be unique within
>>>>> its scope (eg the application, web module, etc), because the
>>>>> name of the app forms part of the ObjectName. Even in an EAR,
>>>>> if each web module has <engine> elements, the web module names
>>>>> are unique, therefore the ObjectNames would be unique.
>>>>> The only problem would be if we had more than one <engine> with
>>>>> the same "sniffer" attribute in the same scope.
>>>>> A reasonable assumption?
>>>>
>>>>
>>>>
>>>> I am not understanding one thing and hope you have thought this
>>>> through.
>>>>
>>>> Is Engine something that user/developer needs to understand/know?
>>>> I was under the impression that user deals with applications and the
>>>> other machinations are handled transparently. So, I'd think we should
>>>> avoid exposing "Engines" to users unless we absolutely have to.
>>>>
>>>> - Kedar
>>>>
>>>>> lloyd
>>>>> On Mar 21, 2008, at 10:03 AM, Hong Zhang wrote:
>>>>>
>>>>>> Lloyd: thanks for finding a solution for this. The sniffer
>>>>>> attribute is unique at least for the standalone war case, so it
>>>>>> will be ok for TP2.
>>>>>>
>>>>>> Jerome: if we need to have a unique name for the Engine
>>>>>> element, what should it be? I am not yet clear about how the
>>>>>> application element would look like for the ear case where we
>>>>>> have multiple wars inside of ear. Would we have multiple
>>>>>> engines with sniffer value as "web" in that case?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> - Hong
>>>>>>
>>>>>> Lloyd L Chambers wrote:
>>>>>>
>>>>>>> AMX MBeans look like this for now:
>>>>>>>
>>>>>>> amx:j2eeType=X-EngineConfig,name=security,X-
>>>>>>> ApplicationConfig=hello1
>>>>>>> amx:j2eeType=X-EngineConfig,name=web,X-ApplicationConfig=hello1
>>>>>>>
>>>>>>> The "sniffer" attribute can be used as the unique ID, but I'm
>>>>>>> not sure that it's unique...?
>>>>>>>
>>>>>>> It is preferable to have a name or id.
>>>>>>>
>>>>>>> Lloyd
>>>>>>>
>>>>>>>
>>>>>>> On Mar 20, 2008, at 6:43 PM, Lloyd L Chambers wrote:
>>>>>>>
>>>>>>>> Hong,
>>>>>>>>
>>>>>>>> I see that the <engine> element has no "id" or "name". This
>>>>>>>> causes a headache for MBeans; a unique ObjectName can't be
>>>>>>>> generated that way. All MBeans to date are either
>>>>>>>> singletons within their scope, or have a "name" or "id" or
>>>>>>>> other primary key.
>>>>>>>>
>>>>>>>> Could we please add a name field?
>>>>>>>>
>>>>>>>>
>>>>>>>> For now I can force the unique id to be the value of
>>>>>>>> "sniffer", but that's a hack.
>>>>>>>>
>>>>>>>>
>>>>>>>> Lloyd
>>>>>>>>
>>>>>>>> ---
>>>>>>>> Lloyd L Chambers
>>>>>>>> lloyd.chambers_at_sun.com
>>>>>>>> Sun Microsystems, Inc
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>