Re: [jboss-as7-dev] Common BeanContainer
In general we (Weld) have always wanted to align interceptor support with whatever JBoss
AS ends up using (once it is split out into a standalone library) to provide users with
continuity of experience (i.e. debugging etc.). So it would be worth us (Weld team), IMO,
checking that whatever ends up being used can be used by Weld inside and outside the AS
(and in other app servers).
On 18 Jan 2011, at 15:07, David M. Lloyd wrote:
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
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev