On 01/18/2011 05:17 AM, Carlo de Wolf wrote:
Do we have a document somewhere that defines the scope of Common
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
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
be metadata based. This is to make sure the metadata-complete
functionality can work.  
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
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
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.