2

For some reason after upgrading from Tomcat 6 -> Tomcat 7 and from MyFaces 2.0 -> MyFaces 2.2 (Using OmniFaces 1.7)

I began to get the following error

javax.faces.FacesException: Could not find any registered converter-class by converterId : omnifaces.GenericEnumConverter at org.apache.myfaces.application.ApplicationImpl.createConverter(ApplicationImpl.java:1533) at org.omnifaces.application.OmniApplication.createConverter(OmniApplication.java:77) at org.apache.myfaces.view.facelets.tag.jsf.ValueHolderRule$LiteralConverterMetadata.applyMetadata(ValueHolderRule.java:50) at org.apache.myfaces.view.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:45) at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:63) at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:90) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:290) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:50) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:55)

The only way that I can use the omnifaces.GenericEnumConverter right now is by adding it manually to the faces-config.xml , like this:

<converter>
    <converter-id>omnifaces.GenericEnumConverter</converter-id>
    <converter-class>org.omnifaces.converter.GenericEnumConverter</converter-class>
</converter>

Any ideas why? and how can I resolve it?

Thanks.

Daniel
  • 36,833
  • 10
  • 119
  • 200
  • I don't do MyFaces, but seems to be it fails scanning the annotation based converters from the output libraries. As an easy test you could try: 1.create your own converter, annotation based. 2. build a jar with it and an empty faces-config. 3. include in your project's classpath and try to use it somewhere. – Aritz May 29 '14 at 13:11

1 Answers1

1

This will happen if you have 

<faces-config ... metadata-complete="true">

in your webapp's /WEB-INF/faces-config.xml. This way JSF won't scan JARs for additional JSF artifacts such as @FacesConverter and so on.

Jsut remove the whole metadata-complete attribute, it defaults to false already.

Unrelated to the concrete problem, MyFaces 2.2 has internally already fixed the problem for which the OmniFaces GenericEnumConverter was been introduced as the solution. You can actually safely remove it from your code.

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • I "blindly" accept it :) will check it later on. Thanks **BalusC** – Daniel May 30 '14 at 07:48
  • I checked my code and I don't use the `metadata-complete="true">` in it, so the problem still exists :/ It seems that the omnifaces jar is not being included as it used to be, and If I remove the use of the `GenericEnumConverter` (because of the JSF 2.2) I getting another exception **Undefined component type org.omnifaces.component.script.Highlight** Is there any way that I check if the omnifaces is being included properly ? – Daniel Jun 01 '14 at 08:47
  • That another exception is also a sign that `metadata-complete` is still `true` in `` of your `faces-config.xml`. Have you also verified the one in `` of your `web.xml`? That actually shouldn't matter, but you never know. – BalusC Jun 01 '14 at 09:38
  • I found one `metadata-complete="true"` in web.xml of the war file in open ejb 4.6 war file (that is maybe somehow related to **TomEE** project?) but even after I removed the `metadata-complete` and double checked that my Tomcat does not contain any files with the `metadata-complete` , it still gives me that error :/ , any ideas? – Daniel Jun 01 '14 at 10:19
  • Can you please tell the exact Tomcat and MyFaces version? I can't reproduce it with Tomcat 7.0.54 and MyFaces 2.2.3. And I'm also confused how exactly TomEE comes into the picture. Please elaborate. – BalusC Jun 01 '14 at 15:45
  • Using Tomcat 7.0.53 and MyFaces 2.2.3 , But I'm afraid its because of the fact that the omnifaces jar is located apart of the web app (not inside **web-inf\lib** , but inside the other path **Tomcat\someName\lib...** and is referenced from **catalina.properties** file with the **common.loader** property (just like I do for *myfaces* and *primefaces* . This exact setup worked well with Tomcat 6 and myfaces 2.0 in the past. Again, if I place the omnifaces jar inside the **web-inf\lib** of the webapp it will work, but its not the way we place our jars- I got several webapps that relay on that jar – Daniel Jun 01 '14 at 16:13
  • Regarding the TomEE, We are using only the Open EJB 4.6 (which as far as I understand is part of the TomEE package) we use it as seperate war file in out Tomcat webapps folder, Thanks for the help so far b.t.w. – Daniel Jun 01 '14 at 16:39
  • Thank you for the missing detail about `common.loader`, this gives something to look at. – BalusC Jun 01 '14 at 16:58
  • This seems to be related: https://issues.apache.org/bugzilla/show_bug.cgi?id=54261 In theory, `@WebServlet` and friends wouldn't work this way either. For OmniFaces, we would need to fall back to hardcoded ``, ``, etc entries in `faces-config.xml` instead of using `@FacesConverter`, `@FacesComponent`, etc annotations (PrimeFaces is already doing that and has never used annotations that's why it still works that way). I'm not sure if we would workaround OmniFaces that way .. I'll have to investigate who's wrong here: Tomcat or JSF. – BalusC Jun 01 '14 at 17:00
  • Should I open an issue on github of omnifaces? or on Tomcat/JSF? – Daniel Jun 03 '14 at 05:46
  • Just saying that I had to return the `converter="omnifaces.GenericEnumConverter"` because without it my list are being populated with strings :( (and I'm using myfaces 2.2.3) – Daniel Jul 20 '14 at 15:05