We've been using ServiceLoader together with OSGi in taverna-scufl2. You have to kind of allow your application to do both: e.g. you can have setters and getters that can be injected in with OSGi Spring services - and then if they have not been set (null), populate with service loader.
https://github.com/taverna/taverna-scufl2/blob/master/scufl2-api/src/main/java/uk/org/taverna/scufl2/api/io/WorkflowBundleIO.java#L144 falls back to ServiceLoader in https://github.com/taverna/taverna-scufl2/blob/master/scufl2-api/src/main/java/uk/org/taverna/scufl2/api/io/WorkflowBundleIO.java#L83 Implementations are listed both in ServiceLoader style: https://github.com/taverna/taverna-scufl2/blob/master/scufl2-api/src/main/resources/META-INF/services/uk.org.taverna.scufl2.api.io.WorkflowBundleReader and wired up as Spring services: https://github.com/taverna/taverna-scufl2/blob/master/scufl2-api/src/main/resources/META-INF/spring/scufl2-api-context-osgi.xml#L8 https://github.com/taverna/taverna-scufl2/blob/master/scufl2-api/src/main/resources/META-INF/spring/scufl2-api-context.xml On 5 November 2014 11:49, Andy Seaborne <a...@apache.org> wrote: > Restructuring is certainly the way to go in the case of ARQ modifying core. > The simple solution is merge the codebases then restructure at leisure, and > that isn't a Jena3 issue. > > What is the experience of ServiceLoader and how does it (and > "META-INF/services/") interact with OSGi? ServiceLoader contains calls to > Class.forName. > > Andy > > > > On 05/11/14 09:45, Rob Vesse wrote: >> >> Yes longer term (and now we have moved to Java 7) it would be best to >> avoid dynamic class loading where possible and use the Java 7 >> ServiceLoader paradigm instead. >> >> Some of the existing stuff is because of the existing module structure >> meaning that it is actually preferable to use the ARQ implementations over >> some things in Jena Core (e.g. readers and writers) but the module >> structure means Jena-Core can't guarantee the presence. We have talked >> about restructuring the modules longer term (I.e. Jena3) which would also >> resolve some of this kind of problem and avoid any need for ServiceLoader >> or dynamic class loading in places >> >> However there will likely still be some places where dynamic class loading >> would need to remain e.g. Jena assembler, use of java: URIs for extension >> functions because they are useful features >> >> Rob >> >> On 04/11/2014 09:54, "Minto van der Sluis" <mi...@xup.nl> wrote: >> >>> Hi, >>> >>> If I recall correctly it is required due Jena using dynamic class >>> loading (Class.forName). Doing a grep on my "not updated in a long time" >>> checkout reveals 38 occurrences. >>> >>> If Jena is considering to provide OSGi bundles maybe then reconsider >>> using an alternative for dynamic class loading. >>> >>> Regards, >>> >>> Minto >>> >>> >>> >>> >>> Reto Gmür schreef op 4-11-2014 14:32: >>>> >>>> Hi Stian, >>>> >>>> If I understood and remember correctly the problem are circular >>>> dependencies between jena artifacts and packages occurring in multiple >>>> jars. I'm sure Minto (CC) can tell you the reasons more. >>>> >>>> If providing OSGi bundles becomes part of Jena then maybe the root >>>> cause of requiring this rather ugly dynamic imports and split-packages >>>> can be addressed. This is likely to be beneficial to the overall design. >>>> >>>> Cheers, >>>> Reto >>>> >>>> On Tue, Nov 4, 2014 at 2:15 PM, Stian Soiland-Reyes >>>> <soiland-re...@cs.manchester.ac.uk >>>> <mailto:soiland-re...@cs.manchester.ac.uk>> wrote: >>>> >>>> Reto, what was the reason for why Clerezza made the >>>> clerezza.osgi.dynamicimport.pkg indirect properties? >>>> >>>> Not sure I quite get this property: >>>> >>>> >>>> >>>> >>>> <clerezza.osgi.export>${clerezza.osgi.export.pkg}*;version=${pkgVersion}; >>>> -split-package:=merge-first >>>> </clerezza.osgi.export> >>>> >>>> >>>> >>>> >>>> On 4 November 2014 13:12, Stian Soiland-Reyes >>>> <soiland-re...@cs.manchester.ac.uk >>>> <mailto:soiland-re...@cs.manchester.ac.uk>> wrote: >>>> > If you found that splitting it up into different bundles works, >>>> then >>>> > perhaps we should not need to have any wrapping bundles at all, >>>> and >>>> > can just add the <packaging>bundle</packaging> stuff to the main >>>> > modules? >>>> > >>>> > >>>> > >>>> > On 4 November 2014 10:54, Reto Gmür <r...@apache.org >>>> <mailto:r...@apache.org>> wrote: >>>> >> Hi >>>> >> >>>> >> In the clerezza project we have been wrapping jena for a while >>>> as OSGi >>>> >> bundles. >>>> >> >>>> >> Recently it got split up into different bundles. The source >>>> (i.e. the poms) >>>> >> can be seen here: >>>> >> >>>> >> https://github.com/apache/clerezza/tree/master/ext >>>> >> >>>> >> Cheers, >>>> >> Reto >>>> >> >>>> >> On Sat, Nov 1, 2014 at 2:26 AM, Stian Soiland-Reyes < >>>> >> soiland-re...@cs.manchester.ac.uk >>>> <mailto:soiland-re...@cs.manchester.ac.uk>> wrote: >>>> >> >>>> >>> I would like to hear from your experience of a custom-wrapped >>>> bundle >>>> >>> what you decided to include or not. >>>> >>> >>>> >>> See my other email message in this thread.. >>>> >>> >>>> >>> Basically in short: >>>> >>> >>>> >>> >>>> >>> >>>> >>>> >>>> http://build.mygrid.org.uk/ci/job/jena-bundle/21/org.apache.jena$jena-osg >>>> i/ >>>> >>> >>>> >>> >>>> >>> >>>> >>>> >>>> http://repository.mygrid.org.uk/artifactory/ext-snapshot-local/org/apache >>>> /jena/jena-osgi/2.12.2-SNAPSHOT/ >>>> >>> >>>> >>> >>>> >>>> >>>> http://repository.mygrid.org.uk/artifactory/ext-snapshot-local/org/apache >>>> /jena/jena-parent/12-SNAPSHOT/ >>>> >>> >>>> >>> >>>> >>> >>>> >>> On 31 October 2014 13:27, Mark Feblowitz >>>> <markfeblow...@icloud.com <mailto:markfeblow...@icloud.com>> wrote: >>>> >>> > I’m an OSGi user, and have been using a custom-wrapped Jena >>>> OSGi bundle >>>> >>> for more than a year. >>>> >>> > >>>> >>> > I’d be happy to try it out. How would I do so? >>>> >>> > >>>> >>> > Mark >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> >> On Oct 31, 2014, at 6:56 AM, Andy Seaborne <a...@apache.org >>>> <mailto:a...@apache.org>> wrote: >>>> >>> >> >>>> >>> >> On 28/10/14 16:50, stain wrote: >>>> >>> >>> GitHub user stain opened a pull request: >>>> >>> >>> >>>> >>> >>> https://github.com/apache/jena/pull/10 >>>> >>> >>> >>>> >>> >>> Jena OSGi bundle >>>> >>> >>> >>>> >>> >>> Embedding core Jena modules in a single OSGi bundle. >>>> >>> >>> >>>> >>> >>> This works around classloader issues such as Jena's use >>>> of >>>> >>> `Class.forName()`, but does not yet support other OSGi bundles >>>> to easily >>>> >>> plug in 3rd party Jena implementations of say readers and >>>> writers. >>>> >>> >>> >>>> >>> >>> Modules included: >>>> >>> >>> * jena-core >>>> >>> >>> * jena-arq >>>> >>> >>> * jena-tdb >>>> >>> >>> * jena-sdb >>>> >>> >>> * jena-iri >>>> >>> >> >>>> >>> >> Having one bundle for Jena makes a lot of sense as we build >>>> and release >>>> >>> whole systems, so partial replacement of bits and pieces isn't >>>> >>> supported/encouraged anyway. Releases may change cross module >>>> >>> assumptions. Personally, I'd drop SDB from the included >>>> modules; it's >>>> >>> being made a maven-only module next time, and not in the >>>> distribution >>>> >>> binaries. >>>> >>> >> >>>> >>> >> What I'd really, really like is for this to be tested by >>>> other OSGi >>>> >>> users. As far as I know, none of the committers use OSGi >>>> day-to-day >>>> >>> (we/Epimorphics used to but when we looked at the >>>> costs/benefits we switch >>>> >>> to a simpler, service architecture style). >>>> >>> >> >>>> >>> >> Stain - what would you say to advertising this on users@ >>>> (and >>>> >>> dev@clerezza?) and seeing if we can get some user testing and >>>> validation? >>>> >>> >> >>>> >>> >> Andy >>>> >>> >> >>>> >>> >>> >>>> >>> >>> This OSGi bundle includes a dependency on the >>>> `httpclient-osgi` >>>> >>> and `httpcore-osgi` version. All other packages used are >>>> embeded within the >>>> >>> OSGi bundle, making them appear on a single classloader in >>>> OSGi. >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> You can merge this pull request into a Git repository by >>>> running: >>>> >>> >>> >>>> >>> >>> $ git pull https://github.com/stain/jena >>>> jena-osgi-bundle >>>> >>> >>> >>>> >>> >>> Alternatively you can review and apply these changes as >>>> the patch at: >>>> >>> >>> >>>> >>> >>> https://github.com/apache/jena/pull/10.patch >>>> >>> >>> >>>> >>> >>> To close this pull request, make a commit to your >>>> master/trunk branch >>>> >>> >>> with (at least) the following in the commit message: >>>> >>> >>> >>>> >>> >>> This closes #10 >>>> >>> >>> >>>> >>> >>> ---- >>>> >>> >>> commit 1957808b34a408bf0278cfb4017d6e7040eebabb >>>> >>> >>> Author: Stian Soiland-Reyes >>>> <soiland-re...@cs.manchester.ac.uk >>>> <mailto:soiland-re...@cs.manchester.ac.uk>> >>>> >>> >>> Date: 2014-10-28T16:03:15Z >>>> >>> >>> >>>> >>> >>> pom tweaks so it builds >>>> >>> >>> >>>> >>> >>> .. also a spelling mistake tixed >>>> >>> >>> >>>> >>> >>> commit 5724c31d542d7c8ddf89c4333fbe4809d7783f49 >>>> >>> >>> Author: Stian Soiland-Reyes >>>> <soiland-re...@cs.manchester.ac.uk >>>> <mailto:soiland-re...@cs.manchester.ac.uk>> >>>> >>> >>> Date: 2014-10-28T16:34:59Z >>>> >>> >>> >>>> >>> >>> Embedding all Jena modules in a single OSGi bundle. >>>> >>> >>> >>>> >>> >>> commit 3bb12d0a1472977cfcd51abf392683659bac1e4d >>>> >>> >>> Author: Stian Soiland-Reyes >>>> <soiland-re...@cs.manchester.ac.uk >>>> <mailto:soiland-re...@cs.manchester.ac.uk>> >>>> >>> >>> Date: 2014-10-28T16:38:00Z >>>> >>> >>> >>>> >>> >>> httpcore-osgi 4.2.5 >>>> >>> >>> >>>> >>> >>> commit aa705c9e3e4f3b4c58924e95aa223213358b08e3 >>>> >>> >>> Author: Stian Soiland-Reyes >>>> <soiland-re...@cs.manchester.ac.uk >>>> <mailto:soiland-re...@cs.manchester.ac.uk>> >>>> >>> >>> Date: 2014-10-28T16:42:48Z >>>> >>> >>> >>>> >>> >>> ver.* properties as in jena-parent >>>> >>> >>> >>>> >>> >>> TODO: Move these properties to jena-parent? >>>> >>> >>> >>>> >>> >>> ---- >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> --- >>>> >>> >>> If your project is set up for it, you can reply to this >>>> email and have >>>> >>> your >>>> >>> >>> reply appear on GitHub as well. If your project does not >>>> have this >>>> >>> feature >>>> >>> >>> enabled and wishes so, or if the feature is enabled but >>>> not working, >>>> >>> please >>>> >>> >>> contact infrastructure at infrastruct...@apache.org >>>> <mailto:infrastruct...@apache.org> or file a JIRA >>>> >>> ticket >>>> >>> >>> with INFRA. >>>> >>> >>> --- >>>> >>> >>> >>>> >>> >> >>>> >>> > >>>> >>> >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> Stian Soiland-Reyes, myGrid team >>>> >>> School of Computer Science >>>> >>> The University of Manchester >>>> >>> http://soiland-reyes.com/stian/work/ >>>> http://orcid.org/0000-0001-9842-9718 >>>> >>> >>>> > >>>> > >>>> > >>>> > -- >>>> > Stian Soiland-Reyes, myGrid team >>>> > School of Computer Science >>>> > The University of Manchester >>>> > http://soiland-reyes.com/stian/work/ >>>> http://orcid.org/0000-0001-9842-9718 >>>> >>>> >>>> >>>> -- >>>> Stian Soiland-Reyes, myGrid team >>>> School of Computer Science >>>> The University of Manchester >>>> http://soiland-reyes.com/stian/work/ >>>> http://orcid.org/0000-0001-9842-9718 >>>> >>>> >>> >>> >>> -- >>> ir. ing. Minto van der Sluis >>> Software innovator / renovator >>> Xup BV >>> >>> Mobiel: +31 (0) 626 014541 >>> >> >> >> >> > -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
