RE: [picocontainer-dev] nanosar is quite ready

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.

> 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.
 
> IMHO, JMXExposed means to me that "i like to expose
> this component to JMX" - and then I have to assure
> that  MBeanServer finds it tasty ( Static / Dynamic
> MBean )
> 
> let's try to find some point in the middle which
> satisfies both.

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

Gosh, this is CRAP! It makes the complete framework look like a big dump bin of ad-hoc development instead of a well-designed library. Does Spring also offer two different impls for JMX (and XML scripting)? If we as devs can no longer reuse/maintain our existing components, we should rather stop at all. What kind of user experience is it, if he has to recognize that we as community have no real vision for our product?

I know, that I have to blame myself for simply writing harsh words instead of spending time on development, but it's unfortunately nothing I can currently change. Early in the discussion we agreed, that it makes now sense to move the JMX stuff into gems and IMHO it would have been easy to adjust it for you in a way that it uses sensible defaults to allow scripting corresponding your needs. But what really embarasses me is a parallel development and leaving it up to the community to support and maintain now two impls. Do you know, how often I spend time in past trying to update the JTec demo to latest pico/nano versions until I finally gave up?

- Jörg

... calming down ... ;-)

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

    http://xircles.codehaus.org/manage_email