1

what is the right way to debug those issues?

In my case I have massive troubles with a LinkageError within my Java EE web project:

Problem

I included JSF API (jboss-jsf-api_2.2_spec-2.2.5.jar) into my wildfly modules directory, i.e. it will be loaded by Wildfly classloader. I have external libraries which also depend on that JSF implementation (e.g. Primefaces and OmniFaces). Additionally, to let the build process run without errors I have to add the library as an separate EAR library.

The strange manner is when adding a bean that implements function with faces event paramaters, e.g.

public void myValueChangeListener(ValueChangeEvent e) {
 // do sth. 
}

implementing those functions results in ...

10:22:18,571 WARN  [org.jboss.modules] (MSC service thread 1-1) Failed to define class javax.faces.event.ValueChangeEvent in Module "javax.faces.api:main" from local module loader @468a169f (finder: local module finder @13d344e7 (roots: /home/user/app-server/wildfly8/modules,/home/user/app-server/wildfly8/modules/system/layers/base)): java.lang.LinkageError: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "javax/faces/event/ValueChangeEvent"

... starting point for my SEVERE

10:22:18,578 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Critical error during deployment: : java.lang.LinkageError: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "javax/faces/event/ValueChangeEvent"

(removing the parameter allows to build the project without errors)

Question

How to cope with such problems? I would need an overview about the order the classes are loaded. Probably there is a way to show an entire classloader tree or any profiling tool which will do the same.

Krease
  • 15,805
  • 8
  • 54
  • 86
John Rumpel
  • 4,535
  • 5
  • 34
  • 48

1 Answers1

2

You can enable debug or trace logging on JBoss Modules, but that's bound to be too much information.

In your case, why do you add a module (i.e. jboss-jsf-api_2.2_spec-2.2.5.jar) which is contained in WildFly anyway (exactly the same version in 8.0.0.Final)? That's why the module loader is complaining about duplicate classes.

There is a list of implicit module dependencies for WildFly deployments (which includes jsf-api for JSF deployments). If you need additional dependencies from the WildFly distribution, you should simply declare that dependency instead of duplicating the module.

See Class Loading in WildFly for more details.

Harald Wellmann
  • 12,615
  • 4
  • 41
  • 63
  • Well, you are right not to add the library manually into the project. Another issue was a missing separation between business logic and web tier. Now I removed the particular jsf implementation but when I try to catch my event within my action listener implementation, my bean is not instantiated during deployment because of a class loading error: Type javax.faces.event.ValueChangeEvent from [Module "deployment.myApp.ear.appCore.jar:main" from Service Module Loader] not found. – John Rumpel May 26 '14 at 07:19