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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
