On 5/21/2013 5:05 AM, Jozef Hartinger wrote:
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. The JSF
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.
On 05/20/2013 06:32 PM, ssilvert(a)redhat.com 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
> 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.
> weld-dev mailing list