RE: [picocontainer-dev] nanosar is quite ready

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


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


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

My view of properties of JMXExposed (what it shall do)

1. Explicit as well as implicit object names.
(currently provided by DynamicMBeanProvider ) 
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()
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 )

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

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

regards,


 

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/


       
____________________________________________________________________________________Ready for the edge of your seat? 
Check out tonight's top picks on Yahoo! TV. 
http://tv.yahoo.com/

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

    http://xircles.codehaus.org/manage_email