Java Gigaspaces：动态；“模板类”；“装载原因”；ClassNotFoundException“；在TypeManager.registerTypeDescriptor（类）上

Gigaspaces 9.6、Java 6

我正在开发一个模块系统，它可以从不在系统类路径中的外部.jar文件动态加载模块的类。每个模块都有自己的类装入器（用于沙箱）。一旦我从外部jar加载了模板类并将其注册到TypeManager，它就会导致ClassNotFoundException

（我试图通过向系统类路径添加包含模板类的.jar来解决这个问题，它可以工作！这表明LRMI的动态类加载正常工作。）

这是堆栈跟踪：

警告：异步执行失败：java.lang.ClassNotFoundException: DefaultClassProvider[4756891978928899637]找不到必需的 在指定的类加载器[1]上初始化[employeedb.dto.Employee]， request=com.tum.108af67ad46743668d724c8caa45e160_container1:com.tum.108af67ad46743668d724c8caa45e160=>RegisterEntryTypeDescriptorSpaceOperationRequest[typeName=employeedb.dto.Employee，校验和=1804124240，gatewayProxy=false] 严重：org.openspaces.core.SpaceMetadataException:中出错 registerTypeDescInServers（）远程任务执行。 TypeName=employeedb.dto.Employee；嵌套异常是 java.lang.ClassNotFoundException:DefaultClassProvider [4756891978928899637]找不到所需的类 [employeedb.dto.Employee]位于指定的类加载器[1]处 org.openspaces.core.exception.DefaultExceptionTranslator.internalTranslate（DefaultExceptionTranslator.java:126） 在 org.openspaces.core.exception.DefaultExceptionTranslator.translate（DefaultExceptionTranslator.java:50） 在 org.openspaces.core.DefaultGigaSpaceTypeManager.registerTypeDescriptor（DefaultGigaSpaceTypeManager.java:73） 在 com.magpieos.core.nestvm.PersistenceServiceManager.registerTypeDescriptor（PersistenceServiceManager.java:146） 在 com.magpieos.core.nestvm.PersistenceServiceManager.registerTypeDescriptor（PersistenceServiceManager.java:140） 在 com.magpieos.core.nestvm.PersistenceServiceManager.registerTypeDescriptor（PersistenceServiceManager.java:136） 位于com.filter.PortalActionFilter.myInit（PortalActionFilter.java:210） 位于com.filter.PortalActionFilter.doFilter（PortalActionFilter.java:113） 在 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter（ApplicationFilterChain.java:256） 在 org.apache.catalina.core.ApplicationFilterChain.doFilter（ApplicationFilterChain.java:217） 在 org.apache.catalina.core.StandardWrapperValve.invoke（StandardWrapperValve.java:279） 在 org.apache.catalina.core.StandardContextValve.invoke（StandardContextValve.java:175） 在 org.apache.catalina.core.StandardPipeline.doInvoke（StandardPipeline.java:655） 在 org.apache.catalina.core.StandardPipeline.invoke（StandardPipeline.java:595） 在 org.apache.catalina.core.StandardHostValve.invoke（StandardHostValve.java:161） 在 org.apache.catalina.connector.CoyoteAdapter.doService（CoyoteAdapter.java:331） 在 org.apache.catalina.connector.CoyoteAdapter.service（CoyoteAdapter.java:231） 在 com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call（ContainerMapper.java:317） 在 com.sun.enterprise.v3.services.impl.ContainerMapper.service（ContainerMapper.java:195） 在 com.sun.grizzly.http.ProcessorTask.invokeAdapter（ProcessorTask.java:860） 在 com.sun.grizzly.http.ProcessorTask.doProcess（ProcessorTask.java:757） 位于com.sun.grizzly.http.ProcessorTask.process（ProcessorTask.java:1056） 在 com.sun.grizzly.http.DefaultProtocolFilter.execute（DefaultProtocolFilter.java:229） 在 com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter（DefaultProtocolChain.java:137） 在 com.sun.grizzly.DefaultProtocolChain.execute（DefaultProtocolChain.java:104） 在 com.sun.grizzly.DefaultProtocolChain.execute（DefaultProtocolChain.java:90） 在 http.HttpProtocolChain.execute（HttpProtocolChain.java:79） 在 ProtocolChainContextTask.doCall（ProtocolChainContextTask.java:54） 在 com.sun.grizzly.SelectionKeyContextTask.call（SelectionKeyContextTask.java:59） 在com.sun.grizzly.ContextTask.run（ContextTask.java:71）上 com.sun.grizzly.util.AbstractThreadPool$Worker.doWork（AbstractThreadPool.java:532） 在 com.sun.grizzly.util.AbstractThreadPool$Worker.run（AbstractThreadPool.java:513） 在java.lang.Thread.run（Thread.java:662）处，由以下原因引起： java.lang.ClassNotFoundException:DefaultClassProvider [4756891978928899637]找不到所需的类 [employeedb.dto.Employee]位于指定的类加载器[1]处 gigaspaces.lrmi.classloading.DefaultClassProvider.getClassDefinition（DefaultClassProvider.java:109） 在 com.gigaspaces.lrmi.classloading.IClassProviderGigaspacesMethodinternalInvoke2.internalInvoke（未知 来源）在 com.gigaspaces.internal.reflection.fast.AbstractMethod.invoke（AbstractMethod.java:41） 在com.gigaspaces.lrmi.LRMIRuntime.called（LRMIRuntime.java:450）中 com.gigaspaces.lrmi.nio.Pivot.ConsumerandHandlerRequest（Pivot.java:557） 位于com.gigaspaces.lrmi.nio.Pivot.handleRequest（Pivot.java:658） Pivot$ChannelEntryTask.run（Pivot.java:196）位于 java.util.concurrent.ThreadPoolExecutor$Worker.runTask（ThreadPoolExecutor.java:886） 在 java.util.concurrent.ThreadPoolExecutor$Worker.run（ThreadPoolExecutor.java:908） ... 还有一个

我的问题是：

---

如果常规LRMI服务器（GSC）/LRMI客户端的类路径中不存在类，我是否能够实现自己的类加载器，将类加载委托给外部JAR？

如果您看到GigaSpaces的类加载器部分，它会说：

就类加载器委托模型而言，服务（PU实例） 类加载器使用父上次委派模式。这意味着 处理单元实例类加载器将首先尝试并加载类 仅当

       Bootstrap (Java)

              |
           System (Java)
              |
           Common (Service Grid)
         /        \
Service CL1     Service CL2