Mein Ohr ist nicht in der Lage, EJB-Modul Klassen zu finden

Question

Ich bin neu in der EAR. Ich habe ein Web-Modul und ein EJB-Modul entwickelt, die für die Funktionalität voneinander abhängig sind. Dafür versuche ich, sie in einem EAR zu konfirmieren. Ich kartiert sowohl Web- und EJB-Modul zu EAR und kann application.xml als

<display-name>EBS-ear</display-name> 
    <module> 
    <ejb>EBS-ejb.jar</ejb> 
    </module> 
    <module> 
    <web> 
     <web-uri>EBS-web.war</web-uri> 
     <context-root>EBS-web</context-root> 
    </web> 
    </module> 
</application> 

sehen Aber wenn ich versuche EAR meinem Server unter Ausnahme wirft

23:58:29,606 ERROR [io.undertow.request] (default task-5) UT005023: Exception handling request to /EBS-web/: java.lang.NoClassDefFoundError: com/ebs/service/UserAuthorisationService 
    at java.lang.Class.getDeclaredConstructors0(Native Method) 
    at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) 
    at java.lang.Class.getConstructor0(Unknown Source) 
    at java.lang.Class.getConstructor(Unknown Source) 
    at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.verifyAction(XmlConfigurationProvider.java:480) 
    at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.addAction(XmlConfigurationProvider.java:429) 
    at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.addPackage(XmlConfigurationProvider.java:556) 
    at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadPackages(XmlConfigurationProvider.java:295) 
    at org.apache.struts2.config.StrutsXmlConfigurationProvider.loadPackages(StrutsXmlConfigurationProvider.java:112) 
    at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:264) 
    at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:67) 
    at org.apache.struts2.dispatcher.Dispatcher.getContainer(Dispatcher.java:967) 
    at org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:435) 
    at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:479) 
    at org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:74) 
    at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init(StrutsPrepareAndExecuteFilter.java:57) 
    at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:111) 
    at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:84) 
    at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:97) 
    at io.undertow.servlet.core.ManagedFilter.createFilter(ManagedFilter.java:80) 
    at io.undertow.servlet.core.ManagedFilter.getFilter(ManagedFilter.java:66) 
    at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) 
    at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) 
    at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) 
    at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) 
    at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) 
    at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) 
    at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) 
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) 
    at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) 
    at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) 
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) 
    at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) 
    at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) 
    at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) 
    at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) 
    at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) 
    at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) 
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) 
    at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) 
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) 
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) 
    at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) 
    at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) 
    at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) 
    at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) 
    at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) 
    at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) 
    at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) 
    at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) 
    at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) 
    at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) 
    at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) 
    at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) 
    at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) 
    at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) 
    at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) 
    at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
    at java.lang.Thread.run(Unknown Source) 
Caused by: java.lang.ClassNotFoundException: com.ebs.service.UserAuthorisationService from [Module "deployment.EBS-web.war:main" from Service Module Loader] 
    at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) 
    at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) 
    at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) 
    at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) 
    ... 61 more 

auszuführen, was ich von oben verstehen kann, ist die EAR ist nicht in der Lage, die Klassen in dem EJB-Modul zu lokalisieren und damit die Ausnahme zu werfen. Ich benutze WildFLy 10 Server und Eclipse IDE.

Answer 1

Eine EAR-Datei ist nur ein Container für verschiedene Enterprise-Module (EJB-Dateien, WAR-Dateien und reguläre JAR-Dateien) mit einigen gut definierten (aber oft missverstandenen) Regeln, für die Klassen sehen können.

EAR 
\-lib 
| \- utilityA.jar 
| \- utilityB.jar 
| \- ... 
|- ejb-jarC.jar 
|- ejb-jarD.jar 
|- ... 
|- warE.jar 
|- warF.jar 
|- ... 

Für die Zwecke der Klasse Sichtbarkeit, diese EAR oben zeigt fünf Module:

1. lib Modul

In den meisten Fällen werden Sie eine EAR-Datei mit folgenden internen Struktur sehen

2. ejb-jar1.jar
3. ejb-jar2.jar
4. war1.jar
5. war2.jar

wo:

1. Alle Gläser in den lib-Modul sind im selben Modul zu gelten;
2. Alle Gläser und Klassen in jedem WAR-Datei werden als im gleichen Modul sein;
3. Jeder ejb-jar ist ein unabhängiges Modul.

Normalerweise hat jedes Modul seinen eigenen Klassenlader. Jetzt

, JBossAS/Wildfly entspannt sich die Klasse Sichtbarkeitsregeln ein wenig Entwickler zu machen lebt einfacher (und aus historischen Gründen).Auf diesen Server-Implementierungen sind die Regeln:

1. Jeder WAR-Modul seine eigene Klassen sehen, die Klassen in jedem EJB jar und die Klassen in jedem Glas in der EAR/lib
   • es nicht sehen kann die Klassen in andere WAR-Module;
   • Jedes EJB-Modul kann seine eigenen Klassen, die Klassen in anderen EJB-Modulen und die Klassen in jedem jar im EAR/lib-Verzeichnis sehen;
   • es kann die Klassen in keine WAR-Module sehen;
2. Die Klassen in der EAR/lib-Modul kann nur einander sehen:
   • sie keine Klassen in keine EJB-Module oder WAR-Module

Eine strengere Umsetzung sehen würde die Definition manifester Klassenpfadeinträge erfordern, um EJB-Module für einander und WAR-Module sichtbar zu machen.

nun alle oben Ihr Problem gegeben ist wahrscheinlich eines der folgenden:

1. eine Klasse im lib-Modul eine Klasse in einer der EJB-Module oder eine der WAR-Module für den Zugriff versucht - hast du die struts2 jars im Verzeichnis EAR/lib abgelegt?
2. eine Klasse in einem EJB-Modul eine Klasse in einen der WAR-Module

Having said all das könnten Sie Ihr Leben viel einfacher machen, da Sie einen JavaEE 7-Server verwenden für den Zugriff versucht. Packen Sie einfach alles inklusive EJBs in eine WAR-Datei. Es ist sehr wahrscheinlich, dass Sie keinen Nutzen daraus ziehen, ein EAR