[jboss-as7-dev] Common BeanContainer

[David M. Lloyd]

Answers inline.

On 01/18/2011 05:17 AM, Carlo de Wolf wrote:
> Do we have a document somewhere that defines the scope of Common
> BeanContainer?

Not really, no.  We're going to feel it out and see what fits and what 
doesn't.  Ideally we'll have a common base for EJB and MB.

> Why are we not re-using jboss-interceptors?

For my part, I reviewed that code and found absolutely no documentation. 
  I found a great deal of abstraction whose purpose I did not 
understand.  And I see a lot of code duplication with things that belong 
in the invocation API and the proxy generator API.

And to be honest, I find the notion of having two separate modules for 
this rather offensive.

That said, using it is not out of the question, if the above issues are 
fixed, as far as I am concerned anyway.  To me a common interceptors API 
would provide only what is needed to implement interceptors and would be 
purpose built from the bottom up, not as a dumping ground for things 
which are only superficially similar and related to the subject of 
interceptors casually.

I am naturally resistant to splitting up modules without cause (as you 
know); I think this position is an important counterweight that we've 
been missing until now.

> Any EE construct must not use any annotation processing. Everything must
> be metadata based. This is to make sure the metadata-complete
> functionality can work. [1] [2]

You are correct.  Constructing interceptors should happen from 
information on the deployment, which can in turn be assembled from 
annotations or from other sources.  So this will have to be split up.

> Are we not going for InvocationDispatcher instead of InvocationHandler?

We are, ultimately.  Once Stuart finishes his proxy work we'll move there.

> I also see a hard dependency on javassist. Would it just not be better
> to delegate out over a SPI implemented by some MSC service? Or will a
> dependency on classfilewriter be introduced?

Yes, we're going to use a hard dependency on Stuart's proxy library once 
it's ready.  The reflection proxy and javassist proxy stuff will all be 
eliminated as there is no real use for having multiple proxy layers.

-- 
- DML