RE: [picocontainer-dev] nanosar is quite ready

Hi Konstantin,

Konstantin Priblouda wrote on Wednesday, August 29, 2007 2:19 PM:

> --- Jörg Schaible <[email protected]>
> wrote:
> 
>> Konstantin Priblouda wrote on Wednesday, August 29, 2007 8:30 AM:
>> 
>>> --- Jörg Schaible
>> <[email protected]>
>>> wrote:
>>> 
>>>> So we have ther same again, a 2nd implementation of
>>>> anh existing thing. Just what I wanted to avoid at
>>>> all.
>>> 
>>> It does not have to stay - just a quick and dirty
>>> test.
>> 
>> Which will manifest now.
> 
> Not necessarily.  I would be happy to merge it into
> remoting ( though IMHO JMX belongs to gems as this
> is not remoting, and depends on nothing ( except MX4J
> stuff  - anyway, is it really necessary now? since 1.5
> 
> it is in core java)

The MX4J stuff is optional anyway. It was originally used my Mike's implementation and I stripped the deps down to the special MBean description support it provides. So that part is MX4J specific ... but optional. Have a look into the MX4J sub package, the classes are quite hollow. Anything else is plain javax.management.

>>> Biggest problem I have with remoting implementation
>>> that adapters need MBeanServer - and there is no good
>>> way to pass it to script which runs through builder.
>>> 
>>> ( not to speak about array of dymamic providers. )
>> 
>> MicroContainer was completely scripted and it made
>> use of this JMX implementation.
> 
> I looked into microcontainer (please correct me if I'm
> wrong) and it used container itself to obtain
> MBeanServer - this is of course an option,  but
> I think that mbean server lost nothing inside
> container hierarchy. MBeanServer comes from outside
> (from container point of view), and I do not see a
> good and portable way to obtain proper MBean server (
> there could be more than one in  given JVM ) via
> script.

Hmmm. Isn't there any possibility to access it? How do you get it in jBoss? Maybe we can use a specialized ObjectReference implementation, that provides the instance.
 
>> Well, when I had the need for JMX I took what was
>> implemented by Mike (originally an implementation
>> used for jBoss) and improved it to my needs. I could
>> use it to expose the components with JMX from my
>> stanhdalone app, Mike used it in (scripted)
>> MicroContainer.
>> 
>> Now, let's have a look at a conversation between
>> user and dev:
>> 
>> U: I wanna expose components with JMX, what should I do?
>> D: Well, we have currently two impls, one in
>> pico-gems and one in nano-remoting.
>> U: Uuugh, and what is the difference?
>> D: You might ask Jörg or Konstantin directly, since
>> only they know, why those two versions exist and
>> when to use which ...
> 
> Yep, That's a crap so we have to find a good solution.

Really glad that we agree here.
 
> My view of properties of JMXExposed (what it shall do)
> 
> 1. Explicit as well as implicit object names.
> (currently provided by DynamicMBeanProvider )

Fine.

> 2. Control over registration time.
> ( current implementation triggers registration on
> getComponentInstance(),  which looks wrong for me.
> registration at JMX is kind of lifecycle action and
> thus shall be done in start()

I am not convinced, because it seems to depend on the use case. I used a JMX console to start and stop services manually. Therefore I had to register them before start. They might have been started by Pico LC, but they did not had to. Also Pico should stop them all at termination.

> Another option could be visitor - it could be a good
> way to  pass MBean server or some config parameters (
> like base name for implicit registration )

There is already a visitor implementation in remoting. But the visitor pattern has a major drawback, so it was not of much use in my application: it assumes that you are working with singletons. I had to manage multiple instances of the same component type and all had to be registered individually. Therefore also this "dynamic" ObjectName stuff, since they had to use obviously unique names. The visitor will only run once over the complete container hierarchy, but cannot deal with dynamic component instantiation. Try to register a JMX component per session ...

> BTW, the same could be said over JNDI stuff - I'm not
> quite happy with it right now.

But it was there first - I also spent my time to grok Mike's implementation before I started to refactor and enhance the functionality (respecting his use case).

> If nobody objects, I will start to merge both attempts
> into gems.

+1, that was my favoured scenario anyway.

- Jörg

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email