Well, if you have class loading issues … you’re doing it wrong. OSGi is lovely
when you follow the rules of modularity. If you use clean services models it
works like a charm. I know I am the expert but with the companies that I’ve
helped we rarely ever have them. And when we find the cause, it is ALWAYS some
class loading hack in a non-modular JAR.
Clearly the problem is really that there are so many JARs out there that
violate the basic premises of modularity. So OSGi’s primary drawback is that
you often cannot use that badly written software. This is upsetting for many
because so unmodular software is actually quite popular. Fortunately, Java 9
exposes those problems also. It will be interesting to watch if this will make
JARs more modular or make Java 9 wither. The verdict is still out I think.
It never ceases to amaze me how developers nowadays go out of their way to get
their code through draconian Sonar coding rules but have no qualms in creating
huge mistakes in their (dependency) architecture. I often get the feeling many
do not understand how important it is to consciously handle dependencies.
Anyway, if you do not want to do it right, OSGi is a beast and I do advise
anybody to run if you ‘re not willing to invest in modular service based
software. OSGi is a terrible classpath replacement.
So what is the advantage then of OSGi done well? Well, it gives you an amazing
flexibility and agileness. Since you are clearly in charge of your
dependencies, it turns out you can use the same software in lots of different
applications with very little effort. With OSGi you will not run in this
nightmare of a Leviathan application where you spend more time fixing bugs than
adding features that seems the destiny of so many efforts.
If you see class loader exceptions, don’t blame OSGi, it is just the messenger.
Step back and find the root cause of what you’re doing wrong.
Kind regards,
Peter Kriens
> On 15 Jun 2018, at 09:12, Raffaele Gambelli via osgi-dev
> <osgi-dev@mail.osgi.org> wrote:
>
> Thanks again Raymond,
>
> start ordering was ok, I mean that I have Apache Aries with a start order of
> 4 and my bundle with 5, I actually can see Apache Aries see my Service,
> please take a look to the attached piacture, it is a screenshot from my Felix
> console, where it's clear that Aries recognizes the service provider.
>
> These kind of problems are really frustrating and are the main cause of OSGI
> abandonment by my company, we are very tired to spend a lot of time to find
> workaround for class loading issues
>
> Thanks again, bye
>
> Raffaele Gambelli
> WebRainbow® Software Analyst & Developer
>
> Hitachi Systems CBT
> r.gambe...@hitachi-systems-cbt.com | Phone +39 051 8550 576
> Via Ettore Cristoni, 84 | 40033 Casalecchio Di Reno
> www.hitachi-systems-cbt.com
>
> This email for the D.Lgs n.196/2003 (Privacy Code), may contain confidential
> and/or privileged information for the sole use of the intended recipient. Any
> review or distribution by others is strictly prohibited. If you are not the
> intended recipient, you must not use, copy, disclose or take any action based
> on this message or any information here. If you have received this email in
> error, please contact us (e-mail: priv...@hitachi-systems-cbt.com) by reply
> e-mail and delete all copies. Legal privilege is not waived because you have
> read this e-mail. Thank you for your cooperation.
>
>
> -----Raymond Auge <raymond.a...@liferay.com> ha scritto: -----
> Per: Raffaele Gambelli <r.gambe...@hitachi-systems-cbt.com>
> Da: Raymond Auge <raymond.a...@liferay.com>
> Data: 14/06/2018 08.49PM
> Cc: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Oggetto: Re: [osgi-dev] Migrating existing projects to OSGi, ServiceLoader
>
> One other thing you could check is the starting order of your bundles. Most
> things that use weaving hooks (SpiFly does) is subject to start ordering.
>
> so make sure SpiFly is started before the bundles it weaves.
>
> Sincerely,
> - Ray
>
> On Thu, Jun 14, 2018 at 5:57 AM, Raffaele Gambelli <
> r.gambe...@hitachi-systems-cbt.com
> <mailto:r.gambe...@hitachi-systems-cbt.com>> wrote:
> Hello Raymond and thank you,
>
> yes we know exactly that it is used the single argument ServiceLoader
> constructor and yes we think to have followed all steps showed in Apache
> Aries SPI Fly doc.
> Felix console shows our bundles and their services, so it seems all right,
> but when invoking the constructor it logs error not finding any
> implementation, here follows the ServiceLoader invocation made in the third
> party library:
>
> static {
> ServiceLoader<IUtils> loader = ServiceLoader.load(IUtils.
> class);
> Iterator<IUtils> iterator = loader.iterator();
>
> if (!iterator.hasNext()) {
> throw new ExceptionInInitializerError(
>
> "No implementation found for IUtils
> in classpath, please choose between dss-utils-apache-commons or
> dss-utils-google-guava");
>
> }
> impl = iterator.next();
>
> }
>
> Thanks, bye
>
> Raffaele Gambelli
> WebRainbow® Software Analyst & Developer
>
> Hitachi Systems CBT
> r.gambe...@hitachi-systems-cbt.com
> <mailto:r.gambe...@hitachi-systems-cbt.com> | Phone +39 051 8550 576
> <https://maps.google.com/?q=576+%0D%0AVia+Ettore+Cristoni&entry=gmail&source=g>
> Via Ettore Cristoni, 84 | 40033 Casalecchio Di Reno
> www.hitachi-systems-cbt.com <http://www.hitachi-systems-cbt.com/>
>
> This email for the D.Lgs n.196/2003 (Privacy Code), may contain confidential
> and/or privileged information for the sole use of the intended recipient. Any
> review or distribution by others is strictly prohibited. If you are not the
> intended recipient, you must not use, copy, disclose or take any action based
> on this message or any information here. If you have received this email in
> error, please contact us (e-mail: priv...@hitachi-systems-cbt.com
> <mailto:priv...@hitachi-systems-cbt.com>) by reply e-mail and delete all
> copies. Legal privilege is not waived because you have read this e-mail.
> Thank you for your cooperation.
>
>
> -----Raymond Auge < raymond.a...@liferay.com
> <mailto:raymond.a...@liferay.com>> ha scritto: -----
> Per: Raffaele Gambelli < r.gambe...@hitachi-systems-cbt.com
> <mailto:r.gambe...@hitachi-systems-cbt.com>>, OSGi Developer Mail List <
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>
> Da: Raymond Auge < raymond.a...@liferay.com <mailto:raymond.a...@liferay.com>>
> Data: 13/06/2018 03.48PM
> Oggetto: Re: [osgi-dev] Migrating existing projects to OSGi, ServiceLoader
>
> Hello Raffaele,
>
> Have you read through the this page starting with
> http://aries.apache.org/modules/spi-fly.html#making-it-work
> <http://aries.apache.org/modules/spi-fly.html#making-it-work>
>
> Also, do you know exactly which ServiceLoader method is used in the Service
> Interface bundle? (it has to be the single argument ServiceLoader.load(Class)
> method to work with the OSGi standardized approach).
>
> Sincerely,
> - Ray
>
> On Wed, Jun 13, 2018 at 5:50 AM, Raffaele Gambelli via osgi-dev
> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> > wrote:
> Hi all,
>
> I would like to use a third party library in my Equinox, it makes use of
> ServiceLoader to loade an implementation coming from a different jar.
>
> I created a bundle containing:
> - my code which calls third party jar
> - the third party jar containing the Service interface
> - the third party jar containing the Service implementation
> - the require and provide capability as suggested in Aries SPI Fly
>
> I can see in my Felix console that bundle is active and I can see its service
> id, nevertheless when I invoke the getInstance of my class which in turn
> calls the third party code which calls ServiceLoader.load, the concrete class
> is not found :-(
>
> Any help woulb be appreciated, thanks in advance, bye
>
> Raffaele Gambelli
> WebRainbow® Software Analyst & Developer
>
> Hitachi Systems CBT
> r.gambe...@hitachi-systems-cbt.com
> <mailto:r.gambe...@hitachi-systems-cbt.com> | Phone +39 051 8550 576
> <https://maps.google.com/?q=576+Via+Ettore+Cristoni&entry=gmail&source=g>
> Via Ettore Cristoni
> <https://maps.google.com/?q=576+Via+Ettore+Cristoni&entry=gmail&source=g>, 84
> | 40033 Casalecchio Di Reno
> www.hitachi-systems-cbt.com <http://www.hitachi-systems-cbt.com/>
>
> This email for the D.Lgs n.196/2003 (Privacy Code), may contain confidential
> and/or privileged information for the sole use of the intended recipient. Any
> review or distribution by others is strictly prohibited. If you are not the
> intended recipient, you must not use, copy, disclose or take any action based
> on this message or any information here. If you have received this email in
> error, please contact us (e-mail: priv...@hitachi-systems-cbt.com
> <mailto:priv...@hitachi-systems-cbt.com>) by reply e-mail and delete all
> copies. Legal privilege is not waived because you have read this e-mail.
> Thank you for your cooperation.
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
>
>
> --
> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>
>
>
> --
> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
> <apacheAriesSpiFly.png>_______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
