我的耳朵不能找到ejb模块类 [英] My ear is not able to find ejb module classes

查看：135 发布时间：2017/7/30 1:08:12 java eclipse java-ee jboss

本文介绍了我的耳朵不能找到ejb模块类的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我是EAR的新手。我已经开发了一个Web模块和一个ejb模块，它们相互依赖于功能。为此，我试图在EAR中与他们保持一致。我将web和ejb模块映射到EAR，并且可以看到application.xml为

 < display-name> EBS-ear& /显示名称> 
< 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>

但是，当我尝试执行EAR时，我的服务器会抛出异常

  23：58：29,606 ERROR [io.undertow.request]（默认任务-5）UT005023：异常处理请求到/ EBS-web /：java.lang。 NoClassDefFoundError：java.lang.Class.getDeclaredConstructors0（Native Method）中的$ / 
 $ java.lang.Class.privateGetDeclaredConstructors（未知源）
 java.lang中的
。 Class.getConstructor0（未知源）
在java.lang.Class.getConstructor（未知源）
在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.XmlCon figurationProvider.loadPackages（XmlConfigurationProvider.java:295）
在org.apache.struts2.config.StrutsXmlConfigurationProvider.loadPackages（StrutsXmlConfigurationProvider.java:112）
在com.opensymphony.xwork2.config.impl.DefaultConfiguration。 reloadContainer（DefaultConfiguration.java:264）
在com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration（ConfigurationManager.java:67）
在org.apache.struts2.dispatcher.Dispatcher.getContainer（Dispatcher。 java：967）
在org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration（Dispatcher.java:435）
在org.apache.struts2.dispatcher.Dispatcher.init（Dispatcher.java:479） 
在org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher（InitOperations.java:74）
在org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init（StrutsPrepareAndExecuteFilter.java： 57）
在io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed（LifecyleIntercept orInvocation.java:111）
在org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init（RunAsLifecycleInterceptor.java:84）
在io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed（LifecyleInterceptorInvocation。 java：97）
在io.undertow.servlet.core.ManagedFilter.createFilter（ManagedFilter.java:80）
在io.undertow.servlet.core.ManagedFilter.getFilter（ManagedFilter.java:66） 
在io.undertow.servlet.core.ManagedFilter.doFilter（ManagedFilter.java:61）
在io.undertow.servlet.handlers.FilterHandler $ FilterChainImpl.doFilter（FilterHandler.java:131）
 at io.undertow.servlet.handlers.FilterHandler.handleRequest（FilterHandler.java:84）
在io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest（ServletSecurityRoleHandler.java:62）
在io.undertow.jsp.JspFileHandler.handleRequest（JspFileHandler.java:32）
在io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest（Servle tDispatchingHandler.java:36）
在org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest（SecurityContextAssociationHandler.java:78）
在io.undertow.server.handlers.PredicateHandler.handleRequest（PredicateHandler。 io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest（ServletAuthenticationCallHandler）中的
 $¬. java：57）
在io.undertow.server.handlers.PredicateHandler.handleRequest（PredicateHandler.java:43）
在io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest（AbstractConfidentialityHandler.java:46） 
在io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest（ServletConfidentialityConstraintHandler.java:64）
在io.undertow.security.handlers.AuthenticationMechanismsHandler.h andleRequest（AuthenticationMechanismsHandler.java:60）
在io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest（CachedAuthenticatedSessionHandler.java:77）
在io.undertow.security.handlers.NotificationReceiverHandler.handleRequest（ NotificationReceiverHandler.java:50）
在io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest（AbstractSecurityContextAssociationHandler.java:43）
在io.undertow.server.handlers.PredicateHandler.handleRequest（PredicateHandler.java： 43）
在org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest（JACCContextIdHandler.java:61）
在io.undertow.server.handlers.PredicateHandler.handleRequest（PredicateHandler.java： 43）
在io.undertow.server.handlers.PredicateHandler.handleRequest（PredicateHandler.java:43）
在io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest（ServletInitialHandler.java:292）
在io.undertow.servlet.handlers.ServletInitialHandler.access $ 100（ServletInitialHandler.java:81）
在io.undertow.servlet.handlers.ServletInitialHandler $ 2.call（ServletInitialHandler.java:138）
在io .retoserver.bat .servlet.core.ContextClassLoaderSetupAction $ 1.call（ContextClassLoaderSetupAction.java:43）
在io.undertow.servlet.api.LegacyThreadSetupActionWrapper $ 1.call（LegacyThreadSetupActionWrapper.java:44）
在io.undertow.servlet .api.LegacyThreadSetupActionWrapper $ 1.call（LegacyThreadSetupActionWrapper.java:44）
在io.undertow.servlet.api.LegacyThreadSetupActionWrapper $ 1.call（LegacyThreadSetupActionWrapper.java:44）
在io.undertow.servlet.api .LegacyThreadSetupActionWrapper $ 1.call（LegacyThreadSetupActionWrapper.java:44） 
在io.undertow.servlet.api.LegacyThreadSetupActionWrapper $ 1.call（LegacyThreadSetupActionWrapper.java:44）
在io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest（ServletInitialHandler.java:272）
在io.undertow.servlet.handlers.ServletInitialHandler.access $ 000（ServletInitialHandler.java:81）
在io.undertow.servlet.handlers.ServletInitialHandler $ 1.handleRequest（ServletInitialHandler.java:104）
 at io.undertow.server.Connectors.executeRootHandler（Connectors.java:202）
在io.undertow.server.HttpServerExchange $ 1.run（HttpServerExchange.java:805）
在java.util.concurrent.ThreadPoolExecutor .runWorker（未知源）
在java.util.concurrent.ThreadPoolExecutor $ Worker.run（未知源）
在java.lang.Thread.run（未知源）
引起的：java .lang.ClassNotFoundException：com.ebs.service.UserAuthorisationService从[Moduledeployment.EBS-web.war：mainfrom Service Module Loader] 
在org.jboss.m odules.ModuleClassLoader.findClass（ModuleClassLoader.java:198）
在org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked（ConcurrentClassLoader.java:363）
在org.jboss.modules.ConcurrentClassLoader.performLoadClass（ConcurrentClassLoader。 java：351）
在org.jboss.modules.ConcurrentClassLoader.loadClass（ConcurrentClassLoader.java:93）
 ... 61更多

从上面我可以理解的是EAR无法找到EJB模块中存在的类，从而抛出异常。我正在使用WildFLy 10服务器和eclipse IDE。

解决方案

一个EAR文件只是一些容器，用于各种企业模块（EJB jar，WAR文件和常规jar文件）定义（但经常被误解）的规则，哪些类可以看到哪些。

在大多数情况下，您将看到具有以下内部结构的EAR文件：

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

为了类可见性的目的，这个EAR上面显示了五个模块：

lib模块

ejb-jar1.jar
ejb-jar2.jar

war1.jar

war2.jar

其中：

lib模块中的所有jar都被认为是相同的模块;

每个WAR文件中的所有jar和类都被认为在同一个模块中;

每个ejb-jar是一个独立的模块

通常，每个模块都有自己的类加载器。

，JBossAS / WildFly放松了类可见性规则，使开发人员更简单（由于历史原因）。在这些服务器实现上，规则是：

每个WAR模块都可以看到它是自己的类，每个EJB jar中的类和每个在EAR / lib目录中的jar
- 在其他 WAR模块中看不到类;

每个EJB模块都可以看到自己的类，其他EJB模块中的类和EAR / lib目录中每个jar中的类;
- 在任何 WAR模块中看不到类;

EAR / lib模块中的类只能看到对方：
- 他们看不到任何 EJB模块或WAR模块

更严格的实现将需要定义的清单类路径条目，以使EJB模块彼此可见和WAR模块。

现在，鉴于上述所有您的特定问题最有可能是：

lib模块中尝试访问其中一个EJB模块或其中一个WAR模块的类的类 - 是否放置在EAR / lib目录中的struts2 jar？

尝试在其中一个WAR模块中访问类的EJB模块中的类

说完所有这一切，你可以使自己的生活更容易，因为你使用JavaEE 7服务器。只需将包含EJB的所有内容打包成WAR文件。您很可能没有从构建和部署EAR获得利益

I am new to the EAR. I have developed a web module and a ejb module which are dependent on each other for the functionality. For that I am trying to confiure them in a EAR. I mapped both web and ejb module to EAR and can see application.xml as

  <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>

But when I try to execute EAR my server throws below exception

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

What I can understand from above is the EAR is not able to locate the classes present in the EJB module and therefore throwing the exception. I am using WildFLy 10 server and eclipse IDE.

解决方案

An EAR file is just a container for various enterprise modules (EJB jars, WAR files and regular jar files) with some well defined (but often misunderstood) rules for which classes can see which.

In most cases, you will see an EAR file with the following internal structure:

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

For the purposes of class visibility, this EAR above shows five modules:

lib module
ejb-jar1.jar
ejb-jar2.jar
war1.jar
war2.jar

where:

All jars in the lib module are considered to be in the same module;
All jars and classes in each WAR file are considered to be in the same module;
Each ejb-jar is an independent module.

Typically, each module has it's own class loader.

Now, JBossAS/WildFly relaxes the class visibility rules a little to make developers lives simpler (and for historical reasons). On these server implementations the rules are:

Each WAR module can see it's own classes, the classes in each EJB jar and the classes in every jar in the the EAR/lib directory
- it cannot see the classes in other WAR modules;
Each EJB module can see it's own classes, the classes in other EJB modules and the classes in every jar in the the EAR/lib directory;
- it cannot see the classes in any WAR modules;
The classes in the EAR/lib module can only see each other:
- they cannot see classes in any EJB modules or WAR modules

A stricter implementation would require the definition of manifest Class-path entries in order to make EJB modules visible to each other and WAR modules.

Now, given all of the above your particular problem is most likely one of:

a class in the lib module attempting to access a class in one of the EJB modules or one of the WAR modules - did you place the struts2 jars in the EAR/lib directory?
a class in an EJB module trying to access a class in one of the WAR modules

Having said all of that you could make your life a lot easier since you're using a JavaEE 7 server. Just package everything including EJBs into a WAR file. Chances are you are gaining no benefit from building and deploying an EAR

这篇关于我的耳朵不能找到ejb模块类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文

我的耳朵不能找到ejb模块类 [英] My ear is not able to find ejb module classes

问题描述

相关文章

Java开发最新文章

热门教程

热门工具

登录关闭

我的耳朵不能找到ejb模块类 [英] My ear is not able to find ejb module classes

问题描述

相关文章

Java开发最新文章

热门教程

热门工具

登录 关闭

登录关闭