Re: Status of JMShe kernel is fully JMX controllabole

[Stephen McConnell <mc...@apache.org>]

Steven Harris wrote:

> First time poster (so bare with me). If or when we move this thing 
> from phoenix to merlin doesn't merlin have jmx integration already? 


Only partially.

Today - only the kernel is fully JMX manageble.  A MBean is defined for 
appliance instances (the component scenario manager) but is not yet 
exposed.  And we still need to take care of custom component MBeans.  
With completion of appliance exposure - every component deployment 
scenario becomes manageble independetly of a particular component 
implementation (which is a really big step foward).  Immediate proties 
are focussing on cleaning up the embedding management - basically 
pulling together five or six differnet implementation into a single 
intelligent embedded model.  Once that is done and we refactor the 
existing embeddors to leverage a common model - then focus will shift to 
kernel extension as a generic requirement.  One extension is JMX 
management which is currently handles explicity in the kernel.  We need 
to refactor this such that JMX is nothing more that an extension to the 
kernel.

Stephen.


>
>
> On Nov 4, 2003, at 7:06 PM, Noel J. Bergman wrote:
>
>>>> Personally, I think that JMS is overkill, but it has
>>>> been recommended that we look at it, so I'm asking the
>>>> geronimo team what the status is so that we can evaluate.
>>>>  I've other alternatives in mind, as well.
>>>
>>
>>> Fair points, and I'd stress that I'm not against JMS per se, but to
>>
>> explain
>>
>>> the background to my position.. I was involved with a messaging product
>>> which didn't implement JMS because it was considered to be too much 
>>> of a
>>> jack of all trades, compromised in some areas to facilitate others, 
>>> and it
>>> doesn't offer any major benefit where compliance (interoperability) 
>>> isn't
>>
>> a
>>
>>> requirement.
>>
>>
>> For our purposes, we don't need a standard interface for 
>> interoperability.
>> THAT standard would be SMTP, POP3, IMAP, etc.  I just want to see if we
>> could find a good distributed spooling technology without having to 
>> roll our
>> own.  On the other hand, I'm also mulling over the idea of not using a
>> distributed spooler, but rather using something like RMI to a 
>> communicate
>> with a remote processor.  Either way, I believe that we want to send 
>> a mail
>> object, not the entire message, and require the clustered processors 
>> to have
>> shared access to the message data.
>>
>>> the time overhead and the problems caused when queues get out of 
>>> hand is
>>> unacceptable to my bosses.
>>
>>
>> Sounds like it should be to anyone.
>>
>>> using the jmx architecture throughout making it very manageable
>>> (cycling individual components is one feature they advertise
>>> which appeals to me WRT James, and the ability to embed other
>>> MBeans or embed their MBeans elsewhere is also something which
>>> fits with my own vision of James.
>>
>>
>> JMX is something that they are already working on for Avalon, and it 
>> does
>> make a great deal of sense for all of the reasons you've mentioned.
>>
>>> Anyway lets carry on turning over rocks and see what crawls out
>>
>>
>> :-)
>>
>>     --- Noel
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org