RE: [picocontainer-dev] Argumentative PC

Hi Konstantin,

Konstantin Priblouda wrote on Sunday, August 12, 2007 5:31 PM:

> --- Jörg Schaible <[email protected]> wrote:
> 
>> The existing JMX code also provide a quite complex
>> solution for the name
>> mapping. I'd really dislike to have a second
>> implementation like we have
>> now two XML based Nano dialects.
> 
> I would propose to split remoting so there are  clear
> subproject boundaries - jmx by itself is not really
> remoting and this stuff is better in gems (as jmx is
> core feature of java)

As already stated, I was more comfortable with the separate artifact solution anyway. But since our minimum JDK supports JMX now, it is IMHO fine in gems. If you look at the impl in remoting, there's just one or two classes that are dependend on MX4J - I've already kept the dep as minimal as possible, and it should already run on JDK 5.

> as for 2 xml based dialects - neither of them is
> trully complete. they should be merged - great feature
> of xstream is to provide primitives / simple constants
> of
> various types.  but there is no way to play around
> with behaviours - but it should.
> 
> the only way to use all features is to go groovy.

Yep. Especially regarding our future plans we should clean up XML support.
 
> as for JNDI - I propose:
> 1. JNDI Object reference
> 2. Behaviour based on it ( registering ) - this could
> be even generic behaviour which stores component in
> whatever reference is provided upon creation

Explain more. Current JMX impl supports some different approaches to create the ObjectName. Registering is done with the lifecylce (since it depends on the object wether you have only one instance or multiple of 'em).

> 3. JNDI component adapter, as current EJBClientAdapter
> is tied to EJB spec and is not what we really need
> there ( this new adapter could be base for EJB stuff )

As long as the EJB client adapter keep the "single-object/multiple-threads" functionality I've explkained in my other mail regarding the ThrealLocal stuff in gems.

> I would propose everything shall go into gems, but
> nano-jndi would also do.

Main reason for separate artifacts were the additional deps. Reason for collecting those artifacts in remoting was the intention to decrease the number of artifacts. With JDK 5 gems seems now perfect.

- Jörg

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

    http://xircles.codehaus.org/manage_email