Forum Stats

  • 3,840,392 Users
  • 2,262,599 Discussions


Error While validating XHTML Files in Eclipse OEPE (Mars & Neon)

LittlePenguin Member Posts: 11
edited Aug 24, 2016 3:40AM in Enterprise Pack for Eclipse

I'm suffering the error explained in this question of Stackoverflow.

Summarizing, when validating an xhtml or an entire dynamic webproject a window error appear with the error:

"An internal error occurred during: "Validating".

Could not initialize class org.apache.myfaces.shared.config.MyfacesConfig"

In Stackoverflow they correct a MANIFEST.MF file located inside a jar (I think in Neon must be plugins/

The problem is the solution explained in Stackoverflow doesn't solve my error.

I have also tried to edit manually the MANIFEST.MF of the jar and delete the text ".tests" of all packages.

I'm using:

  -oepe- (Eclipse Version: Neon (4.6) Build id: I20160606-1100, oepe plugin version

  -Java 1.8.0_65-b17

In the past I had the same problem with Eclipse Mars


Best Answer

  • Ian Trimble-Oracle
    Ian Trimble-Oracle Member Posts: 40
    edited Aug 10, 2016 6:54PM Answer ✓

    OEPE facelet validation makes use of the MyFaces JSF implementation, and the javax.servlet implementation. In the example project, JSF and Servlet libraries are declared as dependencies. Some classes from these libraries are loaded into the VM ahead of OEPE’s classes, and the problem occurs.

    We see one of these per VM lifetime:

    An internal error occurred during: "Validating".

    Absent Code attribute in method that is not native or abstract in class file javax/faces/application/Application

    Followed by one of these for every validation run:

    An internal error occurred during: "Validating".

    Could not initialize class org.apache.myfaces.shared.config.MyfacesConfig

    The reason there is a problem is hinted at by the initial error – the classes loaded by Maven ahead of OEPE’s own classes have been stripped of code, making them useful only to compile against but useless at runtime.

    Why would there be such classes? I have still not found an authoritative answer to that, but they are provided to the Maven central repository and I have read many websites out there discussing related issues. Here are a few:

    The workaround appears to be to use different dependencies in the POM, and pull in libraries that have full class information that can be used at runtime. In the case of the example project, I recommend the following replacements:

    • Remove both JSF artifacts and replace with org.glassfish:javax.faces:2.1.6
    • Remove the Servlet artifact and replace with org.glassfish:javax.servlet:3.0.1


This discussion has been closed.