RE: [picocontainer-dev] nanosar is quite ready

--- Jörg Schaible <[email protected]>
wrote:

> 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.
 I have to look at JMX Course materials ( I was the
docent ;)) - there was sample with several
MBeanServers.  At least JVM itself provides own
server. 
( 
Look into javadoc
ofjavax.management.MBeanServerFactory.findMBeanServer())

JBoss rigs up his own, and because nanosar deployer is
an MBean itself it receives server where it is
registered via callback. And this server is correct 
one  ( since we are about to expose components to JB
managenent console ) 

So container deployer has correct mbean server, but 
lacks a way to pass it down  scripted builder -
visitor solution would be simpliest
(And sequence of events would be: rig up container -
start it - expose jmx - expose jndi) 

This way, JMXExposed must have optional object name,
but not MBeanServer, as it will be visitor who
procvides it when it is necessary ) 

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

I'm not sure that DynamicMBeanProvider is needed at
all -  instance is either MBean tasty for server or
not
(if not - there shall be an exception)  - as it
produces only pair of MBean  ( in this case dynamic,
but there are also static ones )  and object name. 

( object name is now property of JMXExposed, and MBean
itself is a component instance ) 


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

In this case startt/stop has nothing to do with pico
lifecycle - invoking method over jmx console goes
directly to instance. 
Start/stopping could be nadled by pico LC, and
deregistration shall be done by JMXExposed
( this means, it has to keep reference to MBeanServer
where it registered its component ) 



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

OK, in case where you create a lot of instances off
same component adapter and register them visitor is 
not applicable. Though JMX component per session would
be easy - base name  
passed to visitor has session id as parameter and you
are pretty unique. 
( though I do not have seen usecase where you need to
poke into user session yet ) 

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

I will have to grok it too. But now we are in position
to rexamine decisions because we have native JMX
implementation in java core now. 

> > If nobody objects, I will start to merge both
> attempts
> > into gems.
> 
> +1, that was my favoured scenario anyway.

this evening ;)

regards,

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


       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting 

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

    http://xircles.codehaus.org/manage_email