5:17 a.m.
Do we have a document somewhere that defines the scope of Common
BeanContainer?
Why are we not re-using jboss-interceptors?
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]
Are we not going for InvocationDispatcher instead of InvocationHandler?
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?
Carlo
[1]
https://github.com/jbossas/jboss-as/blob/master/ee/src/main/java/org/jbos...
[2]
https://github.com/jbossas/jboss-as/blob/master/ee/src/main/java/org/jbos...
9:07 a.m.
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
3:52 a.m.
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
10:44 p.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
3:51 a.m.
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...
[2]
https://github.com/wolfc/jboss-ejb3/blob/stateless-exp/endpoint/src/main/...
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
5059
days inactive
5068
days old
4 comments
4 participants
participants (4)
-
Ales Justin -
Carlo de Wolf -
David M. Lloyd -
Pete Muir