Gigaspaces:动态“模板类”加载导致TypeManager.registerTypeDescriptor上的“TypeManager.registerTypeDescriptor”(类)

Question

GigaSpace9.6，Java6

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

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

这里是堆栈跟踪：

警告:异步执行失败: java.lang.ClassNotFoundException: DefaultClassProvider 4756891978928899637无法在指定的类加载器1、java.lang.ClassNotFoundException checksum=1804124240、gatewayProxy=false checksum=1804124240: org.openspaces.core.SpaceMetadataException: Error in registerTypeDescInServers()远程任务执行中找到必需的类employeedb.dto.Employee。TypeName=employeedb.dto.Employee；嵌套的例外情况是org.openspaces.core.exception.DefaultExceptionTranslator.internalTranslate(DefaultExceptionTranslator.java:126)：DefaultClassProvider 4756891978928899637无法在指定的类加载器1、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上找到所需的类employeedb.dto.Employee。nestvm.PersistenceServiceManager.registerTypeDescriptor(PersistenceServiceManager.java:140) at com.magpieos.core.nestvm.PersistenceServiceManager.registerTypeDescriptor(PersistenceServiceManager.java:136) at com.filter.PortalActionFilter.myInit(PortalActionFilter.java:210) at com.filter.PortalActionFilter.doFilter(PortalActionFilter.java:113) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) at org.apache.catalina.core.StandardWrapperValve.调用(StandardWrapperValve.java:279)在org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) at org.apache。catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757) at com.sun.grizzly.http.ProcessorTask.process(com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662)：java.lang.ClassNotFoundException: DefaultClassProvider 4756891978928899637无法找到所需的类employeedb.dto指定类装入器1在com.gigaspaces.lrmi.classloading.DefaultClassProvider.getClassDefinition(DefaultClassProvider.java:109) at com.gigaspaces.lrmi.classloading.IClassProviderGigaspacesMethodinternalInvoke2.internalInvoke(Unknown Source)在com.gigaspaces.internal.reflection.fast.AbstractMethod.invoke(AbstractMethod.java:41) at com.gigaspaces.lrmi.LRMIRuntime.invoked(LRMIRuntime.java:450) at com.gigaspaces.lrmi.nio.Pivot.consumeAndHandleRequest(Pivot.java:557) at com.gigaspaces.lrmi.nio.Pivot.handleRequest( com.gigaspaces.lrmi.nio.Pivot$ChannelEntryTask.run(Pivot.java:196) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) .1)

我的问题是：

如果普通的LRMI (GSC)/ LRMI客户端的类路径中不存在类，那么我是否能够实现自己的类加载器，该类将委托给外部jars？

Answer 1

如果您看到ClassLoader部分的GigaSpaces GigaSpaces Wiki类装载机，它会说：

在类加载器委托模型方面，服务(PU实例)类加载器使用父级最后一次委托模式。这意味着处理单元实例类加载器将首先尝试并从其自己的类加载器加载类，并且只有在找不到它们时，才会委托给父类加载程序。

如果您也向下看，会看到使用的类加载器层次结构的描述：

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

因此，我建议您使用JVM参数java.system.class.loader使用不同的系统类加载器启动JVM，以便当GigaSpaces委托时，类加载器将找到这些类。