-
1. Marc's Re: Scott's Re: MARC's POST: Re: JMX Connectors vs. J
adrian.brock Jan 21, 2003 4:47 AM (in response to obrand)I agree and in fact it is the other way around. Meaning that JMX 160
invokers are just specific instances of the framework assembly.
(DP+interceptors+invokers). Adrian was right me tying the invokers to
JMX is not the way to go for 4.0. Detach it further and we may be done.
marcf> There seems to be some overlap here and merging
> functionality with existing
> components should be occurring here. If an existing
> component like clustering
> has to be refactored to support a subset or alternate
> implementation as
> required for JMX that should be done if possible. I
> find it hard to believe
> that the JMX remoting spec is sufficient for all of
> what need for 4.0 though.
> Where is the JSR160 spec so we can gauge the scope of
> what is to be
> achieved?
>
> xxxxxxxxxxxxxxxxxxxxxxxx
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> xxxxxxxxxxxxxxxxxxxxxxxx
>
> > Negative,
> >
> > See the argument made by adrian on why connectors
> > shouldn't be tied to
> > JMX (posted on the JMX forum I think). Most of
> the
> > aspect framework
> > will use remoting as a feature, expecting all
> these
> > objects to be mbeans
> > is silly. The architecture being worked on is a
> > proxy with a logical
> > name (mbeanname or just any key) and the reifed
> > invoke. The handler
> > today directly calls the JMX mbus but really
> should
> > be a lookup with a
> > handler (and a specific JMX handler would convert
> the
> > calls to the
> > invoke(mbean) call of the JMX spec. These are
> > however specific cases.
> >
> > What is interesting in the jmx work is the
> > discovery/callback/remote
> > class loading. Can I ask you guys to not move the
> > invokers in the MX
> > layer but really make the unified invokers enabled
> > with these features.
> > Bill you should be on that one. Keep adrian in
> the
> > loop he is the first
> > one that saw the way to do it, in fact tying the
> > invokers to JMX is a
> > mistake that I made.
> >
> > marcf
> >
> >
> >
> > > Personally, I think the basis of jboss should be
> > > built on top of the JMX Microkernel, and thus
> any
> > > remote capabilities, should be moved into the
> JMX
> > > layer and work via the JMX remoting framework.
> > >
> > > This is what Tom and I are currently working on
> -
> > and
> > > Juha and Tom are both part of the JMX Remoting
> > JSR.
> > > We're trying to work in parallel with the JSR
> > until
> > > we can roll in JSR interfaces once it's public.
> > >
> > > Currently, we have a Socket-based and SOAP-based
> > set
> > > of connectors.
> > >
> > > Part of this framework is both remote
> > connectivity,
> > > as well as discovery of remote connectors.
> > >
> > > As well, we currently have remote classloading
> as
> > > well as remote callback (for notifications)
> > working.
> > >
> > > I think moving the work from the Invokers into
> the
> > MX
> > > layer wouldn't be too much effort.
> > >
> > > In our commercial product, which sits on top of
> > JBOSS
> > > - we are using this very reliably and its been
> > very
> > > easy to build remote JMX based services. We've
> > built
> > > a wealth of code that uses fully distributed JMX
> > > jboss mbeans and its very easy to implement.
> >
>