WELD-862 and Seam Cron
by Peter Royle
Hi,
I'm aiming to make a release of Seam Cron available within the next two weeks. Currently there is an outstanding issue (https://issues.jboss.org/browse/WELD-862) which prevents Cron from running properly with Weld. I have been able to carry on developing Cron by testing it against OpenWebBeans, but obviously if we are to release a Seam module it should work against Weld.
It would be nice if WELD-862 could be fixed as soon a possible so that all future versions will work well with Cron.
But more importantly I also probably need to do something special in Cron so that it will work with the version of Weld already deployed in JBoss AS and Glassfish, which will contain the bug. The workaround mentioned in the bug report is to deep copy the InvocationContext. I attempted to do this by serialising and unserialising the InvocationContext but couldn't due to UnserializableExceptions. Does anyone have any advice for me about how I might be able to work around this bug to support existing versions of Weld?
Cheers,
Pete R
2 months
Example project to show private observer failure with decorator
by Larry Streepy
The attached project (maven and intellij) exhibits the problem with private
observer methods when an App scoped bean is decorated.
You can rung it from IJ, or from the command line using: mvn compile
exec:java -Dexec.mainClass=Main
As delivered, you should see output like the following:
doSomething decorator,
delegate=org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_WeldSubclass@4550bb58
<mailto:delegate=org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_WeldSubclass@
4550bb58>
doSomething,
this=org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_WeldSubclass@4550bb58
<mailto:this=org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_WeldSubclass@4550
bb58> , anInt=5
Got event,
this=org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_Weld$Proxy$@49139829
<mailto:this=org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_Weld$Proxy$@49139
829> <= should be
org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_WeldSubclass
Got event, anInt=0 <= should be 5
Note the "anInt=0" where it should be 5. If you change
AppScopeBean#observer from 'private' to 'protected' you will see output like
this:
doSomething decorator,
delegate=org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_WeldSubclass@4550bb58
<mailto:delegate=org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_WeldSubclass@
4550bb58>
doSomething,
this=org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_WeldSubclass@4550bb58
<mailto:this=org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_WeldSubclass@4550
bb58> , anInt=5
Got event,
this=org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_WeldSubclass@4550bb58
<mailto:this=org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_WeldSubclass@4550
bb58> <= should be
org.jboss.weld.proxies.AppScopeBean$Proxy$_$$_WeldSubclass
Got event, anInt=5 <= should be 5
Note that in the latter case, the member variable is properly initialized.
The problem stems from the fact that the proxy implementation doesn't
include the private methods. I think that the changes included in
https://issues.jboss.org/browse/WELD-2092 have broken decorated beans with
private observer methods. It also hinders tests that use things like JMockit
Deencapsulation to invoke private methods on bean instances.
I don't know how this all reconciles with the CDI spec, but the current
implementation seems broken if I can't have a private observer method simply
because the class is the target of a Decorator.
Thanks for taking the time to review this post.
Larry.
9 years, 9 months
Failures on private observer methods on beans with decorators
by Larry Streepy
I'm just now trying to upgrade to Weld 3.0.0 Alpha 16 (from Alpha10) and I'm
finding a significant change in the way the proxies are generated. This
seems to be the result of this ticket:
https://issues.jboss.org/browse/WELD-2092
In short, it seems that decorated beans that have private methods that
@Observe events are invoked on the wrong instance. They get invoked on an
uninitialized proxy instance instead of the properly initialized bean
instance.
I'm still working to put together a small project that reproduces this
problem, but that may take me until tomorrow. My actual project is too
large.
Has anyone else reported this type of problem? Where an @ApplicationScope
bean with a decorator and a private method with arguments that @Observe some
event are invoked on the wrong object instance? In this case, I'm enabling
RunnableDecorator, and one of my AppScope beans implements Runnable, and it
has a private observer method.
I did my best to search for any other posts on this problem, but didn't find
anything relevant (other than the JIRA ticket I referenced above).
Thanks,
Larry.
9 years, 9 months
