You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Mark Struberg <st...@yahoo.de> on 2012/12/29 19:33:30 UTC
quick hangout about proxy refactoring
Hi folks!
I already created a few jira bugs and wrote a few mails about this topic - without much response so far.
Gerhard, Arne and I will discuss the proxy/Producer refactoring in a quick 30 minute hangout today and will of course also share the discussion topics/results with the list later on.
If anyone has a few spare minutes then please join us in IRC and tell me whom I should invite for the hangout.
hangout will happen at 20:00 GMT+1 (this is CET, in 30 minutes).
everybody is welcome to join. There will most probably be a 2nd round ...
LieGrue,
strub
Re: quick hangout about proxy refactoring
Posted by Mark Struberg <st...@yahoo.de>.
Oh, 1 more: I started with an arquillian container adaptor for owb. We should continue with this effort.
This is also something which could be done in parallel if someone likes to volunteer. I contributed quite some code to the jboss hosted owb-arquillian adaptor (ALv2), so we can reuse some parts.
LieGrue,
strub
----- Original Message -----
> From: Mark Struberg <st...@yahoo.de>
> To: "dev@openwebbeans.apache.org" <de...@openwebbeans.apache.org>
> Cc:
> Sent: Sunday, December 30, 2012 12:23 AM
> Subject: Re: quick hangout about proxy refactoring
>
>
>
>
>
> Hi folks!
>
> Imo it was pretty productive. We looked at a few spec parts together and
> reviewed a few old bugs which are still open:
>
> OWB-329 (closed by a dirty workaround hack which is broken in custom context
> cases)
> OWB-344 (a follow up which I gonna work on now)
> Producer<T> and InjectionTarget<T> and how they relate with
> Interceptors & Decorators.
>
> Basically the same stuff I already boiled up on this list and on cdi-dev.
>
> The outcome so far is that we need to split the Interceptor & Decorator
> stuff out of the NormalScoped proxy and store the intercepted & decorated in
> the context. The Decorators and Interceptors would be stored directly in the
> generated subclass where there is exactly 1 such proxy instance delegating to
> exactly 1 contextual instance each. The Decorators and Interceptors would _not_
> be stored
>
> Theoretically there are 3 locations where one can apply the interceptors
>
> Interceptor Option 1.) in the BeanManager#getReference. This is what we have
> right now due to the fact that proxying got added to the spec pretty late and we
> just added it on top. This has all the problems which are described in OWB-329.
> There is a workaround for 80% of cases (see BeanInstanceBag and it's usage
> in our code) but this is very complex and not a 100% solution. So we should get
> rid of it!
>
> Interceptor Option 2.) add the Interceptor and Decorator proxy in the
> Producer<T>#produce(). This is what is suggested (to not say specified) in
> the spec section 11.2 ("If the class has interceptors, produce() is
> responsible for building the interceptors and decorators of the instance.
> CreationalContext cleanup"). This would of course only allow interceptors
> and decorators for picked up classes ("Managed Beans") but not for
> Bean<?> added via Extensions and not even for producer method generated
> contextual instances! Every interceptable Bean would need to deal with all the
> stuff itself. Might be an option ...
>
>
> Interceptor Option 3.) Do it in the Bean<?>#create(). This would allow us
> to e.g. add interceptors/decorators for ProducerMethodBeans very easily.
>
>
> Maybe we should do a mixture between 2. and 3. In any case we must store the
> InterceptionProxy (contextual instance + applied interceptors and decorators) in
> the Context to get rid of nasty serialisation issues we currently have. The
> reason why we always need to handle interceptors AND decorators in the same
> proxy can be found in 8.2 "Decorators are called after interceptors."
> As clarified by the EG this is also true for interceptors which are defined on
> decorators. All those must get called before the first decorator gets invoked.
>
>
> Another discussion topic:
>
> We must be careful about private methods. Usually private methods are not
> proxied. But we need them to deliver e.g. private @Observes methods or private
> @PreDestroy methods. This can be done in 2 ways:
>
> PrivateMethod Option 1.) also proxy private methods by using reflection and
> setAccessible. Of course this means we use reflection 2 times for any private
> method in an intercepted/decorated class: 1st time when the container invokes
> the proxy, 2nd time when the proxy invokes the internal delegation point to the
> contextual instance.
>
> PrivateMethod Option 2.) Provide an interface OwbInterceptedInstance with a
> method #getOwbInternalContextualInstance() (long name to provide naming
> conflicts) and if we need to invoke a private method then we need to grab the
> internal instance and invoke the call on it.
>
>
>
> 3rd topic which came up: cleanup, cleanup, cleanup.
> We can throw away tons of useless code after this refactoring: BeanInstanceBag
> and all the weird stuff around it is the first candidate.
>
> We can also streamline the CreationalContext! We do not store Interceptors and
> Decorators in them any longer, so we can get rid of this special handling. We
> also do not need the CreationalContext anymore after the bean once got created!
> Arne came up with the idea to also get rid of our tree structure. This is then
> also not needed anymore as we can just use a simple list to maintain the
> depending instances. Even hierarchic destroyal is not a problem as this must use
> exactly the reverse order than it's creation process. So a list should be
> perfectly fine.
>
>
>
> 4th topic: drop SecurityService and use commons-weaver [1] matt and I are
> currently working on. Just add a private method with @Privileged and the weaver
> will create all the doPrivileged blocks for you...
>
>
> 5th topic: I like to start implementing the CDI-1.1 API over in geronimo/specs.
> Will do this as side project.
>
> 6th topic: Producer<T> and InjectionTarget<T>: this is a big
> refactoring and can only be done after the interceptor stuff works fine.
>
>
>
> Ithink that was it basically.
>
> So what are the next steps now?
>
> We can split a few things
>
> 1.) the doPrivileged stuff via commons-weaver. I think we can start with this
> stuff in the next week and it can mostly be done in parallel.
>
> 2.) create a ASM4 based proxying mechanism for the decorator/interceptor stuff.
> This can be done without breaking any code.
>
>
> LieGrue,
> strub
>
>
>
> [1] http://commons.apache.org/sandbox/privilizer/
>
>
>> ________________________________
>> From: Jean-Louis MONTEIRO <je...@gmail.com>
>> To: dev@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de>
>> Sent: Saturday, December 29, 2012 11:34 PM
>> Subject: Re: quick hangout about proxy refactoring
>>
>>
>> Hi guys,
>>
>>
>> I was not available at that time. Apologize.
>>
>>
>> What are the outcomes?
>> Any way to move forward?
>>
>>
>> Jean-Louis
>>
>>
>>
>> 2012/12/29 Mark Struberg <st...@yahoo.de>
>>
>> Hi folks!
>>>
>>> I already created a few jira bugs and wrote a few mails about this topic
> - without much response so far.
>>> Gerhard, Arne and I will discuss the proxy/Producer refactoring in a
> quick 30 minute hangout today and will of course also share the discussion
> topics/results with the list later on.
>>> If anyone has a few spare minutes then please join us in IRC and tell me
> whom I should invite for the hangout.
>>> hangout will happen at 20:00 GMT+1 (this is CET, in 30 minutes).
>>>
>>> everybody is welcome to join. There will most probably be a 2nd round
> ...
>>>
>>> LieGrue,
>>> strub
>>>
>>
>>
>>
>> --
>> Jean-Louis
>>
>>
>
Re: quick hangout about proxy refactoring
Posted by Mark Struberg <st...@yahoo.de>.
Hi folks!
Imo it was pretty productive. We looked at a few spec parts together and reviewed a few old bugs which are still open:
OWB-329 (closed by a dirty workaround hack which is broken in custom context cases)
OWB-344 (a follow up which I gonna work on now)
Producer<T> and InjectionTarget<T> and how they relate with Interceptors & Decorators.
Basically the same stuff I already boiled up on this list and on cdi-dev.
The outcome so far is that we need to split the Interceptor & Decorator stuff out of the NormalScoped proxy and store the intercepted & decorated in the context. The Decorators and Interceptors would be stored directly in the generated subclass where there is exactly 1 such proxy instance delegating to exactly 1 contextual instance each. The Decorators and Interceptors would _not_ be stored
Theoretically there are 3 locations where one can apply the interceptors
Interceptor Option 1.) in the BeanManager#getReference. This is what we have right now due to the fact that proxying got added to the spec pretty late and we just added it on top. This has all the problems which are described in OWB-329. There is a workaround for 80% of cases (see BeanInstanceBag and it's usage in our code) but this is very complex and not a 100% solution. So we should get rid of it!
Interceptor Option 2.) add the Interceptor and Decorator proxy in the Producer<T>#produce(). This is what is suggested (to not say specified) in the spec section 11.2 ("If the class has interceptors, produce() is responsible for building the interceptors and decorators of the instance. CreationalContext cleanup"). This would of course only allow interceptors and decorators for picked up classes ("Managed Beans") but not for Bean<?> added via Extensions and not even for producer method generated contextual instances! Every interceptable Bean would need to deal with all the stuff itself. Might be an option ...
Interceptor Option 3.) Do it in the Bean<?>#create(). This would allow us to e.g. add interceptors/decorators for ProducerMethodBeans very easily.
Maybe we should do a mixture between 2. and 3. In any case we must store the InterceptionProxy (contextual instance + applied interceptors and decorators) in the Context to get rid of nasty serialisation issues we currently have. The reason why we always need to handle interceptors AND decorators in the same proxy can be found in 8.2 "Decorators are called after interceptors." As clarified by the EG this is also true for interceptors which are defined on decorators. All those must get called before the first decorator gets invoked.
Another discussion topic:
We must be careful about private methods. Usually private methods are not proxied. But we need them to deliver e.g. private @Observes methods or private @PreDestroy methods. This can be done in 2 ways:
PrivateMethod Option 1.) also proxy private methods by using reflection and setAccessible. Of course this means we use reflection 2 times for any private method in an intercepted/decorated class: 1st time when the container invokes the proxy, 2nd time when the proxy invokes the internal delegation point to the contextual instance.
PrivateMethod Option 2.) Provide an interface OwbInterceptedInstance with a method #getOwbInternalContextualInstance() (long name to provide naming conflicts) and if we need to invoke a private method then we need to grab the internal instance and invoke the call on it.
3rd topic which came up: cleanup, cleanup, cleanup.
We can throw away tons of useless code after this refactoring: BeanInstanceBag and all the weird stuff around it is the first candidate.
We can also streamline the CreationalContext! We do not store Interceptors and Decorators in them any longer, so we can get rid of this special handling. We also do not need the CreationalContext anymore after the bean once got created!
Arne came up with the idea to also get rid of our tree structure. This is then also not needed anymore as we can just use a simple list to maintain the depending instances. Even hierarchic destroyal is not a problem as this must use exactly the reverse order than it's creation process. So a list should be perfectly fine.
4th topic: drop SecurityService and use commons-weaver [1] matt and I are currently working on. Just add a private method with @Privileged and the weaver will create all the doPrivileged blocks for you...
5th topic: I like to start implementing the CDI-1.1 API over in geronimo/specs. Will do this as side project.
6th topic: Producer<T> and InjectionTarget<T>: this is a big refactoring and can only be done after the interceptor stuff works fine.
Ithink that was it basically.
So what are the next steps now?
We can split a few things
1.) the doPrivileged stuff via commons-weaver. I think we can start with this stuff in the next week and it can mostly be done in parallel.
2.) create a ASM4 based proxying mechanism for the decorator/interceptor stuff. This can be done without breaking any code.
LieGrue,
strub
[1] http://commons.apache.org/sandbox/privilizer/
>________________________________
> From: Jean-Louis MONTEIRO <je...@gmail.com>
>To: dev@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de>
>Sent: Saturday, December 29, 2012 11:34 PM
>Subject: Re: quick hangout about proxy refactoring
>
>
>Hi guys,
>
>
>I was not available at that time. Apologize.
>
>
>What are the outcomes?
>Any way to move forward?
>
>
>Jean-Louis
>
>
>
>2012/12/29 Mark Struberg <st...@yahoo.de>
>
>Hi folks!
>>
>>I already created a few jira bugs and wrote a few mails about this topic - without much response so far.
>>Gerhard, Arne and I will discuss the proxy/Producer refactoring in a quick 30 minute hangout today and will of course also share the discussion topics/results with the list later on.
>>If anyone has a few spare minutes then please join us in IRC and tell me whom I should invite for the hangout.
>>hangout will happen at 20:00 GMT+1 (this is CET, in 30 minutes).
>>
>>everybody is welcome to join. There will most probably be a 2nd round ...
>>
>>LieGrue,
>>strub
>>
>
>
>
>--
>Jean-Louis
>
>
Re: quick hangout about proxy refactoring
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
Hi guys,
I was not available at that time. Apologize.
What are the outcomes?
Any way to move forward?
Jean-Louis
2012/12/29 Mark Struberg <st...@yahoo.de>
> Hi folks!
>
> I already created a few jira bugs and wrote a few mails about this topic -
> without much response so far.
> Gerhard, Arne and I will discuss the proxy/Producer refactoring in a quick
> 30 minute hangout today and will of course also share the discussion
> topics/results with the list later on.
> If anyone has a few spare minutes then please join us in IRC and tell me
> whom I should invite for the hangout.
> hangout will happen at 20:00 GMT+1 (this is CET, in 30 minutes).
>
> everybody is welcome to join. There will most probably be a 2nd round ...
>
> LieGrue,
> strub
>
--
Jean-Louis