> > 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]
