[infinispan-dev] On ParserRegistry and classloaders
Sanne Grinovero
sanne at infinispan.org
Mon Oct 13 07:23:05 EDT 2014
So it seems I can workaround most of the below issues by temporarily
setting the ContectClassLoader,
but then there is an additional problem: since I can't pass the
JGroups configuration as an InputStream but this is hardcoded by
resource name in the Infinispan configuration, Infinispan is unable to
load the correct resource.
I'd consider this quite bad for modular usage, and the following issue
makes it more confusing as the error message reported to the user
reports instead an NPE regarding the Transaction Table:
https://issues.jboss.org/browse/ISPN-2145
I hope that improving the error message at least could be prioritized
for version 7.0 Final.
Sanne
On 11 October 2014 17:54, Sanne Grinovero <sanne at infinispan.org> wrote:
> 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 at redhat.com> 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/org/infinispan/util/FileLookup.java
>>
>> https://github.com/infinispan/infinispan/blob/6.0.x/core/src/main/java/org/infinispan/util/FileLookupFactory.java
>>
>> --
>> 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 at infinispan.org> 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 at redhat.com> wrote:
>>>>>
>>>>> Hi Sanne, Galder,
>>>>>
>>>>> On 05/23/2014 07:08 PM, Sanne Grinovero wrote:
>>>>>>
>>>>>> On 23 May 2014 08:03, Galder Zamarreño<galder at redhat.com> 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> Cheers,
>>>
>>
More information about the infinispan-dev
mailing list