tag:blogger.com,1999:blog-9210566578097047576.post8112532715448106308..comments2023-11-05T02:04:07.740-08:00Comments on <coderthoughts />: java.util.ServiceLoader in OSGiDavid Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-9210566578097047576.post-85574516570380250752015-12-08T23:58:19.408-08:002015-12-08T23:58:19.408-08:00Hi David,
I've created ARIES-1470 JIRA issue,...Hi David,<br /><br />I've created ARIES-1470 JIRA issue, but I doubt the description is enough to reproduce the problem since it's intermittent. I wish I could attach Virgo Jetty Server instance with our small apps deployed, but the size is prohibitive.<br />From my observation the error seems to be caused by the interface classloader being different from the implementation, so it's regarded not assignable.<br /><br />Regards,<br />SetyaSetyahttps://www.blogger.com/profile/03813815691287052202noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-49917536013257444452015-12-08T03:08:09.316-08:002015-12-08T03:08:09.316-08:00Hi Setya,
I haven't come across that one yet....Hi Setya,<br /><br />I haven't come across that one yet. Would it be possible to create an issue in ARIES jira <a href="https://issues.apache.org/jira/browse/ARIES" rel="nofollow">https://issues.apache.org/jira/browse/ARIES</a> with little testcase so that I can try to reproduce?<br /><br />Thanks,<br /><br />DavidDavid Bosschaerthttps://www.blogger.com/profile/13786738766478890804noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-3482548354534568372015-12-08T00:26:36.930-08:002015-12-08T00:26:36.930-08:00Hi David,
When ServiceLoader is used in OSGI envi...Hi David,<br /><br />When ServiceLoader is used in OSGI environment as is, does the problem include as depicted the following error message pattern:<br /><br />Caused by: java.util.ServiceConfigurationError: xxx : Provider xxx not a subtype<br /><br />Cause I've followed your static weaving approach yet the problem persists.<br /><br />Regards,<br />SetyaSetyahttps://www.blogger.com/profile/03813815691287052202noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-4517305297767433052012-10-25T01:41:20.068-07:002012-10-25T01:41:20.068-07:00Hi Dieter, it seems like you're using pure Jav...Hi Dieter, it seems like you're using pure JavaEE deployments here. As far as I understand JBoss AS has built-in support for these. This article relates to using java.util.ServiceLoader in OSGi...David Bosschaerthttps://www.blogger.com/profile/13786738766478890804noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-31312270851170510962012-10-25T01:10:01.774-07:002012-10-25T01:10:01.774-07:00It just works (using AS 7.1.3). Am i missing somet...It just works (using AS 7.1.3). Am i missing something here?<br /><br />I have an .ear file containing many jars, one having the interface and the ServiceLoader.load(class_).iterator() code, and other ones having implementations and the META-INF/services/* files, and my code _does_ obtain all implementations.<br /><br />This solution is probably built in somehow (without the need for the additional manifest headers).<br /><br />Anonymoushttps://www.blogger.com/profile/12926655590086779720noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-76969167552225462262012-10-25T01:02:11.467-07:002012-10-25T01:02:11.467-07:00I'm using jboss 7.1.3 and java.util.ServiceLoa...I'm using jboss 7.1.3 and java.util.ServiceLoader.load(class_).iterator() just works, it succeeds in loading all implementations from different jars within my ear file. Some of these jars are in the ear file root, others in the /lib folder. <br /><br />So i got curious and printed the classloader in the default constructor of my implementations, and it printed a classloader that referred to the jar containing the implementation class.<br /><br />So i guess jboss 7.1.3 somehow has your solution on board, but without the additional manifest entries.Anonymoushttps://www.blogger.com/profile/12926655590086779720noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-38412929601447206692012-09-06T01:05:23.178-07:002012-09-06T01:05:23.178-07:00Hi Charles,
"Could you also mention in your ...Hi Charles,<br /><br />"Could you also mention in your post that for static weaving, we must use the tool as mentioned on Aries Web Site."<br /><br />Thanks for the feedback, yes I will keep that in mind. I've recently changed the build so that it will automatically build the static tool by default. Once the SPI Fly 1.0 release is out it should be possibly to download this as an executable jar file from maven. That should simplify things a little hopefully.David Bosschaerthttps://www.blogger.com/profile/13786738766478890804noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-13064082276107991022012-09-06T01:01:40.257-07:002012-09-06T01:01:40.257-07:00Thx for the update David. Appreciate also that you...Thx for the update David. Appreciate also that you will work on SpiFly release. As Aries will publish soon also a 1.0 release, that could be great to have also SpiFly.<br /><br />Remark : Could you also mention in your post that for static weaving, we must use the tool as mentioned on Aries Web Site.cmoulliardhttps://www.blogger.com/profile/06574597725926921707noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-6001451651196921232012-09-06T00:55:22.357-07:002012-09-06T00:55:22.357-07:00Hi Charles,
Sorry for removing those downloads - ...Hi Charles,<br /><br />Sorry for removing those downloads - I cleaned up my dropbox recently and apparently removed a bit too much :)<br /><br />In any case the SPI Fly project has moved on quite a bit since as it now implements the <a href="http://www.osgi.org/Download/Release5" rel="nofollow">OSGi Enterprise R5 Spec Chapter 133</a>. <br />All of the download links that I put in drop can be obtained by simply doing a 'mvn install' in <a href="http://svn.apache.org/repos/asf/aries/trunk/spi-fly" rel="nofollow">http://svn.apache.org/repos/asf/aries/trunk/spi-fly</a> so they're quite easy to recreated. In the mean time I'll work on getting an SPI Fly 1.0 release out and will update the article with permanent links once its there.<br /><br />BTW the SPI Fly documentation has recently been updated too with information on how to get this running, see here: <a href="http://aries.apache.org/modules/spi-fly.html" rel="nofollow">http://aries.apache.org/modules/spi-fly.html</a>David Bosschaerthttps://www.blogger.com/profile/13786738766478890804noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-53961446300353611962012-09-05T23:37:08.489-07:002012-09-05T23:37:08.489-07:00Hi David,
Thx for this excellent publication whic...Hi David,<br /><br />Thx for this excellent publication which is an excellent intro about Aries Spi-Fly. For your information the dropbox links are not longer available. Could you reactivate them or provide other link reference ? I see that some examples have been published in Aries project They could maybe help us too.<br /><br />Regards,<br /><br />Charlescmoulliardhttps://www.blogger.com/profile/06574597725926921707noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-29610425315852745322011-08-30T00:59:49.673-07:002011-08-30T00:59:49.673-07:00@Erik:
Using a bundle tracker and delegating the l...@Erik:<br />Using a bundle tracker and delegating the loading to the bundle is exactly what I'm doing too :) And I'm registering these objects in the OSGi Service Registry...<br /><br />"For the client side an API similar but different from java.util.ServiceLoader was used"<br />Yes, if you can use a different API in the client that's obviously better. I would suggest using the OSGi ServiceRegistry instead of java.util.ServiceLoader if you can :)David Bosschaerthttps://www.blogger.com/profile/13786738766478890804noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-48411566380331718642011-08-30T00:52:35.592-07:002011-08-30T00:52:35.592-07:00@Cole:
"look for META-INF/services for each ...@Cole: <br />"look for META-INF/services for each bundle ... and register the service with the OSGi Service Registry" is actually something that I'm doing too. Granted, I only mention it briefly above:<br /> "It registers the implementations found in META-INF/services in the OSGi Service Registry so that they can be used from there too"<br />I think that could fit very much with your ideas around using these SPIs with DS. It's described in more detail in RFC 167: <a href="http://www.osgi.org/download/osgi-early-draft-2011-05.pdf" rel="nofollow">http://www.osgi.org/download/osgi-early-draft-2011-05.pdf</a><br /><br />On the consumer side we have a bigger problem. Because java.util.ServiceLoader is in the java.* package, the JVM doesn't allow you to replace it (that's a security feature of Java). And because it's a final class you can't even subclass it to provide an alternative implementation. So if you want to make existing consumers that happen to use java.util.ServiceLoader work without changing their code you'd have to work within the boundaries of that class, which is what I did. Another option could be to use byte code manipulation to change all the invocations java.util.ServiceLoader.load() to something else (e.g. something that looks up the implementation in the SR). That would be an alternative implementation option - for the user they would be more or less equivalent I think?David Bosschaerthttps://www.blogger.com/profile/13786738766478890804noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-85596326822703138112011-08-29T12:12:10.090-07:002011-08-29T12:12:10.090-07:00I used a solution in the past where we had a lot o...I used a solution in the past where we had a lot of existing services that were designed for a java SE environment but where we wanted a more dynamic way of loading them. <br /><br />For that we used OSGi, and using a bundle tracker it was possible to read the META-INF/services/ file from each deployed bundle.<br /><br />Then the classes were loaded using the bundle class loader (bundle.loadClass()), i.e. delegating to the bundle. The bundles containing the services did not export the package. <br /><br />For the client side use an API similar but different from java.util.ServiceLoader was used. This was acceptable since there was only one client but many services and modifying the client was acceptable.<br /><br />I also didn't go that far to identify bundles as SPI-Providers.<br /><br />From what I gather from your description, your approach is more generic since you use the same client API as Java SE but modified using AOP to implement this new behavior and also restricting the overhead of the mechanism using the SPI headers. In this way it is an attractive solution since clients can remain unmodified as well. <br /><br />Interesting stuff.Erik Brakkeehttps://www.blogger.com/profile/00016658868018858475noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-87665088760627301832011-08-29T09:28:35.298-07:002011-08-29T09:28:35.298-07:00When I started reading your article, I had thought...When I started reading your article, I had thoughts forming in my head of how this might be accomplished. It turned out to be a very different approach from yours so I thought I would share.<br /><br />For starters, we have been big fans of Declarative Services for a while now, specifically the Equinox implementation. That got me thinking that service providers could just be picked up the same way and offered as declarative services. Perhaps it would be possible to just look for META-INF/services for each bundle that is registered, and then register the service with the OSGi service registry as the SPI interface. Equinox DS uses a proxy instance so that the actual service implementation is not instantiated until it is requested so this could be done here as well.<br /><br />For the consumer side, perhaps the framework could provide a custom implementation of java.util.ServiceLoader that would just look in the OSGi service registry and find the appropriate service. Since the framework has control over the classloader it should be able to do this I think.<br /><br />Then it should all *just work*, with the added benefit that both sides wouldn't actually have to be using ServiceLoader. You could have providers and/or consumers using proper OSGi.<br /><br />I'll have to do some digging and see if this would be possible. Anyone else have a though on this idea?Colehttps://www.blogger.com/profile/13574260598352133591noreply@blogger.comtag:blogger.com,1999:blog-9210566578097047576.post-59814726782896582092011-08-29T07:47:47.473-07:002011-08-29T07:47:47.473-07:00I wrote a blog entry about precisely this issue: h...I wrote a blog entry about precisely this issue: http://mwnorman.blogspot.com/2010/09/overriding-built-in-java-httpserver.html<br /><br />I have entered a bug (https://bugs.openjdk.java.net/show_bug.cgi?id=100152), but unfortunately, it hasn't been assigned to anyone.Mike Normanhttps://www.blogger.com/profile/02938548382263095170noreply@blogger.com