[jboss-as7-dev] Common BeanContainer

[Carlo de Wolf]

First and foremost I need to see instance association work. This means 
StatelessInstanceInterceptor [1] needs to be able to function. Without 
that it's not usable for EJBs.

I still think we need the servitor to be an instance of common bean 
container, which system interceptors (like the 
StatelessInstanceInterceptor) intercepting its business methods.

InvocationHandler is not enough to be a business interface of the 
servitor. We also need to be able to pass context data and invoked 
business interface. I was hoping InvocationDispatcher would meet that 
requirement, but that interface has disappeared. So I'm switching back 
to Endpoint [2] for the moment.

Proxy generation will all be delegated out, so I consider Remoting and 
propagation of Tx/Sec out of scope.

Carlo

[1] 
https://github.com/wolfc/jboss-ejb3/blob/stateless-exp/servitor/stateless/src/main/java/org/jboss/ejb3/servitor/stateless/StatelessInstanceInterceptor.java
[2] 
https://github.com/wolfc/jboss-ejb3/blob/stateless-exp/endpoint/src/main/java/org/jboss/ejb3/endpoint/Endpoint.java#L72

On 01/27/2011 05:44 AM, Ales Justin wrote:
> I've already discussed this with David via irc.
> (it was a short discussion, but I think we're on the same page)
>
> Stuart's new proxy library will simplify things, hence no need for Javassist anymore.
>
> Wrt interceptors, we would definitely need to bring that in as a separate module,
> hence I would suggest not to make that part of AS7 codebase, but a separate project.
>
> Or, the latest integration point for new proxy lib will actually be JDK' InvocationHandler,
> which then makes this a no-op.
>
> It would also be useful to have a proper API for adding new interceptors into the chain,
> hence less hacking around would be needed; e.g. Jsr299BindingsInterceptor.
>
> On Jan 25, 2011, at 8:52 PM, Pete Muir wrote:
>
>> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev