Apologies for the delay -- things have been nuts.
Here's the route I've taken so far. I created OsgiClassLoader that
searches available Bundles for classes and resources. A new (non-static)
AggregateClassLoader replaces FileLookup, CL-related methods in Util, and
parts of ReflectionUtil. AggregateClassLoader extends/overrides
ClassLoader and searches over a prioritized list of user/app CL, OsgiCL,
System CL, TCCL, etc.
This is easily wired into GlobalConfiguration concepts. However, I'm not
exactly sure how this will play into Configuration and Cache.
Configuration#classLoader is deprecated. Is that in favor of
CacheImpl#getClassLoader & CacheImpl#with(ClassLoader)?
Actually, I think the idea was to only set the classloader in the
GlobalConfiguration and use a separate CacheManager for each deployment,
removing the need for AdvancedCache.with(ClassLoader) as well. But I'm not
sure if we'll ever get to that...
AdvancedCache.with(ClassLoader) is also very limited in scope. The
classloader can't be sent remotely so AFAICT it's only really useful for
unmarshalling return values for get operations with storeAsBinary enabled.
Can someone describe the scoping of CL concepts between
GlobalConfiguration and the Configuration/Cache? Should both have their
own instance of AggregateClassLoader? Cache's instance would put the
user/app provided CL on the top of the queue?
Sounds about right.
For marshalling, ATM we use an EmbeddedContextClassResolver, which uses the
InvocationContextContainer to obtain the classloader set by the user with
AdvancedCache.with(ClassLoader) (unlike JBoss Marshalling's
ContextClassResolver, which uses the TCCL). You will probably want to
implement your own ClassResolver based on AggregateClassLoader, but using
InvocationContextContainer as well.
I'm not sure about other places where we need to load classes. While
working on
I did find some
instances of ServiceLoader.load(Class), which use the TCCL implicitly, but
I'm trying to change that to use the global/cache configuration's
classloader.
Hopefully that all makes sense...
Brett Meyer
Red Hat, Hibernate ORM
----- Original Message -----
From: "Galder Zamarreño" <galder(a)redhat.com>
To: "Eric Wittmann" <eric.wittmann(a)redhat.com>
Cc: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>, "Brett
Meyer" <brmeyer(a)redhat.com>, "Sanne Grinovero"
<sanne(a)hibernate.org>,
"Pete Muir" <pmuir(a)redhat.com>, "Randall Hauch"
<rhauch(a)redhat.com>,
"Steve Jacobs" <sjacobs(a)redhat.com>
Sent: Wednesday, December 18, 2013 8:22:13 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi
On Dec 16, 2013, at 3:00 PM, Eric Wittmann <eric.wittmann(a)redhat.com>
wrote:
> I wanted to add that in the Overlord group we're also looking into using
ISPN in OSGi. Our directive is to get our projects running in Fuse 6.1.
>
> To that end I've been working on getting Overlord:S-RAMP up and running,
which requires both ModeShape and ISPN.
>
> Additionally, Gary Brown uses ISPN in Overlord:RTGov and so will need to
get it working directly (no ModeShape) in Fuse 6.1.
>
> I've made some progress on my end but have run into some of the same
issues as Brett.
>
> An additional issue I hit was the use of Java's ServiceLoader for
org.infinispan.configuration.parsing.ConfigurationParser. None of the
parsers get loaded because ServiceLoader doesn't work particularly well in
OSGi. We had this same issue in S-RAMP (we use ServiceLoader in a few
places). I solved it by using the OSGi Service Registry when running in an
OSGi container, but continuing to use ServiceLoader otherwise.
^ Can you add a JIRA for this so that we can abstract this away? I'm not
sure how exactly we'd decide on the impl to use. By default it'd be SL
impl. When used on OSGI though, an alternative service loading impl would
need to be configured specifically by the user? Or would Infinispan itself
detect that it's in OSGi and hence used the corresponding impl? I've no
idea about OSGI.
> In any case - I was wondering if anyone thought it might be a good idea
to create a git repo where we can create some test OSGi applications that
use ISPN and can be deployed (e.g. to Fuse). This would be for testing
purposes only - to shake out problems. Might be useful for collaboration?
A quickstart on [1] would be the perfect place for something like that,
i.e. fuse + infinispan or something like that.
[1]
http://www.jboss.org/jdf/quickstarts/get-started/
>
> -Eric
>
>
> On 12/12/2013 12:55 PM, Brett Meyer wrote:
>> I finally had a chance to start working with this, a bit, today.
Here's what I've found so far.
>>
>> In general, I'm seeing 2 types of CL issues come up when testing w/
hibernate-infinispan:
>>
>> 1.) Reliance on the client bundle's CL. Take the following stack as an
example:
https://gist.github.com/brmeyer/c8aaa1157a4a951a462c.
Hibernate's InfinispanRegionFactory is building a
ConfigurationBuilderHolder. Parser60#parseTransport eventually gives the
ConfigurationBuilderHolder#getClassLoader to Util#loadClass. But since
this thread is happening within the hibernate-infinispan bundle, that CL
instance is hibernate-infinispan's BundleWiring. If hibernate-infinispan's
manifest explicitly imports the package being loaded, this works fine.
But, as I hit, that's not usually the case. This stack fails when it
attempted to load
org.infinispan.remoting.transport.jgroups.JGroupsTransport. Adding
org.infinispan.remoting.transport.jgroups to our imports worked, but that's
not ideal.
>>
>> 2.) Reliance on TCCL. See GlobalConfigurationBuilder#cl as an example.
TCCL should be avoided at all costs. Here's an example:
https://gist.github.com/brmeyer/141ea83fb632dd126406. Yes,
ConfigurationBuilderHolder could attempt to pass in a CL to
GlobalConfigurationBuilder, but we'd run into the same situation for #1.
In this specific example, we're trying to load the
"infinispan-core-component-metadata.dat" resource within the
infinispan-core bundle, not visible to the hibernate-infinispan bundle CL.
>>
>> commons already has a step towards a solution: OsgiFileLookup.
However, it scans over *all* bundles activated in the container. There's
certainly performance issues with that, but more importantly can introduce
conflicts (multiple versions of Infinispan or client bundles running
simultaneously, a resource existing in multiple bundles, etc.).
>>
>> What we did in Hibernate was to introduce an OSGi-specific
implementation of ClassLoader that's aware of what bundles it needs to
consider. In frameworks with multiple bundles/modules, this is definitely
more complicated. For now, we limit the scope to core, entitymanager
(JPA), and the "requesting bundle" (the client bundle requesting the
Session). The "requesting bundle" concept was important for us since we
scan and rely on the client bundle's entities, mapping files, etc.
>>
>> There are several routes, but all boil down to relying on OSGi APIs to
use Bundles to discover classes and resources, with TCCL &
Class#getClassLoader as a just-in-case backup. How the scope of that
Bundle set is defined is largely up to the framework's existing
architecture and dependency tree.
>>
>> What I might recommend as a first step would be expanding/refactoring
OsgiFileLookup to include loading classes, but continue to allow it to scan
all bundles (for now). That will at least remove the initial CL issues.
But, that would need to be followed up.
>>
>> Before I keep going down the rabbit hole, just wanted to see if there
were any other thoughts. I'm making general assumptions without knowing
much about Infinispan's architecture. Thanks!
>>
>> Brett Meyer
>> Red Hat, Hibernate ORM
>>
>> ----- Original Message -----
>> From: "Brett Meyer" <brmeyer(a)redhat.com>
>> To: "Randall Hauch" <rhauch(a)redhat.com>, "infinispan -Dev
List" <
infinispan-dev(a)lists.jboss.org>
>> Cc: "Pete Muir" <pmuir(a)redhat.com>, "Steve Jacobs"
<sjacobs(a)redhat.com>
>> Sent: Friday, December 6, 2013 11:56:42 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>>
>> Sorry, forgot the link:
>>
>> [1]
https://hibernate.atlassian.net/browse/HHH-8214
>>
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>>
>> ----- Original Message -----
>> From: "Brett Meyer" <brmeyer(a)redhat.com>
>> To: "Randall Hauch" <rhauch(a)redhat.com>, "infinispan -Dev
List" <
infinispan-dev(a)lists.jboss.org>
>> Cc: "Pete Muir" <pmuir(a)redhat.com>, "Steve Jacobs"
<sjacobs(a)redhat.com>
>> Sent: Friday, December 6, 2013 11:51:33 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>>
>> Randall, that is *definitely* the case and is certainly true for
Hibernate. The work involved:
>>
>> * correctly resolving ClassLoaders based on the activated bundles
>> * supporting multiple containers and contexts (container-managed JPA,
un-managed JPA/native, etc.)
>> * fully supporting OSGi/Blueprint services (both for internal services
as well as externally-registered)
>> * bundle scanning
>> * generally working towards supporting the dynamic nature
>> * full unit-tests with Arquillian and an OSGi container
>>
>> It's a matter of holistically supporting the "OSGi way" (for
better or
worse), as opposed to simply ensuring the library's manifest is correct.
>>
>> There were a bloody ton of gotchas and caveats I hit along the way.
That's more along the lines of where I might be able to help.
>>
>> I'm even more interested in this effort so that we can support
hibernate-infinispan 2nd level caching within ORM. On the first attempt, I
hit ClassLoader issues [1]. Some of that may already be resolved.
>>
>> The next step may simply be giving hibernate-infinispan another shot
and correcting things as I find them. In parallel, feel free to let me
know if there's anything else! ORM supports lots of OSGi-enabled extension
points, etc. that are powerful for users, but obviously I don't have the
Infinispan knowledge to know what would be necessary.
>>
>> Thanks!
>>
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>>
>> ----- Original Message -----
>> From: "Randall Hauch" <rhauch(a)redhat.com>
>> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
>> Cc: "Pete Muir" <pmuir(a)redhat.com>, "Brett Meyer"
<brmeyer(a)redhat.com>
>> Sent: Friday, December 6, 2013 10:57:23 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>>
>> Brett, correct me if I’m wrong, but isn’t there a difference in making
some library *work* in an OSGi environment and making that library
*naturally fit well* in an OSGi-enabled application? For example, making
the JAR’s be OSGi bundles is easy and technically makes it possible to
deploy a JAR into an OSGi env, but that’s not where the payoff is. IIUC
what you really want is a BundleActivator or Declarative Services [1] so
that the library’s components are readily available in a naturally-OSGi way.
>>
>> [1]
http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code....
>>
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus(a)redhat.com> wrote:
>>
>>> + infinispan-dev
>>>
>>> Thanks for offering to look into this Brett!
>>> We're already producing OSGi bundles for our modules, but these are
not tested extensively so if you'd review them and test them a bit would be
great!
>>> Tristan can get you up to speed with this.
>>>
>>>
>>>>> Sanne/Galder/Pete,
>>>>>
>>>>> Random question: what's the current state of making Infinispan
OSGi
friendly? I'm definitely interested in helping, if it's still a need.
This past year, I went through the exercise of making Hibernate work well
in OSGi, so all of challenges (read: *many* of them) are still fairly fresh
on my mind. Plus, I'd love for hibernate-infinispan to work in OSGi.
>>>>>
>>>>> If you're up for it, fill me in? I'm happy to pull
everything down
and start working with it.
>>>>>
>>>>> Brett Meyer
>>>>> Software Engineer
>>>>> Red Hat, Hibernate ORM
>>>>>
>>>>
>>>
>>> Cheers,
>>> --
>>> Mircea Markus
>>> Infinispan lead (
www.infinispan.org)
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev