WELD-001409 Ambiguous dependencies for type [EagerBeansRepository]

4
votes

I'm trying to migrate my JSF application to CDI. I have implented the following changes:

  • Added an empty beans.xml file to WEB-INF
  • Changed @ManagedBean 's to @Named
  • Changed All the scopes I have to CDI Scopes (Session, View, Request)
  • Changed all @EJB and @ManagedProperty to @Inject

However, an Omnifaces error is preventing deployment as I'm getting the following error three times:

org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [EagerBeansRepository] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject private org.omnifaces.ApplicationListener.eagerBeansRepository]. Possible dependencies [[Managed Bean [class org.omnifaces.cdi.eager.EagerBeansRepository] with qualifiers [@Any @Default], Managed Bean [class org.omnifaces.cdi.eager.EagerBeansRepository] with qualifiers [@Any @Default]]]

I have downgraded to Omnifaces 1.8.1 and the deployment was successful. Why Omnifaces 2.0 resulting in this error?

Development Environment:

  • Glassfish 4
  • Omnifaces 2.0
  • JSF (Mojarra 2.2.0)
  • WELD-000900 2.0.0 (SP1)
1
jsfglassfishcdiomnifacesweld
This exception suggests that OmniFaces JAR is duplicated in runtime classpath. Are you deploying a WAR or EAR? Where is the OmniFaces JAR placed? Are you sure that GlassFish work folders are properly cleaned up before deploy? By the way, while you're at it, I strongly recommend to upgrade to GlassFish 4.1 as well. – BalusC
@BalusC I have cleared Glassfish work folder and deployed without any errors. Thanks. Any articles or links about why should I upgrade to GlassFish 4.1? – fareed
@BalusC Also can you put your comment as an answer so I accept it? Thanks – fareed

1 Answers

5
votes

This exception suggests that OmniFaces JAR (specifically, the JAR containing the mentioned ambiguous class, which is in your particular case EagerBeansRepository) is duplicated in runtime classpath. Provided that the JAR is properly placed in /WEB-INF/lib of the webapp and not elsewhere, then this can happen if GlassFish work folders are not properly cleaned up before deploy. Particularly the GlassFish Eclipse plugin is known to fail in this. You'd need to manually clean up the GlassFish work folders in /glassfish/domains/[domainname].

By the way, while you're at it, I strongly recommend to upgrade to GlassFish 4.1 as well. GlassFish 4.0 has like every first GlassFish release (all the hassle to get it ready as "First Java EE X Application Server" along with every new Java EE API release) way too many childhood bugs.