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 <[email protected]>
>To: [email protected]; Mark Struberg <[email protected]>
>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 <[email protected]>
>
>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
>
>
