Re: [infinispan-dev] help with Infinispan OSGi

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Mircea Markus-2
+ 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Randall Hauch
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.html

On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Balázs Zsoldos
Hi,

you might be interested that we work on this. We have just created an OSGi Declarative Services component that uses the latest Infinispan-JCache code. Well, this component is pretty primitive, there are only a couple of configuration possibilities:
 - Clustername
 - IP
 - Port

The interface of the service that the Component implements has only one function:

 - Cache createCache(cacheConfiguration);

cacheConfiguration contains some possibilities like the type (distributed/replicated), maxIdle, maxEntries, ...

We had only one problem till now. The infinispan-jcache wired to the javax.enterprise.context and some other packages, although we do not use them in the OSGi world. We made them optional in the MANIFEST.MF and uploaded it to our maven repository.

The component will be released very soon (within days) at GitHub. It will be part of our OpenSource framework. Every other components will be able to create caches for themselves based on the cacheFactory component.

If you are interested, I will keep you up-to-date on this mailing list.

Btw.: This is the MANIFEST we use in infinispan-jcache that made everything work (till now) (look for the word "optional" to see what we had to change):

Import-Package: javax.cache;version="[1.0,2)",javax.cache.annotation;ver
 sion="[1.0,2)",javax.cache.configuration,javax.cache.event;version="[1.
 0,2)",javax.cache.expiry,javax.cache.integration,javax.cache.management
 ,javax.cache.processor,javax.cache.spi;version="[1.0,2)",javax.enterpri
 se.context;resolution:=optional,javax.enterprise.context.spi;resolution
 :=optional,javax.enterprise.event;resolution:=optional,javax.enterprise
 .inject;resolution:=optional,javax.enterprise.inject.spi;resolution:=op
 tional,javax.inject;resolution:=optional,javax.interceptor;resolution:=
 optional,javax.management,javax.naming,javax.transaction;version="[1.1,
 2)",javax.transaction.xa;version="[1.1,2)",javax.xml.namespace,org.infi
 nispan;version="[6.0,7)",org.infinispan.cdi;resolution:=optional;versio
 n="[6.0,7)",org.infinispan.commands;version="[6.0,7)",org.infinispan.co
 mmands.read;version="[6.0,7)",org.infinispan.commands.tx;version="[6.0,
 7)",org.infinispan.commons;version="[6.0,7)",org.infinispan.commons.api
 ;version="[6.0,7)",org.infinispan.commons.configuration;version="[6.0,7
 )",org.infinispan.commons.marshall;version="[6.0,7)",org.infinispan.com
 mons.util;version="[6.0,7)",org.infinispan.commons.util.concurrent;vers
 ion="[6.0,7)",org.infinispan.configuration.cache;version="[6.0,7)",org.
 infinispan.configuration.global;version="[6.0,7)",org.infinispan.config
 uration.parsing;version="[6.0,7)",org.infinispan.container;version="[6.
 0,7)",org.infinispan.container.entries;version="[6.0,7)",org.infinispan
 .container.versioning;version="[6.0,7)",org.infinispan.context;version=
 "[6.0,7)",org.infinispan.factories;version="[6.0,7)",org.infinispan.int
 erceptors;version="[6.0,7)",org.infinispan.interceptors.base;version="[
 6.0,7)",org.infinispan.jmx;version="[6.0,7)",org.infinispan.lifecycle;v
 ersion="[6.0,7)",org.infinispan.manager;version="[6.0,7)",org.infinispa
 n.marshall.core;version="[6.0,7)",org.infinispan.metadata;version="[6.0
 ,7)",org.infinispan.notifications;version="[6.0,7)",org.infinispan.noti
 fications.cachelistener.annotation;version="[6.0,7)",org.infinispan.not
 ifications.cachelistener.event;version="[6.0,7)",org.infinispan.persist
 ence.manager;version="[6.0,7)",org.infinispan.persistence.spi;version="
 [6.0,7)",org.infinispan.persistence.support;version="[6.0,7)",org.infin
 ispan.remoting;version="[6.0,7)",org.infinispan.remoting.transport;vers
 ion="[6.0,7)",org.infinispan.remoting.transport.jgroups;version="[6.0,7
 )",org.infinispan.stats;version="[6.0,7)",org.infinispan.transaction;ve
 rsion="[6.0,7)",org.infinispan.transaction.xa;version="[6.0,7)",org.inf
 inispan.transaction.xa.recovery;version="[6.0,7)",org.infinispan.util;v
 ersion="[6.0,7)",org.infinispan.util.concurrent;version="[6.0,7)",org.i
 nfinispan.util.concurrent.locks.containers;version="[6.0,7)",org.infini
 span.util.logging;version="[6.0,7)",org.jboss.logging;version="[3.1,4)"
 ,org.jgroups;version="[3.4,4)"


Regards,

Balazs Zsoldos
Software Architect
Mobile: +36-70/594-92-34

Everit Kft.

Everit OpenSource


On Fri, Dec 6, 2013 at 4:57 PM, Randall Hauch <[hidden email]> wrote:
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.html

On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Brett Meyer
In reply to this post by Randall Hauch
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" <[hidden email]>
To: "infinispan -Dev List" <[hidden email]>
Cc: "Pete Muir" <[hidden email]>, "Brett Meyer" <[hidden email]>
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.html

On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Brett Meyer
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" <[hidden email]>
To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
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" <[hidden email]>
To: "infinispan -Dev List" <[hidden email]>
Cc: "Pete Muir" <[hidden email]>, "Brett Meyer" <[hidden email]>
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.html

On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Randall Hauch
I’d love to see this work proceed for Infinispan, since we want to do the same thing for ModeShape, which uses (but does not hide or encapsulate) Infinispan.


On Dec 6, 2013, at 10:56 AM, Brett Meyer <[hidden email]> wrote:

> 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" <[hidden email]>
> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
> 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" <[hidden email]>
> To: "infinispan -Dev List" <[hidden email]>
> Cc: "Pete Muir" <[hidden email]>, "Brett Meyer" <[hidden email]>
> 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.html
>
> On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Luca Stancapiano
Hi Randall...... there is a opened issue on infinispan:

https://issues.jboss.org/browse/ISPN-800

It should be ok. It need only a simple test.

> I’d love to see this work proceed for Infinispan, since we want to do the
> same thing for ModeShape, which uses (but does not hide or encapsulate)
> Infinispan.
>
>
> On Dec 6, 2013, at 10:56 AM, Brett Meyer <[hidden email]> wrote:
>
>> 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" <[hidden email]>
>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List"
>> <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>> 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" <[hidden email]>
>> To: "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Brett Meyer" <[hidden email]>
>> 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.html
>>
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>


--
Luca Stancapiano
javaee consultant
skype: flashboss62
mobile: +393381584484
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Brett Meyer
In reply to this post by Brett Meyer
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" <[hidden email]>
To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
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" <[hidden email]>
To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
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" <[hidden email]>
To: "infinispan -Dev List" <[hidden email]>
Cc: "Pete Muir" <[hidden email]>, "Brett Meyer" <[hidden email]>
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.html

On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Eric Wittmann
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.

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?

-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" <[hidden email]>
> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
> 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" <[hidden email]>
> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
> 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" <[hidden email]>
> To: "infinispan -Dev List" <[hidden email]>
> Cc: "Pete Muir" <[hidden email]>, "Brett Meyer" <[hidden email]>
> 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.html
>
> On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Sanne Grinovero-2
Hi Eric,
thanks that sounds great, having a solid collection of tests is
probably the most usefull specification for what we need to achieve.

@Infinispan team: could we add such tests in the Infinispan
repository? I think that's where they belong.

Sanne

On 16 December 2013 14:00, Eric Wittmann <[hidden email]> 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.
>
> 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?
>
> -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" <[hidden email]>
>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List"
>> <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>> 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" <[hidden email]>
>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List"
>> <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>> 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" <[hidden email]>
>> To: "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Brett Meyer" <[hidden email]>
>> 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.html
>>
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Bilgin Ibryam
In reply to this post by Mircea Markus-2

Hi guys,

some time ago I created camel-infinispan component [1] and when I tried to deploy that on an OSGI container, all the fun began :)

You can see all the steps [2] I had to do in order to deploy Infinispan jars on OSGI. They are far from the optimal but should give you some pointers to things to fix while working on it.

Looking forward seeing on Infinispan on OSGI, right now it is a showstopper for couple of POCs.
Cheers,

--
Bilgin Ibryam

Apache Camel & Apache OFBiz committer
Blog: ofbizian.com
Twitter: @bibryam

Author of Instant Apache Camel Message Routing
http://www.amazon.com/dp/1783283475

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Galder Zamarreno
In reply to this post by Eric Wittmann

On Dec 16, 2013, at 3:00 PM, Eric Wittmann <[hidden email]> 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" <[hidden email]>
>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>> 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" <[hidden email]>
>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>> 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" <[hidden email]>
>> To: "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Brett Meyer" <[hidden email]>
>> 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.html
>>
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>


--
Galder Zamarreño
[hidden email]
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Galder Zamarreno
In reply to this post by Sanne Grinovero-2

On Dec 16, 2013, at 4:08 PM, Sanne Grinovero <[hidden email]> wrote:

> Hi Eric,
> thanks that sounds great, having a solid collection of tests is
> probably the most usefull specification for what we need to achieve.
>
> @Infinispan team: could we add such tests in the Infinispan
> repository? I think that's where they belong.

Apart from the quickstart, I agree that some unit tests would be great too and we'd welcome them ;)

>
> Sanne
>
> On 16 December 2013 14:00, Eric Wittmann <[hidden email]> 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.
>>
>> 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?
>>
>> -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" <[hidden email]>
>>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List"
>>> <[hidden email]>
>>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>>> 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" <[hidden email]>
>>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List"
>>> <[hidden email]>
>>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>>> 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" <[hidden email]>
>>> To: "infinispan -Dev List" <[hidden email]>
>>> Cc: "Pete Muir" <[hidden email]>, "Brett Meyer" <[hidden email]>
>>> 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.html
>>>
>>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
[hidden email]
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Brett Meyer
In reply to this post by Galder Zamarreno
Galder, ConfigurationParser/CL/ServiceLoader/etc. is a part of what I already have cooking in my fork.  When finished, want everything in a combined PR against ISPN-800, or would you rather have something more granular?

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Galder Zamarreño" <[hidden email]>
To: "Eric Wittmann" <[hidden email]>
Cc: "infinispan -Dev List" <[hidden email]>, "Brett Meyer" <[hidden email]>, "Sanne Grinovero" <[hidden email]>, "Pete Muir" <[hidden email]>, "Randall Hauch" <[hidden email]>, "Steve Jacobs" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>> 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" <[hidden email]>
>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>> 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" <[hidden email]>
>> To: "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Brett Meyer" <[hidden email]>
>> 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.html
>>
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>


--
Galder Zamarreño
[hidden email]
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Brett Meyer
After discussing several issues with Galder, I'm breaking everything down into subtasks on ISPN-800.  Feel free to comment!

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Brett Meyer" <[hidden email]>
To: "Galder Zamarreño" <[hidden email]>
Cc: "Eric Wittmann" <[hidden email]>, "infinispan -Dev List" <[hidden email]>, "Sanne Grinovero" <[hidden email]>, "Pete Muir" <[hidden email]>, "Randall Hauch" <[hidden email]>, "Steve Jacobs" <[hidden email]>
Sent: Wednesday, December 18, 2013 9:24:19 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi

Galder, ConfigurationParser/CL/ServiceLoader/etc. is a part of what I already have cooking in my fork.  When finished, want everything in a combined PR against ISPN-800, or would you rather have something more granular?

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Galder Zamarreño" <[hidden email]>
To: "Eric Wittmann" <[hidden email]>
Cc: "infinispan -Dev List" <[hidden email]>, "Brett Meyer" <[hidden email]>, "Sanne Grinovero" <[hidden email]>, "Pete Muir" <[hidden email]>, "Randall Hauch" <[hidden email]>, "Steve Jacobs" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>> 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" <[hidden email]>
>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>> 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" <[hidden email]>
>> To: "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Brett Meyer" <[hidden email]>
>> 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.html
>>
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>


--
Galder Zamarreño
[hidden email]
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Galder Zamarreno
In reply to this post by Bilgin Ibryam
Thanks a lot Bilgin.

One of our colleagues has also been looking into Infinispan's integration into OSGI containers, see [1] dev list thread.

Cheers,

[1] http://lists.jboss.org/pipermail/infinispan-dev/2013-December/014272.html

On Dec 17, 2013, at 11:49 PM, Bilgin Ibryam <[hidden email]> wrote:

>
> Hi guys,
>
> some time ago I created camel-infinispan component [1] and when I tried to deploy that on an OSGI container, all the fun began :)
>
> You can see all the steps [2] I had to do in order to deploy Infinispan jars on OSGI. They are far from the optimal but should give you some pointers to things to fix while working on it.
>
> Looking forward seeing on Infinispan on OSGI, right now it is a showstopper for couple of POCs.
>
>
> [1] http://camel.apache.org/infinispan.html
> [2] https://github.com/bibryam/camel-infinispan-osgi
>
> Cheers,
>
> --
> Bilgin Ibryam
>
> Apache Camel & Apache OFBiz committer
> Blog: ofbizian.com
> Twitter: @bibryam
>
> Author of Instant Apache Camel Message Routing
> http://www.amazon.com/dp/1783283475
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
[hidden email]
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Brett Meyer
In reply to this post by Galder Zamarreno
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)?

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?

Hopefully that all makes sense...

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Galder Zamarreño" <[hidden email]>
To: "Eric Wittmann" <[hidden email]>
Cc: "infinispan -Dev List" <[hidden email]>, "Brett Meyer" <[hidden email]>, "Sanne Grinovero" <[hidden email]>, "Pete Muir" <[hidden email]>, "Randall Hauch" <[hidden email]>, "Steve Jacobs" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>> 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" <[hidden email]>
>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>> 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" <[hidden email]>
>> To: "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Brett Meyer" <[hidden email]>
>> 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.html
>>
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>


--
Galder Zamarreño
[hidden email]
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] help with Infinispan OSGi

Dan Berindei
On Tue, Jan 7, 2014 at 9:14 PM, Brett Meyer <[hidden email]> wrote:
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 https://issues.jboss.org/browse/ISPN-3836 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" <[hidden email]>
To: "Eric Wittmann" <[hidden email]>
Cc: "infinispan -Dev List" <[hidden email]>, "Brett Meyer" <[hidden email]>, "Sanne Grinovero" <[hidden email]>, "Pete Muir" <[hidden email]>, "Randall Hauch" <[hidden email]>, "Steve Jacobs" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>> 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" <[hidden email]>
>> To: "Randall Hauch" <[hidden email]>, "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Steve Jacobs" <[hidden email]>
>> 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" <[hidden email]>
>> To: "infinispan -Dev List" <[hidden email]>
>> Cc: "Pete Muir" <[hidden email]>, "Brett Meyer" <[hidden email]>
>> 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.html
>>
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>


--
Galder Zamarreño
[hidden email]
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev