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
BeansXmlHandler indirectly causes NPE in Wildfly
by Maxim Frolov
Hi everyone,
recently I found a bug in Wildfly: https://issues.jboss.org/browse/WFLY-3147
After looking at the source code I found that the BeansXmlHandler always
calls interpolate() method, even if the argument is null.
Does it make sence?
In my opinion, BeansXmlHandler must not call interpolate() method if the
String value is null (i.e. absent).
My questions to this mailing list are:
1) Is this really bug in weld and I should report a JIRA bug / make a pull
request?
or
2) Does this work as expected/designed and the bug is in Wildfly?
Cheers,
/max.
11 years, 12 months
AfterBeanDiscovery and observer resolver cache
by Christian Sadilek
Hi everyone,
CDI extensions can observe the AfterBeanDiscovery event to register observer methods (addObserverMethod). However, when an event is first fired, the observers for that event are resolved and then cached (in TypeSafeResolver). All future calls to addObserverMethod for an already fired event with corresponding qualifiers will have no effect because the observer result is read from cache and not recomputed.
>From an API perspective that's unfortunate because addObserverMethod will only work until an event (with corresponding qualifiers) is fired and there is no indication to the caller of that method that it didn't have any effect when invoked after that.
Possible solutions:
- Provide some public API to clear/recompute that part the observer cache. Maybe that exists? I couldn't find it which is why I am using the private API and Reflection :(. Also let AfterBeanDiscovery.addObserverMethod fail in that case with the advice to reset the cache.
- Recompute the corresponding part of the cache when addObserverMethod is called (seems preferable).
OpenWebBeans doesn't have this issue as their NotificationManager will simply add the new ObserverMethod to a ConcurrentHashMap that is also accessed when an event is fired.
What do you think? Can this already be done or is there another solution?
Cheers,
Christian
12 years
