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 <[email protected]> > To: "[email protected]" <[email protected]> > 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 <[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 >> >> >
