> -----Original Message----- > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] > > Alan Cabrera wrote: > > > > Simon, > > > > Dave and I are in the process of placing a layered pluggable protocol > > stack underneath Hiram's code. It allows for a lot of nifty features > > such as Kerberos via SASL or GSSAPI; we also want to put xinetd > > functionality in. If I read Jeremy's email correctly, it is this that > > he is referring to. > > > > For remote JMX, MX4J has a perfectly good implementation and I think > > that we should use it as is. Are people thinking about using the > > Geronimo network stack to support remote JMX? It is not clear to me > > what the advantages are of doing this. > > > > Do I understand this thread correctly? > > > > Yep :) > DB and I were not sure how it all plugged together.
Think async protocol that can be configured into a stack with each stack having its own protocol name. > The advantages I was thinking of were security etc. around the JMX > invocation. If 160 handles all of this for us, then cool; I was just > concerned that JMX over RMI/JRMP or whatever integrated with the rest of > security etc. so users don't end up having to define separate credentials. > > Seems to me that if we layer 160 on top of your stack, clients get the > standard API and we get low-level integration - does that make sense? Makes sense, share the same configurations/implementations. I know that you can plug your own transport protocol into JMX; this is pretty straightforward. One of the nice things that the Geronimo network stack provides is the ability to have virtual circuits running through the same addr/port. We could have JMX traffic and others go through the same TCP/IP session. Simone, what do you think? Regards, Alan
