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
4 days, 21 hours
Weld branches
by Jozef Hartinger
Team,
there are currently three main branches for Weld Core:
- 1.1 - the Weld 1.1 branch used in JBoss AS 7, JBoss EAP and other EE6
application servers
- master - Weld 1.2 - basically the 1.1 branch with weld-osgi on top
- 2.0 - Weld 2.0 (CDI 1.1 implementation)
This is confusing as git users usually expect to find the latest and
greatest in the master branch which is not the case for Weld. Therefore,
I am going to rename the master branch to a more appropriate name -
"1.2". If you do any work on the current master branch make sure to
apply your changes to "1.2" from now on.
A new master branch will be added eventually when we start working on
Weld 2.1. In the meantime there will be no branch named "master".
Jozef
12 years, 7 months
Remove JSF from Weld Core?
by ssilvert＠redhat.com
Hi Guys,
I'd like to get your thoughts on the possibility of removing JSF
dependencies from Weld Core and putting them in their own artifact. The
reason I want to do this is so that in WildFly we can more easily allow
Weld JSF classes to work with multiple JSF versions.
As it is now, Weld Core has a hard-coded dependency on the single JSF
version that ships with WildFly. So whether someone uses the Multi-JSF
feature or uses WAR_BUNDLES_JSF_IMPL, you can get Linkage errors when
trying to use Weld Core.
>From what I see, the JSF classes in Weld Core aren't really used by the
rest of Weld Core. Instead they are instantiated via the Weld
subsystem's inclusion of the ConversationAwareViewHandler in its
faces-config.xml.
The only part of Weld Core that "sort of" uses a JSF dependency is
BeanDeployment. This instantiates an instance of JsfApiAbstraction and
registers it the Weld ServiceRegistry. JsfApiAbstraction is only there
to determine the JSF spec version. But I haven't been able to find
anywhere it is actually used in the wild.
Specifically, I would like to move the org.jboss.weld.jsf package into
its own jar artifact.
org.jboss.weld.servlet.ConversationPropagationFilter would go in there
too. Weld Core would then list the new artifact as a dependency so as
not to break backward compatibility.
If you think it's a good idea I'll be glad to do the work to make it
happen. Please let me know.
Thanks,
Stan
12 years, 7 months
