Well, I think the behavior when the api is embedded is what you specified and is correct. If you don’t want everything to recycle when spring is installed maybe you should have both optional and dynamic-import for the spring packages? Or put the spring related stuff in a separate bundle depending on both aries tx and spring? I really don’t think this is an argument for separating api and implementation. I could still be missing something here though….
david jencks > On Feb 29, 2016, at 11:09 AM, Christian Schneider <[email protected]> > wrote: > > The question if the spec packages should be included in the impl bundles or > not is highly disputed. See: > http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html > > > Before karaf 4 I recommended to people to embed the api packages that are > implemented in the impl bundle. > > In karaf 4 though this can cause severe problems. The reason is that the new > resolver will refresh bundles if optional dependencies are satisfied. > An example was the aries transaction manager bundle. It embedded the jta api > packages but also had an optional dependency on spring. > > So when you first installed the transaction feature the transaction manager > bundle was started. If you then install a spring feature the transaction > manager bundle is refreshed. > If it contains the jta api this causes all bundles to be refreshed too that > import the jta api packages. So this can cause a lot of bundles to be > restarted. Sometimes such refreshs cascaded to cause refreshs of almost all > bundles. This causes quite some instability .. especially if not all user > bundles are written to work with arbitrary restarts. > > A similar case was pax jdc and the osgi jdbc spec package. > > So what I did with transaction manager and some other cases is to deploy the > api packages spearately and remove the api packages from the impl bundles. > This reduced the karaf refresh a lot and made the system much more usable. > > In many cases it is still ok to embed the api packages needed but if you have > any optional dependencies you should deploy the api in a separate bundle. > As it is sometimes difficult to know if you will have optional dependencies I > now tend to always deploy the apis on their own. > > Christian > > On 29.02.2016 18:49, David Jencks wrote: >> As far as I’m concerned, these little bundles are there to make it easier >> for implementers of a particular spec to include that spec’s api in their >> implementation bundle. It doesn’t do you any good to include the api >> without an implementation at runtime. Thus, I think the quote below is >> highly misleading. >> >> david jencks >> >>> On Feb 29, 2016, at 9:20 AM, Markus Rathgeb <[email protected]> wrote: >>> >>> FYI >>> >>> "But what if you want to use the APIs at runtime? To support using the >>> APIs at runtime, OSGi has now made the companion code for individual >>> specifications available as individual companion code bundles." >>> http://blog.osgi.org/2015/08/more-jars-on-maven-central-and-jcenter.html >>> >>> 2016-02-29 8:40 GMT+01:00 Achim Nierbeck <[email protected]>: >>>> Hi >>>> >>>> it's a bad practice to provide the compendium or core osgi bundles, as >>>> those >>>> contain far more packages then required. >>>> Usually the services implementing those apis should provide the implemented >>>> services. As can be seen for eventadmin, >>>> configuration admin service and the http service in karaf. >>>> >>>> regards, Achim >>>> >>>> >>>> 2016-02-28 22:15 GMT+01:00 Daniel McGreal <[email protected]>: >>>>> Hi Karaf users! >>>>> >>>>> Installing the Compendium in a feature, e.g. with the following primitive >>>>> example, restarts the console, because dependent bundles refresh to wire >>>>> against it. >>>>> >>>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> >>>>> <features xmlns="http://karaf.apache.org/xmlns/features/v1.3.0"; >>>>> name="cmpn"> >>>>> <feature name="cmpn" description="cmpn" >>>>> version="2.5.0.BUILD-SNAPSHOT"> >>>>> <bundle>mvn:org.osgi/org.osgi.compendium/5.0.0</bundle> >>>>> </feature> >>>>> </features> >>>>> >>>>> This is causing me some problems, for example, after the shell restart >>>>> feature:(un)install commands result in an NPE. >>>>> >>>>> java.lang.NullPointerException >>>>> at >>>>> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[9:org.apache.karaf.features.core:4.0.4] >>>>> at >>>>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[9:org.apache.karaf.features.core:4.0.4] >>>>> at >>>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[9:org.apache.karaf.features.core:4.0.4] >>>>> at >>>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[9:org.apache.karaf.features.core:4.0.4] >>>>> at >>>>> java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60] >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60] >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60] >>>>> at java.lang.Thread.run(Thread.java:745)[:1.8.0_60] >>>>> >>>>> Is there a way to prevent this from happening? >>>>> >>>>> Best, Dan. >>>> >>>> >>>> >>>> -- >>>> >>>> Apache Member >>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & >>>> Project Lead >>>> blog <http://notizblog.nierbeck.de/> >>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>>> >>>> Software Architect / Project Manager / Scrum Master >>>> > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
