You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Guillaume Nodet <gn...@apache.org> on 2015/11/13 15:21:38 UTC
[DISCUSS] OSGi support for Artemis
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
Re: [DISCUSS] OSGi support for Artemis
Posted by Andy Taylor <an...@gmail.com>.
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 <cl...@gmail.com> 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 <dk...@apache.org> 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 <
> clebert.suconic@gmail.com> 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 <gn...@apache.org>
> 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
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>
>
>
> --
> Clebert Suconic
>
Re: [DISCUSS] OSGi support for Artemis
Posted by Christian Schneider <ch...@die-schneider.net>.
I think ordinary bundles will not work well regarding the mechanisms to
e.g. find protoccols.
Currently these assume all modules to be in the same classpath. So if
you put them into individual bundles they probably will not work out of
the box.
Maybe we can solve this using the Aries spi-fly as it seems the
Resourelocator mechanism is used. Not sure though.
So an ueber jar would fix that problem. On the other hand I am not sure
if we really would want to put all modules into it.
So I would rather like to first check how far we can get with a real
modularization.
Christian
On 17.11.2015 12:02, Raul Kripalani wrote:
> 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.
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] OSGi support for Artemis
Posted by Christian Schneider <ch...@die-schneider.net>.
I looked into the split packages in detail now. There are definitely
some cases that we can not solve without breaking the api.
The most prominent being the package
org.apache.activemq.artemis.api.core which is present in commons and
core-client.
So we can not solve the split package problem and must use some form of
combined jar. I am currently experimenting
with putting commons, core-client and server together. This solves
almost all of the split packages without packing all of artemis into one
jar.
I also took a closer look into spi-fly and I am not so fond of it
anymore. There are two big problems:
1. It needs to weave all bundles using ServiceLoader to tweak their
classloader.
2. It can not handle bundles going down or being restarted.
So I am looking into an alternative solution now. For example we could
create each impl as a service using an extender pattern based on the
META-INF/services informations.
The point where the instances are looked up must be enhanced then to
also look into OSGi services when in OSGi.
Christian
On 17.11.2015 14:33, Christian Schneider wrote:
> I propose the following approach:
>
> 1. remove the split packages
> 2. make each jar a bundle
> 3. use spi-fly to wire up the optional protocols and eventually other
> modules
>
> If any of these steps proves to be to much work or is otherwise not
> acceptable by the ActiveMQ community we fall back to the ueber jar
> approach.
> Do you have a concrete target date when you need the OSGi support? If
> yes then we could also set us a time limit for the above steps.
> From my side the effort on Artemis is not yet product relevant so I do
> not have a concrete release date.
>
> WDYT?
>
> Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] OSGi support for Artemis
Posted by Christian Schneider <ch...@die-schneider.net>.
I propose the following approach:
1. remove the split packages
2. make each jar a bundle
3. use spi-fly to wire up the optional protocols and eventually other
modules
If any of these steps proves to be to much work or is otherwise not
acceptable by the ActiveMQ community we fall back to the ueber jar approach.
Do you have a concrete target date when you need the OSGi support? If
yes then we could also set us a time limit for the above steps.
From my side the effort on Artemis is not yet product relevant so I do
not have a concrete release date.
WDYT?
Christian
On 17.11.2015 13:06, Guillaume Nodet wrote:
> As I said, my proposal of the uber-jar is just meant to be a short term
> solution.
> The locator pattern is not really ideal in OSGi either, the best way is
> definitely to use OSGi services,
> but it mainly depends how far we would want to go with modularisation.
> We could decide to make protocols available in the OSGi registry and even
> support them being changed on the fly why not impacting other protocols,
> but this may be problematic with how the core is written (not sure that can
> easily be supported, and that would also affect the configuration of those
> transports).
> If we don't go that way, using a locator pattern is good enough and we
> should be able to easily tweak the code to support OSGi.
>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] OSGi support for Artemis
Posted by Guillaume Nodet <gn...@apache.org>.
2015-11-17 12:31 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
> I think ordinary bundles will not work well regarding the mechanisms to
> e.g. find protoccols.
> Currently these assume all modules to be in the same classpath. So if you
> put them into individual bundles they probably will not work out of the box.
>
> Maybe we can solve this using the Aries spi-fly as it seems the
> Resourelocator mechanism is used. Not sure though.
> So an ueber jar would fix that problem. On the other hand I am not sure if
> we really would want to put all modules into it.
>
> So I would rather like to first check how far we can get with a real
> modularization.
As I said, my proposal of the uber-jar is just meant to be a short term
solution.
The locator pattern is not really ideal in OSGi either, the best way is
definitely to use OSGi services,
but it mainly depends how far we would want to go with modularisation.
We could decide to make protocols available in the OSGi registry and even
support them being changed on the fly why not impacting other protocols,
but this may be problematic with how the core is written (not sure that can
easily be supported, and that would also affect the configuration of those
transports).
If we don't go that way, using a locator pattern is good enough and we
should be able to easily tweak the code to support OSGi.
>
>
> Christian
>
> On 17.11.2015 12:02, Raul Kripalani wrote:
>
>> 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.
>>
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: [DISCUSS] OSGi support for Artemis
Posted by Christian Schneider <ch...@die-schneider.net>.
I think ordinary bundles will not work well regarding the mechanisms to
e.g. find protoccols.
Currently these assume all modules to be in the same classpath. So if
you put them into individual bundles they probably will not work out of
the box.
Maybe we can solve this using the Aries spi-fly as it seems the
Resourelocator mechanism is used. Not sure though.
So an ueber jar would fix that problem. On the other hand I am not sure
if we really would want to put all modules into it.
So I would rather like to first check how far we can get with a real
modularization.
Christian
On 17.11.2015 12:02, Raul Kripalani wrote:
> 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.
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] OSGi support for Artemis
Posted by Guillaume Nodet <gn...@apache.org>.
2015-11-17 12:02 GMT+01:00 Raul Kripalani <ra...@apache.org>:
> 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!
>
If the imported packages are optional, you don't drag any dependencies.
That's what I've done in the project I've pushed to my github. It's
clearly not ideal,
as optional dependencies mean that you'll hit ClassNotFoundException at
runtime.
But it effectively has the same effect as using fragments, as you can't
really force a fragment to be resolved (well, actually, you can, but it's
tricky).
>
> 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 <gn...@apache.org>
> wrote:
>
> > 2015-11-17 1:52 GMT+01:00 Raul Kripalani <ra...@evosent.com>:
> >
> > > 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" <gn...@apache.org> 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 <ra...@evosent.com>:
> > > >
> > > > > 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" <ar...@artnaseef.com> 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.
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] OSGi support for Artemis
Posted by Raul Kripalani <ra...@apache.org>.
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 <gn...@apache.org> wrote:
> 2015-11-17 1:52 GMT+01:00 Raul Kripalani <ra...@evosent.com>:
>
> > 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" <gn...@apache.org> 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 <ra...@evosent.com>:
> > >
> > > > 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" <ar...@artnaseef.com> 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.
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] OSGi support for Artemis
Posted by Guillaume Nodet <gn...@apache.org>.
2015-11-17 1:52 GMT+01:00 Raul Kripalani <ra...@evosent.com>:
> 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" <gn...@apache.org> 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 <ra...@evosent.com>:
> >
> > > 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" <ar...@artnaseef.com> 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.
> > > >
> > >
> >
>
Re: [DISCUSS] OSGi support for Artemis
Posted by Raul Kripalani <ra...@evosent.com>.
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" <gn...@apache.org> 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 <ra...@evosent.com>:
>
> > 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" <ar...@artnaseef.com> 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.
> > >
> >
>
Re: [DISCUSS] OSGi support for Artemis
Posted by Guillaume Nodet <gn...@apache.org>.
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 <ra...@evosent.com>:
> 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" <ar...@artnaseef.com> 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.
> >
>
Re: [DISCUSS] OSGi support for Artemis
Posted by Raul Kripalani <ra...@evosent.com>.
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" <ar...@artnaseef.com> 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.
>
Re: [DISCUSS] OSGi support for Artemis
Posted by artnaseef <ar...@artnaseef.com>.
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.
Re: [DISCUSS] OSGi support for Artemis
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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 <gn...@apache.org> 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 <clebert.suconic@gmail.com
> <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 <dkulp@apache.org
> <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 <
> > clebert.suconic@gmail.com <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 <gnodet@apache.org
> <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
> > > dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> > > Talend Community Coder - http://coders.talend.com
> > >
> >
> >
> >
> > --
> > Clebert Suconic
> >
>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Re: [DISCUSS] OSGi support for Artemis
Posted by Clebert Suconic <cl...@gmail.com>.
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 <gn...@apache.org> 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 <cl...@gmail.com>:
>
>> 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 <dk...@apache.org> 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 <
>> clebert.suconic@gmail.com> 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 <gn...@apache.org>
>> 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
>> > dkulp@apache.org - http://dankulp.com/blog
>> > Talend Community Coder - http://coders.talend.com
>> >
>>
>>
>>
>> --
>> Clebert Suconic
>>
--
Clebert Suconic
Re: [DISCUSS] OSGi support for Artemis
Posted by Guillaume Nodet <gn...@apache.org>.
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 <cl...@gmail.com>:
> 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 <dk...@apache.org> 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 <
> clebert.suconic@gmail.com> 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 <gn...@apache.org>
> 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
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>
>
>
> --
> Clebert Suconic
>
Re: [DISCUSS] OSGi support for Artemis
Posted by Clebert Suconic <cl...@gmail.com>.
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 <dk...@apache.org> 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 <cl...@gmail.com> 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 <gn...@apache.org> 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
Clebert Suconic
Re: [DISCUSS] OSGi support for Artemis
Posted by Daniel Kulp <dk...@apache.org>.
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 <cl...@gmail.com> 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 <gn...@apache.org> 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] OSGi support for Artemis
Posted by Clebert Suconic <cl...@gmail.com>.
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 <gn...@apache.org> 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
Re: [DISCUSS] OSGi support for Artemis
Posted by Christian Schneider <ch...@die-schneider.net>.
I have used the script from Arthur to create a list of duplicate packages.
I removed the obvious false positives (mainly from examples) and created
a wiki page:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61329082
So first thing is that there a quite a lot of such packages. So if we
want to clean them up it will be a lot of work. It is also probably not
possible to avoid breaking the API then moving packages or classes.
Still I think it makes sense to start with this task while keeping
things stable (just to improve the modularity of artemis over time).
When we consider breaking the API then I think we should rather do it in
the server
module as I guess that less people depend on the server than on the client.
Unfortunately I think we can not fix this in the short term so we will
need an alternative solution.
If you look at the packages closely you will find that most duplications
are between artemis-core-client and artemis-server. So it might be a
good idea to build a bundle out of these two.
Eventually this might also be a case for a fragment if we want to allow
the installation of just artemis-core-client too. So maybe
artemis-server could be a fragment to artemis-core-client. Not sure
though as I rarely use fragments.
There are 4 packages were artemis-commons is also involved. So as this
is a rather low number we can try to fix these. In case it fails it
could be added to the bigger bundle.
I would be happy about any feedback or alternative solutions.
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
Re: [DISCUSS] OSGi support for Artemis
Posted by Guillaume Nodet <gn...@apache.org>.
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 <cl...@gmail.com>:
> 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
> <ch...@die-schneider.net> 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
>
Re: [DISCUSS] OSGi support for Artemis
Posted by artnaseef <ar...@artnaseef.com>.
Here's a script that will nicely list all of the packages with more than one
source root followed by the list of roots:
Note that for the AMQ source code, it comes up with many things, including
(this is partial output):
--
View this message in context: http://activemq.2283324.n4.nabble.com/DISCUSS-OSGi-support-for-Artemis-tp4703943p4703990.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] OSGi support for Artemis
Posted by artnaseef <ar...@artnaseef.com>.
A simple shell script would work well if we have access to all the
directories.
Something like this:
Or, this is even better:
--
View this message in context: http://activemq.2283324.n4.nabble.com/DISCUSS-OSGi-support-for-Artemis-tp4703943p4703989.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] OSGi support for Artemis
Posted by Clebert Suconic <cl...@gmail.com>.
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
<ch...@die-schneider.net> 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
Re: [DISCUSS] OSGi support for Artemis
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: [DISCUSS] OSGi support for Artemis
Posted by Raul Kripalani <ra...@apache.org>.
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 <gn...@apache.org> 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
>