[DISCUSS] OSGi support for Artemis

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

[DISCUSS] OSGi support for Artemis

Guillaume Nodet-5
I was looking at supporting OSGi deployment for Artemis.

The first big problem I hit is the existence of split packages.  Split
packages are java packages shared across multiple jars (which become
bundles in OSGi).
Examples of those are org.apache.activemq.artemis.uri (shared between
artemis-jms-client and artemis-core-client) or
org.apache.activemq.artemis.api.config (shared between artemis-core-client
and artemis-commons).
The reason they are problematic is that in OSGi, each bundle has its own
class loader, importing classes from other packages based on packages.  The
same package can not be imported from 2 different bundles.

So the question is: would it be possible to get rid of those split packages
? It can be done either by moving the classes from a jar to another one,
keeping the same package name, or by renaming one of the split package so
that there's no duplicate package names across jars.

Thoughts ?
Guillaume Nodet
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

clebertsuconic
https://issues.apache.org/jira/browse/ARTEMIS-93

OSGI still an open task. Fancy contributing? (as the British would say)

The first thing thing I know we will need is an uber JAR. I think we
talked about this during the last Apache Con with some folks.. and I
also remember talking to some other folks.. that the first thing we
will need is an Uber Jar...


ActiveMQ has it being done here:

https://github.com/apache/activemq/tree/master/activemq-osgi


Maybe that's an easy transfer?


And that would take care of your issue of multiple split jars.. (We
need the split jars as the clients don't want to have server
objects... and other things that are best to be kept separate... you
don't need the resource adapter on the client for instance).



On Fri, Nov 13, 2015 at 9:21 AM, Guillaume Nodet <[hidden email]> wrote:

> I was looking at supporting OSGi deployment for Artemis.
>
> The first big problem I hit is the existence of split packages.  Split
> packages are java packages shared across multiple jars (which become
> bundles in OSGi).
> Examples of those are org.apache.activemq.artemis.uri (shared between
> artemis-jms-client and artemis-core-client) or
> org.apache.activemq.artemis.api.config (shared between artemis-core-client
> and artemis-commons).
> The reason they are problematic is that in OSGi, each bundle has its own
> class loader, importing classes from other packages based on packages.  The
> same package can not be imported from 2 different bundles.
>
> So the question is: would it be possible to get rid of those split packages
> ? It can be done either by moving the classes from a jar to another one,
> keeping the same package name, or by renaming one of the split package so
> that there's no duplicate package names across jars.
>
> Thoughts ?
> Guillaume Nodet



--
Clebert Suconic
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

dkulp

I’d much much rather see the split packages resolved than have an uber jar.

Can the packages be moved into a “common” jar or something that can be referenced by both?


Dan



> On Nov 13, 2015, at 10:27 AM, Clebert Suconic <[hidden email]> wrote:
>
> https://issues.apache.org/jira/browse/ARTEMIS-93
>
> OSGI still an open task. Fancy contributing? (as the British would say)
>
> The first thing thing I know we will need is an uber JAR. I think we
> talked about this during the last Apache Con with some folks.. and I
> also remember talking to some other folks.. that the first thing we
> will need is an Uber Jar...
>
>
> ActiveMQ has it being done here:
>
> https://github.com/apache/activemq/tree/master/activemq-osgi
>
>
> Maybe that's an easy transfer?
>
>
> And that would take care of your issue of multiple split jars.. (We
> need the split jars as the clients don't want to have server
> objects... and other things that are best to be kept separate... you
> don't need the resource adapter on the client for instance).
>
>
>
> On Fri, Nov 13, 2015 at 9:21 AM, Guillaume Nodet <[hidden email]> wrote:
>> I was looking at supporting OSGi deployment for Artemis.
>>
>> The first big problem I hit is the existence of split packages.  Split
>> packages are java packages shared across multiple jars (which become
>> bundles in OSGi).
>> Examples of those are org.apache.activemq.artemis.uri (shared between
>> artemis-jms-client and artemis-core-client) or
>> org.apache.activemq.artemis.api.config (shared between artemis-core-client
>> and artemis-commons).
>> The reason they are problematic is that in OSGi, each bundle has its own
>> class loader, importing classes from other packages based on packages.  The
>> same package can not be imported from 2 different bundles.
>>
>> So the question is: would it be possible to get rid of those split packages
>> ? It can be done either by moving the classes from a jar to another one,
>> keeping the same package name, or by renaming one of the split package so
>> that there's no duplicate package names across jars.
>>
>> Thoughts ?
>> Guillaume Nodet
>
>
>
> --
> Clebert Suconic

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

clebertsuconic
ahhh... same package on different JARs... ok.. I missed that.

Yeah.. that needs to be fixed.

On Fri, Nov 13, 2015 at 10:29 AM, Daniel Kulp <[hidden email]> wrote:

>
> I’d much much rather see the split packages resolved than have an uber jar.
>
> Can the packages be moved into a “common” jar or something that can be referenced by both?
>
>
> Dan
>
>
>
>> On Nov 13, 2015, at 10:27 AM, Clebert Suconic <[hidden email]> wrote:
>>
>> https://issues.apache.org/jira/browse/ARTEMIS-93
>>
>> OSGI still an open task. Fancy contributing? (as the British would say)
>>
>> The first thing thing I know we will need is an uber JAR. I think we
>> talked about this during the last Apache Con with some folks.. and I
>> also remember talking to some other folks.. that the first thing we
>> will need is an Uber Jar...
>>
>>
>> ActiveMQ has it being done here:
>>
>> https://github.com/apache/activemq/tree/master/activemq-osgi
>>
>>
>> Maybe that's an easy transfer?
>>
>>
>> And that would take care of your issue of multiple split jars.. (We
>> need the split jars as the clients don't want to have server
>> objects... and other things that are best to be kept separate... you
>> don't need the resource adapter on the client for instance).
>>
>>
>>
>> On Fri, Nov 13, 2015 at 9:21 AM, Guillaume Nodet <[hidden email]> wrote:
>>> I was looking at supporting OSGi deployment for Artemis.
>>>
>>> The first big problem I hit is the existence of split packages.  Split
>>> packages are java packages shared across multiple jars (which become
>>> bundles in OSGi).
>>> Examples of those are org.apache.activemq.artemis.uri (shared between
>>> artemis-jms-client and artemis-core-client) or
>>> org.apache.activemq.artemis.api.config (shared between artemis-core-client
>>> and artemis-commons).
>>> The reason they are problematic is that in OSGi, each bundle has its own
>>> class loader, importing classes from other packages based on packages.  The
>>> same package can not be imported from 2 different bundles.
>>>
>>> So the question is: would it be possible to get rid of those split packages
>>> ? It can be done either by moving the classes from a jar to another one,
>>> keeping the same package name, or by renaming one of the split package so
>>> that there's no duplicate package names across jars.
>>>
>>> Thoughts ?
>>> Guillaume Nodet
>>
>>
>>
>> --
>> Clebert Suconic
>
> --
> Daniel Kulp
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>



--
Clebert Suconic
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

andytaylor
If someone identifies what packages clash I'd be happy to move them. The
only concern I have is changing Api's but maybe we could have an Api jar if
that's an issue.

On Fri, 13 Nov 2015 15:33 Clebert Suconic <[hidden email]> wrote:

> ahhh... same package on different JARs... ok.. I missed that.
>
> Yeah.. that needs to be fixed.
>
> On Fri, Nov 13, 2015 at 10:29 AM, Daniel Kulp <[hidden email]> wrote:
> >
> > I’d much much rather see the split packages resolved than have an uber
> jar.
> >
> > Can the packages be moved into a “common” jar or something that can be
> referenced by both?
> >
> >
> > Dan
> >
> >
> >
> >> On Nov 13, 2015, at 10:27 AM, Clebert Suconic <
> [hidden email]> wrote:
> >>
> >> https://issues.apache.org/jira/browse/ARTEMIS-93
> >>
> >> OSGI still an open task. Fancy contributing? (as the British would say)
> >>
> >> The first thing thing I know we will need is an uber JAR. I think we
> >> talked about this during the last Apache Con with some folks.. and I
> >> also remember talking to some other folks.. that the first thing we
> >> will need is an Uber Jar...
> >>
> >>
> >> ActiveMQ has it being done here:
> >>
> >> https://github.com/apache/activemq/tree/master/activemq-osgi
> >>
> >>
> >> Maybe that's an easy transfer?
> >>
> >>
> >> And that would take care of your issue of multiple split jars.. (We
> >> need the split jars as the clients don't want to have server
> >> objects... and other things that are best to be kept separate... you
> >> don't need the resource adapter on the client for instance).
> >>
> >>
> >>
> >> On Fri, Nov 13, 2015 at 9:21 AM, Guillaume Nodet <[hidden email]>
> wrote:
> >>> I was looking at supporting OSGi deployment for Artemis.
> >>>
> >>> The first big problem I hit is the existence of split packages.  Split
> >>> packages are java packages shared across multiple jars (which become
> >>> bundles in OSGi).
> >>> Examples of those are org.apache.activemq.artemis.uri (shared between
> >>> artemis-jms-client and artemis-core-client) or
> >>> org.apache.activemq.artemis.api.config (shared between
> artemis-core-client
> >>> and artemis-commons).
> >>> The reason they are problematic is that in OSGi, each bundle has its
> own
> >>> class loader, importing classes from other packages based on
> packages.  The
> >>> same package can not be imported from 2 different bundles.
> >>>
> >>> So the question is: would it be possible to get rid of those split
> packages
> >>> ? It can be done either by moving the classes from a jar to another
> one,
> >>> keeping the same package name, or by renaming one of the split package
> so
> >>> that there's no duplicate package names across jars.
> >>>
> >>> Thoughts ?
> >>> Guillaume Nodet
> >>
> >>
> >>
> >> --
> >> Clebert Suconic
> >
> > --
> > Daniel Kulp
> > [hidden email] - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>
>
>
> --
> Clebert Suconic
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

Raul Kripalani-3
In reply to this post by Guillaume Nodet-5
If there are just a few modules affected, and the reason for split packages
is due to some fancy class discovery, or modularity, or something like, it
may justify using OSGi fragments.

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

On Fri, Nov 13, 2015 at 2:21 PM, Guillaume Nodet <[hidden email]> wrote:

> I was looking at supporting OSGi deployment for Artemis.
>
> The first big problem I hit is the existence of split packages.  Split
> packages are java packages shared across multiple jars (which become
> bundles in OSGi).
> Examples of those are org.apache.activemq.artemis.uri (shared between
> artemis-jms-client and artemis-core-client) or
> org.apache.activemq.artemis.api.config (shared between artemis-core-client
> and artemis-commons).
> The reason they are problematic is that in OSGi, each bundle has its own
> class loader, importing classes from other packages based on packages.  The
> same package can not be imported from 2 different bundles.
>
> So the question is: would it be possible to get rid of those split packages
> ? It can be done either by moving the classes from a jar to another one,
> keeping the same package name, or by renaming one of the split package so
> that there's no duplicate package names across jars.
>
> Thoughts ?
> Guillaume Nodet
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

Guillaume Nodet-5
In reply to this post by clebertsuconic
An uber-jar is obviously a simpler solution, but it's really not the best
one.  I'd rather spend time on a clean solution.
After the split package problem, the next steps would be enhance the
service discovery mechanism to ensure it can work in OSGi, provide a
ConfigAdmin support, a karaf feature, etc...
I'm willing to contribute to solve that and I'll propose some PR, I just
need some indication on how you want to proceed, especially with the split
packages.

The ActiveMQDefaultConfiguration is used by both client and servers, so I
suppose artemis-commons would be a good place for it.  We just need a
specific package for it.  What about
org.apache.activemq.artemis.api.config.common ?

The jms related classes in org.apache.activemq.artemis.uri could be moved
to org.apache.activemq.artemis.uri.jms.

Thoughts ?

Guillaume



2015-11-13 16:33 GMT+01:00 Clebert Suconic <[hidden email]>:

> ahhh... same package on different JARs... ok.. I missed that.
>
> Yeah.. that needs to be fixed.
>
> On Fri, Nov 13, 2015 at 10:29 AM, Daniel Kulp <[hidden email]> wrote:
> >
> > I’d much much rather see the split packages resolved than have an uber
> jar.
> >
> > Can the packages be moved into a “common” jar or something that can be
> referenced by both?
> >
> >
> > Dan
> >
> >
> >
> >> On Nov 13, 2015, at 10:27 AM, Clebert Suconic <
> [hidden email]> wrote:
> >>
> >> https://issues.apache.org/jira/browse/ARTEMIS-93
> >>
> >> OSGI still an open task. Fancy contributing? (as the British would say)
> >>
> >> The first thing thing I know we will need is an uber JAR. I think we
> >> talked about this during the last Apache Con with some folks.. and I
> >> also remember talking to some other folks.. that the first thing we
> >> will need is an Uber Jar...
> >>
> >>
> >> ActiveMQ has it being done here:
> >>
> >> https://github.com/apache/activemq/tree/master/activemq-osgi
> >>
> >>
> >> Maybe that's an easy transfer?
> >>
> >>
> >> And that would take care of your issue of multiple split jars.. (We
> >> need the split jars as the clients don't want to have server
> >> objects... and other things that are best to be kept separate... you
> >> don't need the resource adapter on the client for instance).
> >>
> >>
> >>
> >> On Fri, Nov 13, 2015 at 9:21 AM, Guillaume Nodet <[hidden email]>
> wrote:
> >>> I was looking at supporting OSGi deployment for Artemis.
> >>>
> >>> The first big problem I hit is the existence of split packages.  Split
> >>> packages are java packages shared across multiple jars (which become
> >>> bundles in OSGi).
> >>> Examples of those are org.apache.activemq.artemis.uri (shared between
> >>> artemis-jms-client and artemis-core-client) or
> >>> org.apache.activemq.artemis.api.config (shared between
> artemis-core-client
> >>> and artemis-commons).
> >>> The reason they are problematic is that in OSGi, each bundle has its
> own
> >>> class loader, importing classes from other packages based on
> packages.  The
> >>> same package can not be imported from 2 different bundles.
> >>>
> >>> So the question is: would it be possible to get rid of those split
> packages
> >>> ? It can be done either by moving the classes from a jar to another
> one,
> >>> keeping the same package name, or by renaming one of the split package
> so
> >>> that there's no duplicate package names across jars.
> >>>
> >>> Thoughts ?
> >>> Guillaume Nodet
> >>
> >>
> >>
> >> --
> >> Clebert Suconic
> >
> > --
> > Daniel Kulp
> > [hidden email] - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>
>
>
> --
> Clebert Suconic
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

clebertsuconic
ActiveMQDefaultConfiguration is part of the APi. That would break
people's integrations. I would like to avoid moving it.


We could move stuff without changing package names easily into artemis-commons.


We could create a new one there and deprecate the old one.. or play
with extensions... I would prefer to keep the API unchanged.

On Fri, Nov 13, 2015 at 2:19 PM, Guillaume Nodet <[hidden email]> wrote:

> An uber-jar is obviously a simpler solution, but it's really not the best
> one.  I'd rather spend time on a clean solution.
> After the split package problem, the next steps would be enhance the
> service discovery mechanism to ensure it can work in OSGi, provide a
> ConfigAdmin support, a karaf feature, etc...
> I'm willing to contribute to solve that and I'll propose some PR, I just
> need some indication on how you want to proceed, especially with the split
> packages.
>
> The ActiveMQDefaultConfiguration is used by both client and servers, so I
> suppose artemis-commons would be a good place for it.  We just need a
> specific package for it.  What about
> org.apache.activemq.artemis.api.config.common ?
>
> The jms related classes in org.apache.activemq.artemis.uri could be moved
> to org.apache.activemq.artemis.uri.jms.
>
> Thoughts ?
>
> Guillaume
>
>
>
> 2015-11-13 16:33 GMT+01:00 Clebert Suconic <[hidden email]>:
>
>> ahhh... same package on different JARs... ok.. I missed that.
>>
>> Yeah.. that needs to be fixed.
>>
>> On Fri, Nov 13, 2015 at 10:29 AM, Daniel Kulp <[hidden email]> wrote:
>> >
>> > I’d much much rather see the split packages resolved than have an uber
>> jar.
>> >
>> > Can the packages be moved into a “common” jar or something that can be
>> referenced by both?
>> >
>> >
>> > Dan
>> >
>> >
>> >
>> >> On Nov 13, 2015, at 10:27 AM, Clebert Suconic <
>> [hidden email]> wrote:
>> >>
>> >> https://issues.apache.org/jira/browse/ARTEMIS-93
>> >>
>> >> OSGI still an open task. Fancy contributing? (as the British would say)
>> >>
>> >> The first thing thing I know we will need is an uber JAR. I think we
>> >> talked about this during the last Apache Con with some folks.. and I
>> >> also remember talking to some other folks.. that the first thing we
>> >> will need is an Uber Jar...
>> >>
>> >>
>> >> ActiveMQ has it being done here:
>> >>
>> >> https://github.com/apache/activemq/tree/master/activemq-osgi
>> >>
>> >>
>> >> Maybe that's an easy transfer?
>> >>
>> >>
>> >> And that would take care of your issue of multiple split jars.. (We
>> >> need the split jars as the clients don't want to have server
>> >> objects... and other things that are best to be kept separate... you
>> >> don't need the resource adapter on the client for instance).
>> >>
>> >>
>> >>
>> >> On Fri, Nov 13, 2015 at 9:21 AM, Guillaume Nodet <[hidden email]>
>> wrote:
>> >>> I was looking at supporting OSGi deployment for Artemis.
>> >>>
>> >>> The first big problem I hit is the existence of split packages.  Split
>> >>> packages are java packages shared across multiple jars (which become
>> >>> bundles in OSGi).
>> >>> Examples of those are org.apache.activemq.artemis.uri (shared between
>> >>> artemis-jms-client and artemis-core-client) or
>> >>> org.apache.activemq.artemis.api.config (shared between
>> artemis-core-client
>> >>> and artemis-commons).
>> >>> The reason they are problematic is that in OSGi, each bundle has its
>> own
>> >>> class loader, importing classes from other packages based on
>> packages.  The
>> >>> same package can not be imported from 2 different bundles.
>> >>>
>> >>> So the question is: would it be possible to get rid of those split
>> packages
>> >>> ? It can be done either by moving the classes from a jar to another
>> one,
>> >>> keeping the same package name, or by renaming one of the split package
>> so
>> >>> that there's no duplicate package names across jars.
>> >>>
>> >>> Thoughts ?
>> >>> Guillaume Nodet
>> >>
>> >>
>> >>
>> >> --
>> >> Clebert Suconic
>> >
>> > --
>> > Daniel Kulp
>> > [hidden email] - http://dankulp.com/blog
>> > Talend Community Coder - http://coders.talend.com
>> >
>>
>>
>>
>> --
>> Clebert Suconic
>>



--
Clebert Suconic
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

chirino
In reply to this post by Guillaume Nodet-5
Doing proper osgi modularization involves way more than moving packages to
resolve split package issues. It requires dynamic dependency injection
support which I doubt the current Artemis project supports. If the goal is
to to just add osgi support, The uber jar approach is the simplest most
correct way to do it without requiring a major re-architecture of th
current Artemis di systems.

On Friday, November 13, 2015, Guillaume Nodet <[hidden email]> wrote:

> An uber-jar is obviously a simpler solution, but it's really not the best
> one.  I'd rather spend time on a clean solution.
> After the split package problem, the next steps would be enhance the
> service discovery mechanism to ensure it can work in OSGi, provide a
> ConfigAdmin support, a karaf feature, etc...
> I'm willing to contribute to solve that and I'll propose some PR, I just
> need some indication on how you want to proceed, especially with the split
> packages.
>
> The ActiveMQDefaultConfiguration is used by both client and servers, so I
> suppose artemis-commons would be a good place for it.  We just need a
> specific package for it.  What about
> org.apache.activemq.artemis.api.config.common ?
>
> The jms related classes in org.apache.activemq.artemis.uri could be moved
> to org.apache.activemq.artemis.uri.jms.
>
> Thoughts ?
>
> Guillaume
>
>
>
> 2015-11-13 16:33 GMT+01:00 Clebert Suconic <[hidden email]
> <javascript:;>>:
>
> > ahhh... same package on different JARs... ok.. I missed that.
> >
> > Yeah.. that needs to be fixed.
> >
> > On Fri, Nov 13, 2015 at 10:29 AM, Daniel Kulp <[hidden email]
> <javascript:;>> wrote:
> > >
> > > I’d much much rather see the split packages resolved than have an uber
> > jar.
> > >
> > > Can the packages be moved into a “common” jar or something that can be
> > referenced by both?
> > >
> > >
> > > Dan
> > >
> > >
> > >
> > >> On Nov 13, 2015, at 10:27 AM, Clebert Suconic <
> > [hidden email] <javascript:;>> wrote:
> > >>
> > >> https://issues.apache.org/jira/browse/ARTEMIS-93
> > >>
> > >> OSGI still an open task. Fancy contributing? (as the British would
> say)
> > >>
> > >> The first thing thing I know we will need is an uber JAR. I think we
> > >> talked about this during the last Apache Con with some folks.. and I
> > >> also remember talking to some other folks.. that the first thing we
> > >> will need is an Uber Jar...
> > >>
> > >>
> > >> ActiveMQ has it being done here:
> > >>
> > >> https://github.com/apache/activemq/tree/master/activemq-osgi
> > >>
> > >>
> > >> Maybe that's an easy transfer?
> > >>
> > >>
> > >> And that would take care of your issue of multiple split jars.. (We
> > >> need the split jars as the clients don't want to have server
> > >> objects... and other things that are best to be kept separate... you
> > >> don't need the resource adapter on the client for instance).
> > >>
> > >>
> > >>
> > >> On Fri, Nov 13, 2015 at 9:21 AM, Guillaume Nodet <[hidden email]
> <javascript:;>>
> > wrote:
> > >>> I was looking at supporting OSGi deployment for Artemis.
> > >>>
> > >>> The first big problem I hit is the existence of split packages.
> Split
> > >>> packages are java packages shared across multiple jars (which become
> > >>> bundles in OSGi).
> > >>> Examples of those are org.apache.activemq.artemis.uri (shared between
> > >>> artemis-jms-client and artemis-core-client) or
> > >>> org.apache.activemq.artemis.api.config (shared between
> > artemis-core-client
> > >>> and artemis-commons).
> > >>> The reason they are problematic is that in OSGi, each bundle has its
> > own
> > >>> class loader, importing classes from other packages based on
> > packages.  The
> > >>> same package can not be imported from 2 different bundles.
> > >>>
> > >>> So the question is: would it be possible to get rid of those split
> > packages
> > >>> ? It can be done either by moving the classes from a jar to another
> > one,
> > >>> keeping the same package name, or by renaming one of the split
> package
> > so
> > >>> that there's no duplicate package names across jars.
> > >>>
> > >>> Thoughts ?
> > >>> Guillaume Nodet
> > >>
> > >>
> > >>
> > >> --
> > >> Clebert Suconic
> > >
> > > --
> > > Daniel Kulp
> > > [hidden email] <javascript:;> - http://dankulp.com/blog
> > > Talend Community Coder - http://coders.talend.com
> > >
> >
> >
> >
> > --
> > Clebert Suconic
> >
>


--
Hiram Chirino
Engineering | Red Hat, Inc.
[hidden email] | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

artnaseef
How much work are we talking to get Artemis properly OSGi-ready?  An uber-jar is a work-around.  If nothing better can be accomplished, then we may have to live with it in the near-term, but it is important to understand what challenges are driving us toward a work-around.

Also, we have an individual showing interest to make this happen, so let's encourage that effort!  Thank you Guillaume.

I may be a bit tainted as these days I'm spending large amounts of time refactoring code and eliminating the impacts of work-arounds and shortcuts.
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

Raul Kripalani-2
Once again, I do suggest you explore the OSGi Fragment route.

I haven't digged into the Artemis source, but if your modularity scheme
consists of modules that provide classes and resources to a central one, it
could fit well.

This is the strategy I'm using with certain modules to OSGify Apache
Ignite.

It also resolves the split package situation quite elegantly without being
a workaround (depending on the rationale of the split packages to begin
with).
On 16 Nov 2015 03:15, "artnaseef" <[hidden email]> wrote:

> How much work are we talking to get Artemis properly OSGi-ready?  An
> uber-jar
> is a work-around.  If nothing better can be accomplished, then we may have
> to live with it in the near-term, but it is important to understand what
> challenges are driving us toward a work-around.
>
> Also, we have an individual showing interest to make this happen, so let's
> encourage that effort!  Thank you Guillaume.
>
> I may be a bit tainted as these days I'm spending large amounts of time
> refactoring code and eliminating the impacts of work-arounds and shortcuts.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/DISCUSS-OSGi-support-for-Artemis-tp4703943p4703972.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

cschneider
In reply to this post by Guillaume Nodet-5
I agree we should try to get rid of the split packages. They are even a
problem in plain java as you could easily create the same class
in both without noticing at fist.

A big ueber jat could be a kind of stop gap solution but I think it
makes sense to try to avoid it if the effort is not too big.

I do not like the fragment approach too much. I personally only consider
fragments if I need to make some existing jar work and can not change
it. It might be a last resort if the split packages can not be resolved
in any other way.

Do you have a good way to find all the split packages? I think the first
thing we should do is get a complete list of all split packages. Then we
can decide what to do.
If there is no automated way I can make a list.

The next step would be to add the maven bundle plugin with defaults and
see what results it produces.

After that we need to see if we can make the plugin mechanism work for
OSGi. It seems that for example the protocols use the ServiceLoader to
announce their impls. That might be covered by Aries spi-fly though
I do not have any experience with it.

In any case I am willing to help with the OSGi effort.

Christian


On 13.11.2015 15:21, Guillaume Nodet wrote:

> I was looking at supporting OSGi deployment for Artemis.
>
> The first big problem I hit is the existence of split packages.  Split
> packages are java packages shared across multiple jars (which become
> bundles in OSGi).
> Examples of those are org.apache.activemq.artemis.uri (shared between
> artemis-jms-client and artemis-core-client) or
> org.apache.activemq.artemis.api.config (shared between artemis-core-client
> and artemis-commons).
> The reason they are problematic is that in OSGi, each bundle has its own
> class loader, importing classes from other packages based on packages.  The
> same package can not be imported from 2 different bundles.
>
> So the question is: would it be possible to get rid of those split packages
> ? It can be done either by moving the classes from a jar to another one,
> keeping the same package name, or by renaming one of the split package so
> that there's no duplicate package names across jars.
>
> Thoughts ?
> Guillaume Nodet
>


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

clebertsuconic
I think moving the packages should be an easy thing... does anyone
know an automated way to find this on any IDE or Maven thing? so far I
only know how to do manual inspection. I failed to find such thing on
google (hence the question here).

On Mon, Nov 16, 2015 at 8:42 AM, Christian Schneider
<[hidden email]> wrote:

> I agree we should try to get rid of the split packages. They are even a
> problem in plain java as you could easily create the same class
> in both without noticing at fist.
>
> A big ueber jat could be a kind of stop gap solution but I think it makes
> sense to try to avoid it if the effort is not too big.
>
> I do not like the fragment approach too much. I personally only consider
> fragments if I need to make some existing jar work and can not change it. It
> might be a last resort if the split packages can not be resolved in any
> other way.
>
> Do you have a good way to find all the split packages? I think the first
> thing we should do is get a complete list of all split packages. Then we can
> decide what to do.
> If there is no automated way I can make a list.
>
> The next step would be to add the maven bundle plugin with defaults and see
> what results it produces.
>
> After that we need to see if we can make the plugin mechanism work for OSGi.
> It seems that for example the protocols use the ServiceLoader to announce
> their impls. That might be covered by Aries spi-fly though
> I do not have any experience with it.
>
> In any case I am willing to help with the OSGi effort.
>
> Christian
>
>
>
> On 13.11.2015 15:21, Guillaume Nodet wrote:
>>
>> I was looking at supporting OSGi deployment for Artemis.
>>
>> The first big problem I hit is the existence of split packages.  Split
>> packages are java packages shared across multiple jars (which become
>> bundles in OSGi).
>> Examples of those are org.apache.activemq.artemis.uri (shared between
>> artemis-jms-client and artemis-core-client) or
>> org.apache.activemq.artemis.api.config (shared between artemis-core-client
>> and artemis-commons).
>> The reason they are problematic is that in OSGi, each bundle has its own
>> class loader, importing classes from other packages based on packages.
>> The
>> same package can not be imported from 2 different bundles.
>>
>> So the question is: would it be possible to get rid of those split
>> packages
>> ? It can be done either by moving the classes from a jar to another one,
>> keeping the same package name, or by renaming one of the split package so
>> that there's no duplicate package names across jars.
>>
>> Thoughts ?
>> Guillaume Nodet
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>



--
Clebert Suconic
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

Guillaume Nodet-5
In reply to this post by Raul Kripalani-2
I really don't see the point of using fragments.  Fragments are not a good
OSGi solution in general.
The easiest way forward (even instead of using fragments) would be to use
an uber-jar imho.
At least, it has the benefit of limiting the code changes and locating all
the OSGi stuff in a single module.

2015-11-16 11:48 GMT+01:00 Raul Kripalani <[hidden email]>:

> Once again, I do suggest you explore the OSGi Fragment route.
>
> I haven't digged into the Artemis source, but if your modularity scheme
> consists of modules that provide classes and resources to a central one, it
> could fit well.
>
> This is the strategy I'm using with certain modules to OSGify Apache
> Ignite.
>
> It also resolves the split package situation quite elegantly without being
> a workaround (depending on the rationale of the split packages to begin
> with).
> On 16 Nov 2015 03:15, "artnaseef" <[hidden email]> wrote:
>
> > How much work are we talking to get Artemis properly OSGi-ready?  An
> > uber-jar
> > is a work-around.  If nothing better can be accomplished, then we may
> have
> > to live with it in the near-term, but it is important to understand what
> > challenges are driving us toward a work-around.
> >
> > Also, we have an individual showing interest to make this happen, so
> let's
> > encourage that effort!  Thank you Guillaume.
> >
> > I may be a bit tainted as these days I'm spending large amounts of time
> > refactoring code and eliminating the impacts of work-arounds and
> shortcuts.
> >
> >
> >
> > --
> > View this message in context:
> >
> http://activemq.2283324.n4.nabble.com/DISCUSS-OSGi-support-for-Artemis-tp4703943p4703972.html
> > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

Guillaume Nodet-5
In reply to this post by clebertsuconic
The list I gave is partially automated.
I've generated it while working on an uber-jar osgi bundle (the
maven-bundle-plugin can indicate packages that are split).
Such a bundle is the easiest / fastest way forward as it limits the code
changes.
It's definitely not the best solution, but could be considered a temporary
one while waiting for the required refactoring to be done.
As Dan explained, going to real osgi bundles may require more work around
class loading, service discovery, etc...


2015-11-16 16:10 GMT+01:00 Clebert Suconic <[hidden email]>:

> I think moving the packages should be an easy thing... does anyone
> know an automated way to find this on any IDE or Maven thing? so far I
> only know how to do manual inspection. I failed to find such thing on
> google (hence the question here).
>
> On Mon, Nov 16, 2015 at 8:42 AM, Christian Schneider
> <[hidden email]> wrote:
> > I agree we should try to get rid of the split packages. They are even a
> > problem in plain java as you could easily create the same class
> > in both without noticing at fist.
> >
> > A big ueber jat could be a kind of stop gap solution but I think it makes
> > sense to try to avoid it if the effort is not too big.
> >
> > I do not like the fragment approach too much. I personally only consider
> > fragments if I need to make some existing jar work and can not change
> it. It
> > might be a last resort if the split packages can not be resolved in any
> > other way.
> >
> > Do you have a good way to find all the split packages? I think the first
> > thing we should do is get a complete list of all split packages. Then we
> can
> > decide what to do.
> > If there is no automated way I can make a list.
> >
> > The next step would be to add the maven bundle plugin with defaults and
> see
> > what results it produces.
> >
> > After that we need to see if we can make the plugin mechanism work for
> OSGi.
> > It seems that for example the protocols use the ServiceLoader to announce
> > their impls. That might be covered by Aries spi-fly though
> > I do not have any experience with it.
> >
> > In any case I am willing to help with the OSGi effort.
> >
> > Christian
> >
> >
> >
> > On 13.11.2015 15:21, Guillaume Nodet wrote:
> >>
> >> I was looking at supporting OSGi deployment for Artemis.
> >>
> >> The first big problem I hit is the existence of split packages.  Split
> >> packages are java packages shared across multiple jars (which become
> >> bundles in OSGi).
> >> Examples of those are org.apache.activemq.artemis.uri (shared between
> >> artemis-jms-client and artemis-core-client) or
> >> org.apache.activemq.artemis.api.config (shared between
> artemis-core-client
> >> and artemis-commons).
> >> The reason they are problematic is that in OSGi, each bundle has its own
> >> class loader, importing classes from other packages based on packages.
> >> The
> >> same package can not be imported from 2 different bundles.
> >>
> >> So the question is: would it be possible to get rid of those split
> >> packages
> >> ? It can be done either by moving the classes from a jar to another one,
> >> keeping the same package name, or by renaming one of the split package
> so
> >> that there's no duplicate package names across jars.
> >>
> >> Thoughts ?
> >> Guillaume Nodet
> >>
> >
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
>
>
>
> --
> Clebert Suconic
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

Raul Kripalani-2
In reply to this post by Guillaume Nodet-5
Hi Guillaume,

Out of curiosity, why do you think OSGi fragments are not a good solution
in general?

As for everything, they have their use case, right? Or is there a reason to
avoid them altogether, beyond one's liking or disliking of the technique?

Thanks,
Raúl.
On 16 Nov 2015 15:18, "Guillaume Nodet" <[hidden email]> wrote:

> I really don't see the point of using fragments.  Fragments are not a good
> OSGi solution in general.
> The easiest way forward (even instead of using fragments) would be to use
> an uber-jar imho.
> At least, it has the benefit of limiting the code changes and locating all
> the OSGi stuff in a single module.
>
> 2015-11-16 11:48 GMT+01:00 Raul Kripalani <[hidden email]>:
>
> > Once again, I do suggest you explore the OSGi Fragment route.
> >
> > I haven't digged into the Artemis source, but if your modularity scheme
> > consists of modules that provide classes and resources to a central one,
> it
> > could fit well.
> >
> > This is the strategy I'm using with certain modules to OSGify Apache
> > Ignite.
> >
> > It also resolves the split package situation quite elegantly without
> being
> > a workaround (depending on the rationale of the split packages to begin
> > with).
> > On 16 Nov 2015 03:15, "artnaseef" <[hidden email]> wrote:
> >
> > > How much work are we talking to get Artemis properly OSGi-ready?  An
> > > uber-jar
> > > is a work-around.  If nothing better can be accomplished, then we may
> > have
> > > to live with it in the near-term, but it is important to understand
> what
> > > challenges are driving us toward a work-around.
> > >
> > > Also, we have an individual showing interest to make this happen, so
> > let's
> > > encourage that effort!  Thank you Guillaume.
> > >
> > > I may be a bit tainted as these days I'm spending large amounts of time
> > > refactoring code and eliminating the impacts of work-arounds and
> > shortcuts.
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://activemq.2283324.n4.nabble.com/DISCUSS-OSGi-support-for-Artemis-tp4703943p4703972.html
> > > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

artnaseef
In reply to this post by clebertsuconic
A simple shell script would work well if we have access to all the directories.

Something like this:

find . -name '*.java' -print | grep 'src/main/java' | sed 's,\(.*\)/src/main/java/\(.*\),\2 \1,' | sort -u

Or, this is even better:

find . -name '*.java' -print | grep 'src/main/java' | sed 's,\(.*\)/src/main/java/\(.*\)/[^/]*.java,\2  \1,' | sort -u
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

artnaseef
Here's a script that will nicely list all of the packages with more than one source root followed by the list of roots:

find . -name '*.java' -print | \
	grep 'src/main/java' | \
	sed 's,\(.*\)/src/main/java/\(.*\)/[^/]*.java,\2  \1,' | \
	sort -u | \
	awk '\
		{
			count[$1]++; ROOTS[$1] = ROOTS[$1] " " $2;
		}

		END \
		{
			for ( pkg in count )
			{
				if ( count[pkg] > 1 )
				{
					print pkg "\t" ROOTS[pkg];
				}
			}
		}'

Note that for the AMQ source code, it comes up with many things, including (this is partial output):

org/apache/activemq/broker/region/policy	 ./activemq-broker ./activemq-client
org/apache/activemq/pool	 ./activemq-pool ./activemq-spring
org/apache/activemq/maven	 ./activemq-tooling/activemq-maven-plugin ./activemq-tooling/activemq-memtest-maven-plugin ./activemq-tooling/activemq-perf-maven-plugin
org/apache/activemq/broker	 ./activemq-broker ./activemq-client
org/apache/activemq/transport	 ./activemq-broker ./activemq-client ./activemq-http
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

Guillaume Nodet-5
In reply to this post by Raul Kripalani-2
2015-11-17 1:52 GMT+01:00 Raul Kripalani <[hidden email]>:

> Hi Guillaume,
>
> Out of curiosity, why do you think OSGi fragments are not a good solution
> in general?
>

The original primary use case for fragments is to extend a given bundle.
Using it as a workaround for proper modularisation is too much imho.
A cleaner way to extend a given bundle's functionality is to use OSGi
services which allow for more dynamism in OSGi.
Installing a fragment will cause bundles to be refreshed


>
> As for everything, they have their use case, right? Or is there a reason to
> avoid them altogether, beyond one's liking or disliking of the technique?
>

There are valid use cases for using fragments, but again, I don't think
using those as a workaround for proper modularisation is one of them (even
though it works and certainly has been used this way, especially when you
don't have real control over the code you want to deploy in OSGi).

In the Artemis use case, the best way is definitely to refactor the code as
needed so that it becomes a nice OSGi citizen.  As a short term solution
(especially if there are some incompatibilities that need to be pushed to a
major version for example), the simplest way imho is to use an
uber-bundle.  The benefits is that all the OSGi stuff is concentrated into
a single maven module, and the amount of work is much less.  The only small
disadvantage compared to fragments would be that a bunch of import package
need to be optional, whereas with fragments, those could be mandatory for a
given fragment.  But at the end, both are similar as you can't really force
an unresolvable fragment to cause a failure, so that in both case, if
something is missing, there will be a runtime exception such as
ClassNotFoundException.


>
> Thanks,
> Raúl.
> On 16 Nov 2015 15:18, "Guillaume Nodet" <[hidden email]> wrote:
>
> > I really don't see the point of using fragments.  Fragments are not a
> good
> > OSGi solution in general.
> > The easiest way forward (even instead of using fragments) would be to use
> > an uber-jar imho.
> > At least, it has the benefit of limiting the code changes and locating
> all
> > the OSGi stuff in a single module.
> >
> > 2015-11-16 11:48 GMT+01:00 Raul Kripalani <[hidden email]>:
> >
> > > Once again, I do suggest you explore the OSGi Fragment route.
> > >
> > > I haven't digged into the Artemis source, but if your modularity scheme
> > > consists of modules that provide classes and resources to a central
> one,
> > it
> > > could fit well.
> > >
> > > This is the strategy I'm using with certain modules to OSGify Apache
> > > Ignite.
> > >
> > > It also resolves the split package situation quite elegantly without
> > being
> > > a workaround (depending on the rationale of the split packages to begin
> > > with).
> > > On 16 Nov 2015 03:15, "artnaseef" <[hidden email]> wrote:
> > >
> > > > How much work are we talking to get Artemis properly OSGi-ready?  An
> > > > uber-jar
> > > > is a work-around.  If nothing better can be accomplished, then we may
> > > have
> > > > to live with it in the near-term, but it is important to understand
> > what
> > > > challenges are driving us toward a work-around.
> > > >
> > > > Also, we have an individual showing interest to make this happen, so
> > > let's
> > > > encourage that effort!  Thank you Guillaume.
> > > >
> > > > I may be a bit tainted as these days I'm spending large amounts of
> time
> > > > refactoring code and eliminating the impacts of work-arounds and
> > > shortcuts.
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > >
> > >
> >
> http://activemq.2283324.n4.nabble.com/DISCUSS-OSGi-support-for-Artemis-tp4703943p4703972.html
> > > > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] OSGi support for Artemis

Raul Kripalani-3
Thanks for your input Guillaume. I had understood that you didn't generally
consider OSGi fragments fit for any purpose.

If the goal is to make Artemis a nice OSGi citizen, I agree with you that
proper modularisation with whiteboard pattern and OSGi services should be
the correct path.

If the goal was to make Artemis simply "work" in OSGi, I don't think an
uber jar is the optimal solution. Why? Even though I haven't dug into the
source, I'm pretty sure that not *all* modules present a split-package
situation. Therefore, building an uber-jar is killing flies with a bazooka
in my opinion, since you'll be forcing the user to drag in ALL optional
third party dependencies, whether they'll be using them or not.

That's why I think fragments are the right approach. You'd apply a
mix'n'match policy, where modules that present a split-package situation
would become fragments, whereas the rest would become normal bundles.

I appreciate this discussion with you, master!

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

On Tue, Nov 17, 2015 at 9:09 AM, Guillaume Nodet <[hidden email]> wrote:

> 2015-11-17 1:52 GMT+01:00 Raul Kripalani <[hidden email]>:
>
> > Hi Guillaume,
> >
> > Out of curiosity, why do you think OSGi fragments are not a good solution
> > in general?
> >
>
> The original primary use case for fragments is to extend a given bundle.
> Using it as a workaround for proper modularisation is too much imho.
> A cleaner way to extend a given bundle's functionality is to use OSGi
> services which allow for more dynamism in OSGi.
> Installing a fragment will cause bundles to be refreshed
>
>
> >
> > As for everything, they have their use case, right? Or is there a reason
> to
> > avoid them altogether, beyond one's liking or disliking of the technique?
> >
>
> There are valid use cases for using fragments, but again, I don't think
> using those as a workaround for proper modularisation is one of them (even
> though it works and certainly has been used this way, especially when you
> don't have real control over the code you want to deploy in OSGi).
>
> In the Artemis use case, the best way is definitely to refactor the code as
> needed so that it becomes a nice OSGi citizen.  As a short term solution
> (especially if there are some incompatibilities that need to be pushed to a
> major version for example), the simplest way imho is to use an
> uber-bundle.  The benefits is that all the OSGi stuff is concentrated into
> a single maven module, and the amount of work is much less.  The only small
> disadvantage compared to fragments would be that a bunch of import package
> need to be optional, whereas with fragments, those could be mandatory for a
> given fragment.  But at the end, both are similar as you can't really force
> an unresolvable fragment to cause a failure, so that in both case, if
> something is missing, there will be a runtime exception such as
> ClassNotFoundException.
>
>
> >
> > Thanks,
> > Raúl.
> > On 16 Nov 2015 15:18, "Guillaume Nodet" <[hidden email]> wrote:
> >
> > > I really don't see the point of using fragments.  Fragments are not a
> > good
> > > OSGi solution in general.
> > > The easiest way forward (even instead of using fragments) would be to
> use
> > > an uber-jar imho.
> > > At least, it has the benefit of limiting the code changes and locating
> > all
> > > the OSGi stuff in a single module.
> > >
> > > 2015-11-16 11:48 GMT+01:00 Raul Kripalani <[hidden email]>:
> > >
> > > > Once again, I do suggest you explore the OSGi Fragment route.
> > > >
> > > > I haven't digged into the Artemis source, but if your modularity
> scheme
> > > > consists of modules that provide classes and resources to a central
> > one,
> > > it
> > > > could fit well.
> > > >
> > > > This is the strategy I'm using with certain modules to OSGify Apache
> > > > Ignite.
> > > >
> > > > It also resolves the split package situation quite elegantly without
> > > being
> > > > a workaround (depending on the rationale of the split packages to
> begin
> > > > with).
> > > > On 16 Nov 2015 03:15, "artnaseef" <[hidden email]> wrote:
> > > >
> > > > > How much work are we talking to get Artemis properly OSGi-ready?
> An
> > > > > uber-jar
> > > > > is a work-around.  If nothing better can be accomplished, then we
> may
> > > > have
> > > > > to live with it in the near-term, but it is important to understand
> > > what
> > > > > challenges are driving us toward a work-around.
> > > > >
> > > > > Also, we have an individual showing interest to make this happen,
> so
> > > > let's
> > > > > encourage that effort!  Thank you Guillaume.
> > > > >
> > > > > I may be a bit tainted as these days I'm spending large amounts of
> > time
> > > > > refactoring code and eliminating the impacts of work-arounds and
> > > > shortcuts.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > > >
> > > >
> > >
> >
> http://activemq.2283324.n4.nabble.com/DISCUSS-OSGi-support-for-Artemis-tp4703943p4703972.html
> > > > > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
> > > > >
> > > >
> > >
> >
>
12