[infinispan-dev] On ParserRegistry and classloaders

[Ion Savin]

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