0

I'm running an EAR with EJB + EJB + WAR deployment in JBoss WildFly 8.2.0.Final with JSF 2.2 and RichFaces 4.5.2.Final. My problem is, that all RichFaces resources fail to load properly in the client. The generated URL don't resolve and return with HTTP 404.

The deployment is build upon Maven und results in the following structure:

enter image description here

The reason for using <scope>compile</scope> in the EJB module and not the WAR is that I need to extend RichFaces classes from within my EJB module. We've build a dynamic form generator based on some of the components.

As soon as I add JARs to EAR/lib/ and WAR/WEB-INF/lib/ by using <scope>compile</scope> instead of <scope>provided</scope> in the WAR module I get the following stacktrace while starting the application server:

Caused by: java.lang.IllegalArgumentException: Multiple entries with same key: interface javax.validation.constraints.Min=org.richfaces.javascript.LibraryFunctionImplementation@c77af4e and interface javax.validation.constraints.Min=org.richfaces.javascript.LibraryFunctionImplementation@5a903150
    at com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:150)
    at com.google.common.collect.RegularImmutableMap.checkNoConflictInBucket(RegularImmutableMap.java:104)
    at com.google.common.collect.RegularImmutableMap.<init>(RegularImmutableMap.java:70)
    at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:254)
    at org.richfaces.javascript.ClientServiceConfigParser.parseConfig(ClientServiceConfigParser.java:75)
    at org.richfaces.application.ValidatorModule.createClientScriptService(ValidatorModule.java:65)
    at org.richfaces.application.ValidatorModule.configure(ValidatorModule.java:60)
    at org.richfaces.application.ServicesFactoryImpl.init(ServicesFactoryImpl.java:60)
    at org.richfaces.application.InitializationListener.createFactory(InitializationListener.java:110)
    at org.richfaces.application.InitializationListener.onStart(InitializationListener.java:69)
    at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:167)
    at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108)
    at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2190)
    at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163)
    at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303)
    at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294)
    at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:692)
    at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:260)
    ... 9 more

How can I solve this problem?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Daniel Bleisteiner
  • 3,190
  • 1
  • 33
  • 47
  • See https://www.evernote.com/shard/s48/sh/c9f1b0b7-13f6-4457-b793-3cf7d20a3fac/707572ba35072eff98b47daeaa5a245a for the generated deployment that fails to start... – Daniel Bleisteiner Feb 20 '15 at 12:32

1 Answers1

1

Frontend artifacts don't belong in EAR's /lib. They belong in WAR's /WEB-INF/lib. It would otherwise make the backend (the EJB) totally unreusable on other frontends (other WARs), such as Spring MVC, JAX-RS RESTful, "Plain vanilla" JSP/Servlet, etc..etc.. Using/importing JSF FacesContext and friends such as Servlet's HttpServletRequest in an EJB class is already a seriously big red alert. You should not be doing that.

Move that code to WAR. Or, if you intend to make it reusable across various WARs, make it a web fragment project instead which can then end up as another JAR in /WEB-INF/lib.

See also:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • I'm aware that this is not the desired architecture but we are talking about 300.000+ lines of code in this 6 year old project with roughly 120 component classes working with `UIComponent` subclassing. I'll investigate if it is feasible to move some of these into the WAR module... but I'm afraid this breaks the release schedule for this upgrade. – Daniel Bleisteiner Feb 20 '15 at 12:43
  • 2
    Much luck wished. Don't worry about schedule. Just tell them the architecture was seriously broken and needs to be fixed before you can continue. – BalusC Feb 20 '15 at 12:46
  • I love Eclipse... it allowed me to move code by using the refactoring tools. It took 3h to move the code... now it starts and loads resources as expected. But it will take days to clean things up... which is progressive from now on. The project builds and starts properly. – Daniel Bleisteiner Feb 23 '15 at 11:49