geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul McMahan <paulmcma...@gmail.com>
Subject Re: Can we deal generically with container specific jsr77 statistics?
Date Thu, 08 Nov 2007 17:10:57 GMT
I hadn't really thought about footprint issues, but that's a good point.

Put another way, my concern is:
Can a component's management interface be modified without also  
replacing g-mangement?


Best wishes,
Paul

On Nov 8, 2007, at 11:56 AM, Anita Kulshreshtha wrote:

> --- Paul McMahan <paulmcmahan@gmail.com> wrote:
>
>> While I think that technically Anita is correct this approach
>> produces some practical challenges.
>> If all the *StatsImpl classes for all components in the server are
>> gathered in g-management then how can the *StatsImpl classes be
>> upgraded, modified, or replaced without also replacing g-
>> management?
>
> Paul,
>     We are talking about few classes (e.g. 3 each for tomcat/Jetty)  
> per
> component not few jars. I do not think it is worth having separate
> g-management for each assembly. Especially when we still ship all  
> specs
> _jars_ in the smallest assembly.
>    I hope this answers your concerns..
> Thanks
> Anita
>
>  The g-management module would become a major source of
>>
>> contention as various components fix and improve their management
>> interfaces (and we hope they do).
>
>   And since g-management is part of
>>
>> the core framework I think replacing it would require recycling the
>> server (not verified).
>>
>> Let's weigh this out against the overhead of maintaining separate
>> configs for each of the various assembly configurations, which is
>> certainly no trivial matter.
>>
>>
>> Best wishes,
>> Paul
>>
>> On Nov 8, 2007, at 10:10 AM, Anita Kulshreshtha wrote:
>>
>>>
>>> --- "Erik B. Craig" <ginemesis@gmail.com> wrote:
>>>
>>>  say, openEJB or somesuch
>>>> would also
>>>> reside here rather than within our openEJB package? If so, how
>> would
>>>> this
>>>> all play into the pluggable server/framework design?
>>>>
>>>     Since these classes ONLY depend on management classes and not
>> on
>>> openEJB or somesuch, it does not affect the pluggable
>> server/framework
>>> design. I do not think we are planning to strip down classes from
>>> g-management to cater to pluggable framework and add classes as we
>>> upgrade to a higher assembly.
>>>
>>> Thanks
>>> Anita
>>>
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam protection around
>>> http://mail.yahoo.com
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com


Mime
View raw message