However, if we have time to refactor it very soon, i would certainly have no problem to include it in 1.0.2. What I meant is that I'd rather avoid exposing an mbean which is bound to be refactored in the near future.
On Fri, Oct 16, 2009 at 10:30, David Bosschaert <[email protected]> wrote: > Okidoki, I'll leave that one for now. > > Cheers, > > David > > 2009/10/15 Guillaume Nodet <[email protected]> > >> Right, I think I've missed that one while refactoring the JMX layer >> for the features service. >> Unless there is a real need for that now, I would defer to 1.2.0 and >> refactor it in a more coarse grained service, the same way we did for >> the FeaturesServiceMBean, so that we'd have a getInstances() method >> that would return a TabularData containing all the informations >> available for a give instance (name, port and state for now). We >> could leave the other methods unchanged. >> >> On Thu, Oct 15, 2009 at 18:09, David Bosschaert >> <[email protected]> wrote: >> > Hi all, >> > >> > While looking at FELIX-1655, I noticed that there is actually an >> > AdminServiceMBean in the code, but it doesn't seem to be registered with >> the >> > MBean Server. Is this done deliberately or is this an oversight or am I >> > missing it? >> > >> > I think having this controllable through JMX would be useful - I'd be >> happy >> > to try an enable this functionality... >> > >> > Cheers, >> > >> > David >> > >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
