CODEWITHSUNDEEP
jsfconverterscdiomnifaces
Atanas Vangelov
Atanas Vangelov

Reputation: 23

Updated omnifaces jar, now it says that my converters are ambiguous

So I was running an old version of omnifaces - 1.8.3, now I updated to the latest 2.6.3 and I get some pretty odd exception when I try to login. The problem is I really don't know how to properly debug a .xthml jsf

Exception I am getting:

2017-07-10T16:32:46.631+0300|Warning: StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception
org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318: Cannot resolve an ambiguous dependency between: 
  - Managed Bean [class kamelon.ui.convertors.LoginConverter] with qualifiers [@Any @Default],
  - Managed Bean [class kamelon.ui.convertors.IdentityHashCodeConverter] with qualifiers [@Any @Default],
  - Managed Bean [class kamelon.ui.convertors.IdentifiableConvertor] with qualifiers [@Any @Default]
    at org.jboss.weld.manager.BeanManagerImpl.resolve(BeanManagerImpl.java:1235)
    at org.jboss.weld.util.ForwardingBeanManager.resolve(ForwardingBeanManager.java:91)
    at org.jboss.weld.bean.builtin.BeanManagerProxy.resolve(BeanManagerProxy.java:115)
    at org.omnifaces.util.BeansLocal.resolve(BeansLocal.java:77)
    at org.omnifaces.cdi.converter.ConverterManager.createConverter(ConverterManager.java:122)
    at org.omnifaces.cdi.converter.ConverterManager$Proxy$_$$_WeldClientProxy.createConverter(Unknown Source)
    at org.omnifaces.application.OmniApplication.createConverter(OmniApplication.java:82)
    at com.sun.faces.facelets.tag.jsf.ValueHolderRule$LiteralConverterMetadata.applyMetadata(ValueHolderRule.java:85)
    at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
    at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
    at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
    at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:491)
....

I have specified < p:(component)>< f:converter>< /p:(component)> in many files and I don't know if I should switch them to < p:(component) converter=""/> now or if I should add more (and where?) for the new version.

Don't know what is the problem with the new version, can somebody help?

Thanks in advance!

Upvotes: 2

Views: 632

Answers (2)

BalusC
BalusC

Reputation: 1109532

This will happen if you have a @FacesConverter which extends an existing @FacesConverter instead of directly implementing the Converter interface.

For example,

@FacesConverter("identifiableConverter")
public class IdentifiableConvertor implements Converter {}

@FacesConverter("identityHashCodeConverter")
public class IdentityHashCodeConverter extends IdentifiableConvertor {}

@FacesConverter("loginConverter")
public class LoginConverter extends IdentityHashCodeConverter {}

This way, when you ask CDI for an instance of IdentifiableConvertor, CDI doesn't know which one exactly you mean. It could be as good IdentityHashCodeConverter or LoginConverter because they are both assignable to a IdentifiableConvertor field. This is ambiguous.

This can be solved by putting @Specializes on the subclasses.

@FacesConverter("identifiableConverter")
public class IdentifiableConvertor implements Converter {}

@FacesConverter("identityHashCodeConverter")
@Specializes
public class IdentityHashCodeConverter extends IdentifiableConvertor {}

@FacesConverter("loginConverter")
@Specializes
public class LoginConverter extends IdentityHashCodeConverter {}

This way CDI knows that IdentityHashCodeConverter should only be assigned to a IdentityHashCodeConverter field and the LoginConverter should only be assigned to a LoginConverter field. When you now ask for IdentifiableConvertor, CDI knows it can't be the IdentityHashCodeConverter or IdentityHashCodeConverter and thus only the IdentifiableConvertor remains available, without ambiguity.

Alternatively, you can also drop the superclass and implement the bare Converter interface directly. But this is not DRY.

Upvotes: 4

Atanas Vangelov
Atanas Vangelov

Reputation: 23

Looks like a Convertor extending org.omnifaces.converter.SelectItemsConverter gives that exception, implementing javax.faces.convert.Converter fixed it for me. Don't know why is it so...

Upvotes: 0

Related Questions