I run standalone TCK and see no failures (Actually I got 5 failures but when re-run those failures have also passed (mentioned in Weld)!). You got 19 failures then some of them are broken. I understand the point that your real time application depends on OWB but OWB must not depend on your application :)
Therefore I think there are some issues in your current code update. Before getting this level, I think it must not be committed. --Gurkan 2010/3/24 Mark Struberg <[email protected]> > 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 > -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
