standalone already looks pretty good again:

Tests run: 570, Failures: 19, Errors: 0, Skipped: 0

LieGrue,
strub

--- Gurkan Erdogdu <[email protected]> schrieb am Mi, 24.3.2010:

> Von: Gurkan Erdogdu <[email protected]>
> Betreff: Re: attention - danger zone ;)
> An: [email protected]
> Datum: Mittwoch, 24. März, 2010 08:11 Uhr
> Please do not commit big
> changes(changing design of current implementation) before
> running TCK for web and standalone case. It is very bad
> experience to re-setup to run those TCK tests again and
> finding bugs.
> 
> 
> Thanks;
> 
> --Gurkan
> 
> 
> 
> ________________________________
> From: Mark Struberg <[email protected]>
> To: [email protected]
> Sent: Wed, March 24, 2010 3:54:50 AM
> Subject: Re: attention - danger zone ;)
> 
> small update.
> 
> All our internal tests passed already.
> I did also successfully run our real world app.
> 
> I will fire up the standalone TCK tomorrow to check how bad
> it is and check the changes in if they are reasonably ok.
> 
> 
> LieGrue,
> strub
> 
> PS: I came across a few code parts where I absolutely
> wonder why this never crashed ;)
> 
> 
> --- Mark Struberg <[email protected]>
> schrieb am Di, 23.3.2010:
> 
> > Von: Mark Struberg <[email protected]>
> > Betreff: Re: attention - danger zone ;)
> > An: [email protected]
> > Datum: Dienstag, 23. März, 2010 23:55 Uhr
> > hi sven!
> > 
> > yes and no :)
> > 
> > ad 1.) yes, I aim for separating those concerns into
> 2
> > different MethodHandlers which will get manifested in
> 2
> > proxy objects.
> > 
> > ad 2.) the logic is really simple: If a bean defines
> > interceptors or decorators, we create a contextual
> instance
> > which includes this functionality. We do this by
> creating a
> > proxy and 1:1 delegating to exactly the one
> contextual
> > instance it serves. So for each contextual instance
> which
> > needs to get intercepted/decorated, we create a single
> proxy
> > to serve this purpose
> > 
> > For all @NormalScoped beans, I'll create a
> > NormalScopedBeanProxy which only serves to resolve
> the
> > correct contextual instance (with any interception
> already
> > applied) and delegates all method invocations to this
> > underlying contextual instance. 
> > 
> > So while the InterceptorProxy instance is 1:1 bound to
> the
> > contextual instance, the NormalScopedBeanProxy is 1:1
> bound
> > to the injection point. But there is no 1:1 relation
> between
> > those 2 proxies but a n:m. And that is what made the
> old
> > code so complicated to read, because all the
> resolving
> > needed to switch dynamically.
> > 
> > ad 3.) Yes, if the context is a passivating one, then
> the
> > contextual instance (including all it's
> > interceptors/decorators) will get serialized to that
> > passivation storage. This is now exactly as it is
> defined in
> > the spec!
> > 
> > ad 4.) exactly!
> > 
> > LieGrue,
> > strub
> > 
> > 
> > --- Sven Linstaedt <[email protected]>
> > schrieb am Di, 23.3.2010:
> > 
> > > Von: Sven Linstaedt <[email protected]>
> > > Betreff: Re: attention - danger zone ;)
> > > An: [email protected]
> > > Datum: Dienstag, 23. März, 2010 23:17 Uhr
> > > Hi Mark,
> > > 
> > > just for my personal understanding: The proposed
> > changes
> > > imply:
> > > 
> > > 1. Introducing two seperate MethodHandler. One
> for
> > > resolving NormalScope
> > > beans to the actual instance. Another one for
> applying
> > the
> > > interception/decoration stack.
> > > 
> > > 2. As only one MethodHandler can be attached to
> proxy
> > class
> > > instances, for
> > > dependent scoped beans the
> interception/decoration
> > handler
> > > is attached. For
> > > normal scope instances the resolving handler is
> > attached.
> > > 
> > > 3. The interception/decoration MethodHandler
> including
> > the
> > > actual
> > > interceptor/decorator instances is part of the
> bean
> > state
> > > (?), so it is
> > > serialized to a normal scope along with the bean
> > instance.
> > > 
> > > 4. This implies the scope receives not the
> concrete
> > bean
> > > instance, but
> > > rather the proxy class instance with attached
> > > MethodHandler, which in turn
> > > contains of the bean instance and
> > interceptor/decorator
> > > instances?
> > > 
> > > 
> > > br, Sven
> > > 
> > > 
> > > 2010/3/23 Mark Struberg <[email protected]>
> > > 
> > > > The current
> NormalScopedBeanInterceptorHandler is
> > a
> > > subclass of the
> > > > InterceptorHandler.
> > > >
> > > > But while the InterceptorHandler is fixed
> 1:1 to
> > a
> > > contextual instance, the
> > > > proxy we need to handle the NormalScoped
> > behaviour is
> > > different for each and
> > > > every injection point. There is currently a
> lot
> > code
> > > to work around this
> > > > logical separation, but I consider this to
> be
> > what it
> > > is - a workaround. See
> > > > my comments on OWB-329. Maybe I was not
> clear
> > enough
> > > and should elaborate
> > > > further?
> > > >
> > > > txs and LieGrue,
> > > > strub
> > > >
> > > > --- Gurkan Erdogdu <[email protected]>
> > > schrieb am Di, 23.3.2010:
> > > >
> > > > > Von: Gurkan Erdogdu <[email protected]>
> > > > > Betreff: Re: attention - danger zone
> ;)
> > > > > An: [email protected]
> > > > > Datum: Dienstag, 23. März, 2010 19:51
> Uhr
> > > > > >>>I'm currently refactoring
> > > > > the decorator / interceptor stuff by
> > > > > splitting the Interceptor and
> Decorator
> > > MethodHandlers from
> > > > > the
> > > > >
> >>>NormalScopedBeanMethodHandler.
> > > > > Why? Interceptor/Decorator is handled
> in
> > the
> > > abstract class
> > > > > InterceptorHandler not in
> > > NormalScopedBeanMethodHandler.
> > > > >
> > > > > What is the problem with current
> approach?
> > > Currently
> > > > > InterceptorHandler performs
> > interceptor/decorator
> > > stack for
> > > > > bean just one case.
> > > > >
> > > > > Thanks;
> > > > >
> > > > > --Gurkan
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: Mark Struberg <[email protected]>
> > > > > To: [email protected]
> > > > > Sent: Tue, March 23, 2010 8:09:49 PM
> > > > > Subject: attention - danger zone ;)
> > > > >
> > > > > Hi!
> > > > >
> > > > > I'm currently refactoring the decorator
> /
> > > interceptor stuff
> > > > > by splitting the Interceptor and
> Decorator
> > > MethodHandlers
> > > > > from the
> NormalScopedBeanMethodHandler.
> > > > >
> > > > > This will also allow implementing
> those
> > parts as
> > > pure
> > > > > subclasses later.
> > > > >
> > > > > I'm back to only 2 broken tests and my
> real
> > world
> > > app is
> > > > > running again.
> > > > >
> > > > > Please do not checkin big changes into
> SVN
> > in
> > > > > webbeans-impl.
> > > > >
> > > > > txs and LieGrue,
> > > > > strub
> > > > >
> > > > >
> > >
> __________________________________________________
> > > > > Do You Yahoo!?
> > > > > Sie sind Spam leid? Yahoo! Mail
> verfügt
> > über
> > > einen
> > > > > herausragenden Schutz gegen
> Massenmails.
> > > > > http://mail.yahoo.com
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> >
> ___________________________________________________________________
> > > > > Yahoo! Türkiye açıldı!  http://yahoo.com.tr
> > > > > İnternet üzerindeki en iyi içeriği
> > Yahoo!
> > > Türkiye
> > > > > sizlere sunuyor!
> > > >
> > > >
> > __________________________________________________
> > > > Do You Yahoo!?
> > > > Sie sind Spam leid? Yahoo! Mail verfügt
> über
> > einen
> > > herausragenden Schutz
> > > > gegen Massenmails.
> > > > http://mail.yahoo.com
> > > >
> > > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Sie sind Spam leid? Yahoo! Mail verfügt über einen
> > herausragenden Schutz gegen Massenmails. 
> > http://mail.yahoo.com
> > 
> 
> __________________________________________________
> Do You Yahoo!?
> Sie sind Spam leid? Yahoo! Mail verfügt über einen
> herausragenden Schutz gegen Massenmails. 
> http://mail.yahoo.com
> 
> 
> 
>      
> ___________________________________________________________________
> Yahoo! Türkiye açıldı!  http://yahoo.com.tr
> İnternet üzerindeki en iyi içeriği Yahoo! Türkiye
> sizlere sunuyor!

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com

Reply via email to