OK, that sounds reasonable. https://issues.jboss.org/browse/WELD-1429
On 05/21/2013 02:03 PM, [email protected] wrote: > On 5/21/2013 5:05 AM, Jozef Hartinger wrote: >> Hi Stan, >> >> it is not a problem to separate the code that depends on JSF into a >> separate artifact. However, it is unclear to me how that changes the >> situation in WF. How will the JSF dependency of the new artifact >> (let's call it weld-jsf) be setup in WildFly? Could we not use the >> same mechanism to setup the JSF dependency of the current weld-core >> artifact in the first place? (instead of the hard-coded dependency on >> JSF API you mentioned)? > It all has to do with the way Multi-JSF works[1]. The JSF subsystem > figures out which version of JSF the app wants to use. Then it adds > that version to the deployment. For each JSF version, we need a group > of modules that are hard-wired together in their respective module.xml > files. We can't add something to the deployment that depends on the > wrong JSF version. > > So that's why we want to limit the number of modules that declare a > dependency on JSF. It makes for less modules to install when we install > a new JSF version. Right now, there are three modules needed for a new > JSF version. They are jsf-api, jsf-impl, and jsf-injection. For > weld-jsf, I will probably place its artifact in the same module as the > jsf-injection artifact. That seems like a logical place for it to > live. Thus, we keep the number required JSF modules per version at three. > > I don't think it's wise to just do this with all of Weld Core. Lots of > other modules depend on Weld Core. Most of them (all of them?) don't > care about Weld/JSF classes. But if some module did care about Weld/JSF > classes, we would need to make sure that this module loads those classes > in a way that is compatible with Multi-JSF. It would get pretty hairy. > > [1] https://community.jboss.org/wiki/DesignOfAS7Multi-JSFFeature >> Jozef >> >> On 05/20/2013 06:32 PM, [email protected] wrote: >>> 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 >>> _______________________________________________ >>> weld-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
