You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Daniel McGreal <d....@gmail.com> on 2016/02/28 22:15:23 UTC
OSGi Compendium within a feature restarts the console
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.
Re: OSGi Compendium within a feature restarts the console
Posted by Daniel McGreal <d....@gmail.com>.
Aha, I need to pay more attention to the OSGi blogs.
Thanks Markus.
> On 29 Feb 2016, at 17:20, Markus Rathgeb <ma...@gmail.com> 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 <bc...@googlemail.com>:
>> 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 <d....@gmail.com>:
>>>
>>> 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
>>
Re: OSGi Compendium within a feature restarts the console
Posted by ch...@kiffer.ltd.uk.
When I write an application in C that will run on a POSIX system, I import
header files (APIs) into my code with #include; I don't import the
implementation from glibc or whatever. If I or anyone else wants to run
the code, they need to have the libraries installed but they don't need
the headers. I have worked this way for more than 30 years because it is
the only sane way to program in C, but for some reason Java developers
still seem to find it a strange concept.
Compile against the interface. Run against an implementation. You know
it makes sense.
> Personally, I implement my own BundleInfo to represent bundles installed
> in a distributed system.
>
>> On 29 Feb 2016, at 17:57, David Jencks <da...@gmail.com> wrote:
>>
>> Sure, but I canât imagine any such use case. I can imagine using the
>> little bundles at compile time to make sure you know which specs you
>> depend on, but Iâm mystified how this could be useful at runtime.
>>
>> david jencks
>>
>>> On Feb 29, 2016, at 9:51 AM, Daniel McGreal <d....@gmail.com>
>>> wrote:
>>>
>>> I think he means (which is actually aligned with my use case) that I
>>> can use the classes from the spec this way, when I donât need an
>>> implementation.
>>>
>>>> On 29 Feb 2016, at 17:49, David Jencks <da...@gmail.com>
>>>> 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 <ma...@gmail.com>
>>>>> 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 <bc...@googlemail.com>:
>>>>>> 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 <d....@gmail.com>:
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>
>>>
>>
>
>
Re: OSGi Compendium within a feature restarts the console
Posted by Daniel McGreal <d....@gmail.com>.
Personally, I implement my own BundleInfo to represent bundles installed in a distributed system.
> On 29 Feb 2016, at 17:57, David Jencks <da...@gmail.com> wrote:
>
> Sure, but I can’t imagine any such use case. I can imagine using the little bundles at compile time to make sure you know which specs you depend on, but I’m mystified how this could be useful at runtime.
>
> david jencks
>
>> On Feb 29, 2016, at 9:51 AM, Daniel McGreal <d....@gmail.com> wrote:
>>
>> I think he means (which is actually aligned with my use case) that I can use the classes from the spec this way, when I don’t need an implementation.
>>
>>> On 29 Feb 2016, at 17:49, David Jencks <da...@gmail.com> 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 <ma...@gmail.com> 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 <bc...@googlemail.com>:
>>>>> 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 <d....@gmail.com>:
>>>>>>
>>>>>> 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
>>>>>
>>>
>>
>
Re: OSGi Compendium within a feature restarts the console
Posted by Christian Schneider <ch...@die-schneider.net>.
For jpa and jdbc we already use the new spec packages. Aries JPA and pax
jdbc use these bundles in their respective features.
Christian
2016-03-01 14:18 GMT+01:00 Mike Rumpf <mi...@gmx.de>:
> Fair enough for ds. But in the case of the jpa/jdbc packages it really
> depends on the implementation though. For my setup the jdbc package (namely
> the DataSourceFactory class) is not provided by the service provider sadly.
> So I have to rely on the designated bundle.
>
> Mike
>
>
> Guillaume Nodet-2 wrote
> > You may want to not align compile time dependencies (the maven deps) with
> > the runtime dependencies (bundles listed in features).
> > You can safely depend on the overall compendium jar at build time, this
> > can
> > ease the build a bit.
> > At runtime, you should depend on a feature which will provide the DS
> > implementation and packages.
> >
> > 2016-03-01 13:52 GMT+01:00 Mike Rumpf <
>
> > mikey99@
>
> > >:
> >
> >> Of course I read that before. However for development you will need the
> >> ds
> >> annotation classes which are not part of the scr bundle. You will nee
> the
> >> part of the compendium bundle to make it work.
> >>
> >> I just configured a JPA/JDBC for hibernate/postgres solution in karaf.
> >> The
> >> same applies here: I needed the jdbc/jpa parts from the compendium as
> >> well.
> >> In the past we provided manually created osgi jdbc/jpa bundles with the
> >> interfaces. Nice to have them now at maven central.
> >>
> >> But maybe I am missing something. Is there a way to avoid using them?
> >>
> >> Mike
> >>
> >>
> >> maggu2810 wrote
> >> > Have you read this one:
> >> >
> >>
> http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html#should-a-service-providerconsumer-bundle-be-packaged-with-its-service-api-packages
> >> > Christian Schneider posted the link already above
> >> >
> >> > If you have a look at
> >> >
> >>
> http://search.maven.org/remotecontent?filepath=org/apache/felix/org.apache.felix.scr/1.8.2/org.apache.felix.scr-1.8.2.jar
> >> > you will see, that this bundle contains the OSGi service interfaces.
> >> > If you have a look at
> >> >
> >>
> http://build.eclipse.org/rt/virgo/ivy/bundles/release/org.eclipse.virgo.mirrored/org.eclipse.equinox.ds/1.4.200.v20131126-2331/org.eclipse.equinox.ds-1.4.200.v20131126-2331.jar
> >> > you will see, that this bundle does not contain the OSGi service
> >> > interfaces.
> >> >
> >> > 2016-03-01 13:17 GMT+01:00 Mike Rumpf <
> >>
> >> > mikey99@
> >>
> >> > >:
> >> >> maggu2810 wrote
> >> >>> It has been some time ago, I had to use the Equinox Event Admin and
> >> DS
> >> >>> implementation.
> >> >>> That bundles (I have not checked other versions) missing the APIs -
> >> >>> they contain only the implementation. So I have to create a splitted
> >> >>> compendium myself to get them working in Karaf.
> >> >>> I read this blog and I am fine, that such packages exist.
> >> >>>
> >> >>> I do not see a use case for interfaces without implementations.
> >> >>>
> >> >>> But hey, it is up to you how you use this artifacts.
> >> >>
> >> >> Isn't that still valid? The OSGi JPA/JDBC interfaces are only
> >> available
> >> >> in
> >> >> the respective osgi interface bundles as linked in the blog. As far
> as
> >> I
> >> >> know there is no apache felix bundle to provide the service interface
> >> >> classes. Same goes with the OSGi ds annotation classes. Therefore the
> >> >> bundles listed in the blog are very helpful. However the JPA bundle
> >> has
> >> a
> >> >> dependency to javax.persistence [1.1,2) which cannot be resolved
> >> >> easily...
> >> >> Seems to be a bug.
> >> >>
> >> >> Mike
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://karaf.922171.n3.nabble.com/OSGi-Compendium-within-a-feature-restarts-the-console-tp4045606p4045643.html
> >> >> Sent from the Karaf - User mailing list archive at Nabble.com.
> >>
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://karaf.922171.n3.nabble.com/OSGi-Compendium-within-a-feature-restarts-the-console-tp4045606p4045645.html
> >> Sent from the Karaf - User mailing list archive at Nabble.com.
> >>
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Red Hat, Open Source Integration
> >
> > Email:
>
> > gnodet@
>
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
>
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/OSGi-Compendium-within-a-feature-restarts-the-console-tp4045606p4045647.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: OSGi Compendium within a feature restarts the console
Posted by Mike Rumpf <mi...@gmx.de>.
Fair enough for ds. But in the case of the jpa/jdbc packages it really
depends on the implementation though. For my setup the jdbc package (namely
the DataSourceFactory class) is not provided by the service provider sadly.
So I have to rely on the designated bundle.
Mike
Guillaume Nodet-2 wrote
> You may want to not align compile time dependencies (the maven deps) with
> the runtime dependencies (bundles listed in features).
> You can safely depend on the overall compendium jar at build time, this
> can
> ease the build a bit.
> At runtime, you should depend on a feature which will provide the DS
> implementation and packages.
>
> 2016-03-01 13:52 GMT+01:00 Mike Rumpf <
> mikey99@
> >:
>
>> Of course I read that before. However for development you will need the
>> ds
>> annotation classes which are not part of the scr bundle. You will nee the
>> part of the compendium bundle to make it work.
>>
>> I just configured a JPA/JDBC for hibernate/postgres solution in karaf.
>> The
>> same applies here: I needed the jdbc/jpa parts from the compendium as
>> well.
>> In the past we provided manually created osgi jdbc/jpa bundles with the
>> interfaces. Nice to have them now at maven central.
>>
>> But maybe I am missing something. Is there a way to avoid using them?
>>
>> Mike
>>
>>
>> maggu2810 wrote
>> > Have you read this one:
>> >
>> http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html#should-a-service-providerconsumer-bundle-be-packaged-with-its-service-api-packages
>> > Christian Schneider posted the link already above
>> >
>> > If you have a look at
>> >
>> http://search.maven.org/remotecontent?filepath=org/apache/felix/org.apache.felix.scr/1.8.2/org.apache.felix.scr-1.8.2.jar
>> > you will see, that this bundle contains the OSGi service interfaces.
>> > If you have a look at
>> >
>> http://build.eclipse.org/rt/virgo/ivy/bundles/release/org.eclipse.virgo.mirrored/org.eclipse.equinox.ds/1.4.200.v20131126-2331/org.eclipse.equinox.ds-1.4.200.v20131126-2331.jar
>> > you will see, that this bundle does not contain the OSGi service
>> > interfaces.
>> >
>> > 2016-03-01 13:17 GMT+01:00 Mike Rumpf <
>>
>> > mikey99@
>>
>> > >:
>> >> maggu2810 wrote
>> >>> It has been some time ago, I had to use the Equinox Event Admin and
>> DS
>> >>> implementation.
>> >>> That bundles (I have not checked other versions) missing the APIs -
>> >>> they contain only the implementation. So I have to create a splitted
>> >>> compendium myself to get them working in Karaf.
>> >>> I read this blog and I am fine, that such packages exist.
>> >>>
>> >>> I do not see a use case for interfaces without implementations.
>> >>>
>> >>> But hey, it is up to you how you use this artifacts.
>> >>
>> >> Isn't that still valid? The OSGi JPA/JDBC interfaces are only
>> available
>> >> in
>> >> the respective osgi interface bundles as linked in the blog. As far as
>> I
>> >> know there is no apache felix bundle to provide the service interface
>> >> classes. Same goes with the OSGi ds annotation classes. Therefore the
>> >> bundles listed in the blog are very helpful. However the JPA bundle
>> has
>> a
>> >> dependency to javax.persistence [1.1,2) which cannot be resolved
>> >> easily...
>> >> Seems to be a bug.
>> >>
>> >> Mike
>> >>
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://karaf.922171.n3.nabble.com/OSGi-Compendium-within-a-feature-restarts-the-console-tp4045606p4045643.html
>> >> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/OSGi-Compendium-within-a-feature-restarts-the-console-tp4045606p4045645.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email:
> gnodet@
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
--
View this message in context: http://karaf.922171.n3.nabble.com/OSGi-Compendium-within-a-feature-restarts-the-console-tp4045606p4045647.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: OSGi Compendium within a feature restarts the console
Posted by Guillaume Nodet <gn...@apache.org>.
You may want to not align compile time dependencies (the maven deps) with
the runtime dependencies (bundles listed in features).
You can safely depend on the overall compendium jar at build time, this can
ease the build a bit.
At runtime, you should depend on a feature which will provide the DS
implementation and packages.
2016-03-01 13:52 GMT+01:00 Mike Rumpf <mi...@gmx.de>:
> Of course I read that before. However for development you will need the ds
> annotation classes which are not part of the scr bundle. You will nee the
> part of the compendium bundle to make it work.
>
> I just configured a JPA/JDBC for hibernate/postgres solution in karaf. The
> same applies here: I needed the jdbc/jpa parts from the compendium as well.
> In the past we provided manually created osgi jdbc/jpa bundles with the
> interfaces. Nice to have them now at maven central.
>
> But maybe I am missing something. Is there a way to avoid using them?
>
> Mike
>
>
> maggu2810 wrote
> > Have you read this one:
> >
> http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html#should-a-service-providerconsumer-bundle-be-packaged-with-its-service-api-packages
> > Christian Schneider posted the link already above
> >
> > If you have a look at
> >
> http://search.maven.org/remotecontent?filepath=org/apache/felix/org.apache.felix.scr/1.8.2/org.apache.felix.scr-1.8.2.jar
> > you will see, that this bundle contains the OSGi service interfaces.
> > If you have a look at
> >
> http://build.eclipse.org/rt/virgo/ivy/bundles/release/org.eclipse.virgo.mirrored/org.eclipse.equinox.ds/1.4.200.v20131126-2331/org.eclipse.equinox.ds-1.4.200.v20131126-2331.jar
> > you will see, that this bundle does not contain the OSGi service
> > interfaces.
> >
> > 2016-03-01 13:17 GMT+01:00 Mike Rumpf <
>
> > mikey99@
>
> > >:
> >> maggu2810 wrote
> >>> It has been some time ago, I had to use the Equinox Event Admin and DS
> >>> implementation.
> >>> That bundles (I have not checked other versions) missing the APIs -
> >>> they contain only the implementation. So I have to create a splitted
> >>> compendium myself to get them working in Karaf.
> >>> I read this blog and I am fine, that such packages exist.
> >>>
> >>> I do not see a use case for interfaces without implementations.
> >>>
> >>> But hey, it is up to you how you use this artifacts.
> >>
> >> Isn't that still valid? The OSGi JPA/JDBC interfaces are only available
> >> in
> >> the respective osgi interface bundles as linked in the blog. As far as I
> >> know there is no apache felix bundle to provide the service interface
> >> classes. Same goes with the OSGi ds annotation classes. Therefore the
> >> bundles listed in the blog are very helpful. However the JPA bundle has
> a
> >> dependency to javax.persistence [1.1,2) which cannot be resolved
> >> easily...
> >> Seems to be a bug.
> >>
> >> Mike
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://karaf.922171.n3.nabble.com/OSGi-Compendium-within-a-feature-restarts-the-console-tp4045606p4045643.html
> >> Sent from the Karaf - User mailing list archive at Nabble.com.
>
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/OSGi-Compendium-within-a-feature-restarts-the-console-tp4045606p4045645.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: OSGi Compendium within a feature restarts the console
Posted by Mike Rumpf <mi...@gmx.de>.
Of course I read that before. However for development you will need the ds
annotation classes which are not part of the scr bundle. You will nee the
part of the compendium bundle to make it work.
I just configured a JPA/JDBC for hibernate/postgres solution in karaf. The
same applies here: I needed the jdbc/jpa parts from the compendium as well.
In the past we provided manually created osgi jdbc/jpa bundles with the
interfaces. Nice to have them now at maven central.
But maybe I am missing something. Is there a way to avoid using them?
Mike
maggu2810 wrote
> Have you read this one:
> http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html#should-a-service-providerconsumer-bundle-be-packaged-with-its-service-api-packages
> Christian Schneider posted the link already above
>
> If you have a look at
> http://search.maven.org/remotecontent?filepath=org/apache/felix/org.apache.felix.scr/1.8.2/org.apache.felix.scr-1.8.2.jar
> you will see, that this bundle contains the OSGi service interfaces.
> If you have a look at
> http://build.eclipse.org/rt/virgo/ivy/bundles/release/org.eclipse.virgo.mirrored/org.eclipse.equinox.ds/1.4.200.v20131126-2331/org.eclipse.equinox.ds-1.4.200.v20131126-2331.jar
> you will see, that this bundle does not contain the OSGi service
> interfaces.
>
> 2016-03-01 13:17 GMT+01:00 Mike Rumpf <
> mikey99@
> >:
>> maggu2810 wrote
>>> It has been some time ago, I had to use the Equinox Event Admin and DS
>>> implementation.
>>> That bundles (I have not checked other versions) missing the APIs -
>>> they contain only the implementation. So I have to create a splitted
>>> compendium myself to get them working in Karaf.
>>> I read this blog and I am fine, that such packages exist.
>>>
>>> I do not see a use case for interfaces without implementations.
>>>
>>> But hey, it is up to you how you use this artifacts.
>>
>> Isn't that still valid? The OSGi JPA/JDBC interfaces are only available
>> in
>> the respective osgi interface bundles as linked in the blog. As far as I
>> know there is no apache felix bundle to provide the service interface
>> classes. Same goes with the OSGi ds annotation classes. Therefore the
>> bundles listed in the blog are very helpful. However the JPA bundle has a
>> dependency to javax.persistence [1.1,2) which cannot be resolved
>> easily...
>> Seems to be a bug.
>>
>> Mike
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/OSGi-Compendium-within-a-feature-restarts-the-console-tp4045606p4045643.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
--
View this message in context: http://karaf.922171.n3.nabble.com/OSGi-Compendium-within-a-feature-restarts-the-console-tp4045606p4045645.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: OSGi Compendium within a feature restarts the console
Posted by Markus Rathgeb <ma...@gmail.com>.
Have you read this one:
http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html#should-a-service-providerconsumer-bundle-be-packaged-with-its-service-api-packages
Christian Schneider posted the link already above
If you have a look at
http://search.maven.org/remotecontent?filepath=org/apache/felix/org.apache.felix.scr/1.8.2/org.apache.felix.scr-1.8.2.jar
you will see, that this bundle contains the OSGi service interfaces.
If you have a look at
http://build.eclipse.org/rt/virgo/ivy/bundles/release/org.eclipse.virgo.mirrored/org.eclipse.equinox.ds/1.4.200.v20131126-2331/org.eclipse.equinox.ds-1.4.200.v20131126-2331.jar
you will see, that this bundle does not contain the OSGi service
interfaces.
2016-03-01 13:17 GMT+01:00 Mike Rumpf <mi...@gmx.de>:
> maggu2810 wrote
>> It has been some time ago, I had to use the Equinox Event Admin and DS
>> implementation.
>> That bundles (I have not checked other versions) missing the APIs -
>> they contain only the implementation. So I have to create a splitted
>> compendium myself to get them working in Karaf.
>> I read this blog and I am fine, that such packages exist.
>>
>> I do not see a use case for interfaces without implementations.
>>
>> But hey, it is up to you how you use this artifacts.
>
> Isn't that still valid? The OSGi JPA/JDBC interfaces are only available in
> the respective osgi interface bundles as linked in the blog. As far as I
> know there is no apache felix bundle to provide the service interface
> classes. Same goes with the OSGi ds annotation classes. Therefore the
> bundles listed in the blog are very helpful. However the JPA bundle has a
> dependency to javax.persistence [1.1,2) which cannot be resolved easily...
> Seems to be a bug.
>
> Mike
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/OSGi-Compendium-within-a-feature-restarts-the-console-tp4045606p4045643.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
Re: OSGi Compendium within a feature restarts the console
Posted by Mike Rumpf <mi...@gmx.de>.
maggu2810 wrote
> It has been some time ago, I had to use the Equinox Event Admin and DS
> implementation.
> That bundles (I have not checked other versions) missing the APIs -
> they contain only the implementation. So I have to create a splitted
> compendium myself to get them working in Karaf.
> I read this blog and I am fine, that such packages exist.
>
> I do not see a use case for interfaces without implementations.
>
> But hey, it is up to you how you use this artifacts.
Isn't that still valid? The OSGi JPA/JDBC interfaces are only available in
the respective osgi interface bundles as linked in the blog. As far as I
know there is no apache felix bundle to provide the service interface
classes. Same goes with the OSGi ds annotation classes. Therefore the
bundles listed in the blog are very helpful. However the JPA bundle has a
dependency to javax.persistence [1.1,2) which cannot be resolved easily...
Seems to be a bug.
Mike
--
View this message in context: http://karaf.922171.n3.nabble.com/OSGi-Compendium-within-a-feature-restarts-the-console-tp4045606p4045643.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: OSGi Compendium within a feature restarts the console
Posted by Markus Rathgeb <ma...@gmail.com>.
It has been some time ago, I had to use the Equinox Event Admin and DS
implementation.
That bundles (I have not checked other versions) missing the APIs -
they contain only the implementation. So I have to create a splitted
compendium myself to get them working in Karaf.
I read this blog and I am fine, that such packages exist.
I do not see a use case for interfaces without implementations.
But hey, it is up to you how you use this artifacts.
Re: OSGi Compendium within a feature restarts the console
Posted by David Jencks <da...@gmail.com>.
Sure, but I can’t imagine any such use case. I can imagine using the little bundles at compile time to make sure you know which specs you depend on, but I’m mystified how this could be useful at runtime.
david jencks
> On Feb 29, 2016, at 9:51 AM, Daniel McGreal <d....@gmail.com> wrote:
>
> I think he means (which is actually aligned with my use case) that I can use the classes from the spec this way, when I don’t need an implementation.
>
>> On 29 Feb 2016, at 17:49, David Jencks <da...@gmail.com> 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 <ma...@gmail.com> 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 <bc...@googlemail.com>:
>>>> 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 <d....@gmail.com>:
>>>>>
>>>>> 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
>>>>
>>
>
Re: OSGi Compendium within a feature restarts the console
Posted by Daniel McGreal <d....@gmail.com>.
I think he means (which is actually aligned with my use case) that I can use the classes from the spec this way, when I don’t need an implementation.
> On 29 Feb 2016, at 17:49, David Jencks <da...@gmail.com> 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 <ma...@gmail.com> 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 <bc...@googlemail.com>:
>>> 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 <d....@gmail.com>:
>>>>
>>>> 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
>>>
>
Re: OSGi Compendium within a feature restarts the console
Posted by David Jencks <da...@gmail.com>.
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 <ch...@die-schneider.net> 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 <ma...@gmail.com> 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 <bc...@googlemail.com>:
>>>> 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 <d....@gmail.com>:
>>>>> 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
>
Re: OSGi Compendium within a feature restarts the console
Posted by Christian Schneider <ch...@die-schneider.net>.
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 <ma...@gmail.com> 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 <bc...@googlemail.com>:
>>> 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 <d....@gmail.com>:
>>>> 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
Re: OSGi Compendium within a feature restarts the console
Posted by David Jencks <da...@gmail.com>.
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 <ma...@gmail.com> 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 <bc...@googlemail.com>:
>> 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 <d....@gmail.com>:
>>>
>>> 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
>>
Re: OSGi Compendium within a feature restarts the console
Posted by Markus Rathgeb <ma...@gmail.com>.
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 <bc...@googlemail.com>:
> 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 <d....@gmail.com>:
>>
>> 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
>
Re: OSGi Compendium within a feature restarts the console
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <d....@gmail.com>:
> 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