Hey Sanne, I’ve looked at ParserRegistry and not sure I see the changes you are referring to… >From what I’ve seen, ParserRegistry has taken class loader in the constructor since the start.

I suspect you might be referring to classloader related changes as a result of OSGI integration?

Cheers, On 19 May 2014, at 17:09, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > I see the ParserRegistry was changed quite a bit; in Infinispan 6 it > allowed to specify a different classloader for some operations, now it > only takes a classloader during construction time. > > For WildFly/JBoss users, it is quite common that the configuration > file we want parsed is not in the same classloader that the > ParserRegistry needs to lookup its own parser components (as its > design uses the ServiceLoader to discover components of the parser). > This is especially true when Infinispan is not used by the application > directly but via another module (so I guess also critical for > capedwarf). > > I initially though to workaround the problem using a "wrapping > classloader" so that I could pass a single CL instance which would try > both the deployment classloader and the Infinispan's module > classloader, but - besides this being suboptimal - it doesn't work as > I'm violating isolation between modules: I can get exposed to an > Infinispan 6 module which contains also Parser components, which get > loaded as a service but are not compatible (different class > definition). > > I'll need these changes in the ParserRegistry reverted please. Happy > to send a pull myself, but before I attempt to patch it myself could > someone explain what the goal was? > > thanks, > Sanne > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño galder(a)redhat.com twitter.com/galderz _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Hi Sanne, Galder, On 05/23/2014 07:08 PM, Sanne Grinovero wrote: > On 23 May 2014 08:03, Galder Zamarreño&lt;galder(a)redhat.com&gt; wrote: >> >Hey Sanne, >> > >> >I’ve looked at ParserRegistry and not sure I see the changes you are referring to… >> > >> >>From what I’ve seen, ParserRegistry has taken class loader in the constructor since the start. > Yes, and that was good as we've been using it: it might need > directions to be pointed at the right modules to load extension > points. > > My problem is not that the constructor takes a ClassLoader, but that > other options have been removed; essentially in my scenario the module > containing the extension points does not contain the configuration > file I want it to load, and the actual classLoader I want the > CacheManager to use is yet a different one. As explained below, > assembling a single "catch all" ClassLoader to delegate to all doesn't > work as some of these actually need to be strictly isolated to prevent > ambiguities. > >> >I suspect you might be referring to classloader related changes as a result of OSGI integration? > I didn't check but that sounds like a reasonable estimate. I had a look at the OSGi-related changes done for this class and they don't alter the class interface in any way. The implementation changes related to FileLookup seem to maintain the same behavior for non-OSGi contexts also. Regards, Ion Savin _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Ion, Martin - what are your thoughts? On Jul 29, 2014, at 16:34, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > All, > in Search we wrap the Parser in a decorator which workarounds the > classloader limitation. > I still think you should fix this, it doesn't matter how/why it was changed. > > Sanne > > On 26 May 2014 11:06, Ion Savin <isavin(a)redhat.com&gt; wrote: >> Hi Sanne, Galder, >> >> On 05/23/2014 07:08 PM, Sanne Grinovero wrote: >>> On 23 May 2014 08:03, Galder Zamarreño&lt;galder(a)redhat.com&gt; wrote: >>>>> Hey Sanne, >>>>> >>>>> I’ve looked at ParserRegistry and not sure I see the changes you are referring to… >>>>> >>>>>> From what I’ve seen, ParserRegistry has taken class loader in the constructor since the start. >>> Yes, and that was good as we've been using it: it might need >>> directions to be pointed at the right modules to load extension >>> points. >>> >>> My problem is not that the constructor takes a ClassLoader, but that >>> other options have been removed; essentially in my scenario the module >>> containing the extension points does not contain the configuration >>> file I want it to load, and the actual classLoader I want the >>> CacheManager to use is yet a different one. As explained below, >>> assembling a single "catch all" ClassLoader to delegate to all doesn't >>> work as some of these actually need to be strictly isolated to prevent >>> ambiguities. >>> >>>>> I suspect you might be referring to classloader related changes as a result of OSGI integration? >>> I didn't check but that sounds like a reasonable estimate. >> >> I had a look at the OSGi-related changes done for this class and they >> don't alter the class interface in any way. The implementation changes >> related to FileLookup seem to maintain the same behavior for non-OSGi >> contexts also. >> >> Regards, >> Ion Savin >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers,

Hi all, sorry it took me quite some time to return on this, but it's still troublesome and quite critical to allow using Infinispan as a module. I'm again trying to use Infinispan's JBoss Modules as a (library) for deployed application, and it fails because of: Caused by: java.lang.ClassNotFoundException: org.infinispan.remoting.transport.jgroups.JGroupsTransport from [Module \"deployment.ModuleMemberRegistrationIT.war:main\" from Service Module Loader]"}} Debugging the application server, the stack is pointing to this method : public TransportConfigurationBuilder defaultTransport() { Transport transport = Util.getInstance(DEFAULT_TRANSPORT, this.getGlobalConfig().getClassLoader()); <------- Failure here transport(transport); return this; } The getClassLoader() function returns a reference to the application deployment (as you can see in the error above). This code makes sense I think, but then inspecting in the "Util.getInstance" method we see that it's not strictly using the classloaders we pass, but it's going to look in a specific sequence as defined by this function: public static ClassLoader[] getClassLoaders(ClassLoader appClassLoader) { return new ClassLoader[] { appClassLoader, // User defined classes OsgiClassLoader.getInstance(), // OSGi bundle context needs to be on top of TCCL, system CL, etc. Util.class.getClassLoader(), // Infinispan classes (not always on TCCL [modular env]) ClassLoader.getSystemClassLoader(), // Used when load time instrumentation is in effect Thread.currentThread().getContextClassLoader() //Used by jboss-as stuff }; } Now to clarify one thing: the deployment does NOT have direct visibility to the Infinispan modules. The application is depending on Hibernate Search, and I can't allow Infinispan to leak visibility to the application. So going through the list, none of the classloaders actually have the class from Infinispan Core because: appClassLoader -> doesn't have access to any Infinispan jar OsgiClassLoader.getInstance() -> OSGi only (right? I'm not too clear on this one.. BTW the OsgiClassLoader.getInstance() is clearly not threadsafe) Util.class.getClassLoader(), // Infinispan classes (not always on TCCL [modular env]) <- (That's the comment in the code) Well NO, this comment was probably correct when Util.class was included into infinispan-core.. but now this function just returns the modular classloader of Infinispan Commons ! It doesn't expose the JGroupsTransport. I hoped I could configure the ClassLoader, but I've already done that: 1 ClassLoader ispnClassLoadr = ParserRegistry.class.getClassLoader(); 2 configurationParser = new ParserRegistry( ispnClassLoadr ); // Make sure the Parser is using the module having access to Infinispan Core 3 ConfigurationBuilderHolder builderHolder = configurationParser.parse( is ); // I have to pass a stream so that I can load the resource from the user module 4 patchInfinispanClassLoader( builderHolder ); // AFTER I have the builderHolder, I can use an utility method to correct the classloaders But the above exception is triggered at line *3* so I have no opportunity to amend any classloader. In summary: the defaultTransport() is triggered during XML parsing and it's going to ignore any programmatically set classloader. A patch proposal would be to change the following line from the GlobalConfigurationBuilder() constructor: ClassLoader defaultCL = Util.isOSGiContext() ? GlobalConfigurationBuilder.class.getClassLoader() : Thread.currentThread().getContextClassLoader(); to a simple: ClassLoader defaultCL = GlobalConfigurationBuilder.class.getClassLoader(); But the function generating the chain of classloaders should probably also need to be fixed.. I suspect it would be much easier if we could agree to: A) accept classloaders on the methods which need it B) Stick to the given classloaders without applying unrequested and surprising overrides My workaround in Search is going to be to set the ContextClassloader; that resolved my problem but it's piling up on other workarounds related to Infinispan initialization and classloaders. I'm not opening JIRA's here as I'm not clear on which ones are bugs, and how many of these are intentional.. please take that judgement task. Thanks, Sanne On 30 July 2014 20:21, Ion Savin <isavin(a)redhat.com&gt; wrote: > Hi Sanne, > > I don't see any changes in the ParserRegistry which would have removed the > behavior you describe (at least looking at the OSGi changes). Can you point > me please to some code which used to work in the past? > > I've found two classes which have some reference to Hibernate in comments > and the factory was removed part of the OSGi changes. Are these perhaps the > changes which you are missing? > > https://github.com/infinispan/infinispan/blob/6.0.x/core/src/main/java/or... > > https://github.com/infinispan/infinispan/blob/6.0.x/core/src/main/java/or... > > -- > Ion Savin > > > On 07/30/2014 09:17 PM, Mircea Markus wrote: >> >> Ion, Martin - what are your thoughts? >> >> On Jul 29, 2014, at 16:34, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: >> >>> All, >>> in Search we wrap the Parser in a decorator which workarounds the >>> classloader limitation. >>> I still think you should fix this, it doesn't matter how/why it was >>> changed. >>> >>> Sanne >>> >>> On 26 May 2014 11:06, Ion Savin <isavin(a)redhat.com&gt; wrote: >>>> >>>> Hi Sanne, Galder, >>>> >>>> On 05/23/2014 07:08 PM, Sanne Grinovero wrote: >>>>> >>>>> On 23 May 2014 08:03, Galder Zamarreño&lt;galder(a)redhat.com&gt; wrote: >>>>>>> >>>>>>> Hey Sanne, >>>>>>> >>>>>>> I’ve looked at ParserRegistry and not sure I see the changes you are >>>>>>> referring to… >>>>>>> >>>>>>>> From what I’ve seen, ParserRegistry has taken class loader in the >>>>>>>> constructor since the start. >>>>> >>>>> Yes, and that was good as we've been using it: it might need >>>>> directions to be pointed at the right modules to load extension >>>>> points. >>>>> >>>>> My problem is not that the constructor takes a ClassLoader, but that >>>>> other options have been removed; essentially in my scenario the module >>>>> containing the extension points does not contain the configuration >>>>> file I want it to load, and the actual classLoader I want the >>>>> CacheManager to use is yet a different one. As explained below, >>>>> assembling a single "catch all" ClassLoader to delegate to all doesn't >>>>> work as some of these actually need to be strictly isolated to prevent >>>>> ambiguities. >>>>> >>>>>>> I suspect you might be referring to classloader related changes as a >>>>>>> result of OSGI integration? >>>>> >>>>> I didn't check but that sounds like a reasonable estimate. >>>> >>>> >>>> I had a look at the OSGi-related changes done for this class and they >>>> don't alter the class interface in any way. The implementation changes >>>> related to FileLookup seem to maintain the same behavior for non-OSGi >>>> contexts also. >>>> >>>> Regards, >>>> Ion Savin >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> Cheers, >> >

Caused by: java.lang.ClassNotFoundException: org.infinispan.remoting.transport.jgroups.JGroupsTransport from [Module \"deployment.ModuleMemberRegistrationIT.war:main\" from Service Module Loader]"}}