You are welcome ;) Regards JB
On Thu, Mar 10, 2022 at 3:47 PM Bengt Rodehav <be...@rodehav.com> wrote: > Tried your advise and it worked perfectly - thanks! > > /Bengt > > Den tors 10 mars 2022 kl 09:16 skrev Bengt Rodehav <be...@rodehav.com>: > >> Sorry, just saw that you answered how to provide capability via the >> feature - will try that. >> >> /Bengt >> >> Den tors 10 mars 2022 kl 09:06 skrev Bengt Rodehav <be...@rodehav.com>: >> >>> Thanks a lot JB - this really helps! >>> >>> Do you also know if it is possible to make pax-jdbc generate the >>> corresponding "provides"? Otherwise I might do as you suggest and disable >>> the capabilities. >>> >>> /Bengt >>> >>> Den ons 9 mars 2022 kl 21:02 skrev Jean-Baptiste Onofré <j...@nanthrax.net >>> >: >>> >>>> Exactly: maven-bundle-plugin 2.3.7 doesn't generate the >>>> Requirement/Capability headers. That's why it works. If you deploy your >>>> bundles built with this version, you won't have the problem. >>>> >>>> maven-bundle-plugin 5.1.4 generates the req/cap headers, used by the >>>> features service. If you want, you can disable req/cap headers generation. >>>> Just pass the following instructions to maven-bundle-plugin: >>>> >>>> <_norequirements>true</_norequirements> >>>> <_nocapabilities>true</_nocapabilities> >>>> >>>> So, it's what I said in my previous email: it's not related directly to >>>> Karaf (Karaf features resolver use req/cap since Karaf 4.2.x), it's because >>>> your bundles MANIFEST have changed (when you upgraded the >>>> maven-bundle-plugin version). >>>> >>>> Regards >>>> JB >>>> >>>> On Wed, Mar 9, 2022 at 8:37 PM Bengt Rodehav <be...@rodehav.com> wrote: >>>> >>>>> Aha - thanks a lot. I thought I was goin crazy. I use pax-jdbc for the >>>>> data source. I'll need to check if it can provide the capability. Or, >>>>> maybe >>>>> the problem is in the other end. I updated to a newer version of maven >>>>> bundle plugin (from 2.3.7 to 5.1.4) - maybe the old one didn't require the >>>>> capability. >>>>> >>>>> /Bengt >>>>> >>>>> On Wed, 9 Mar 2022, 18:27 Jean-Baptiste Onofré, <j...@nanthrax.net> >>>>> wrote: >>>>> >>>>>> No, you didn't get my point. >>>>>> >>>>>> The fact the datasource is there or not doesn't matter at runtime if >>>>>> it doesn't provide the capability. >>>>>> >>>>>> Let me explain. >>>>>> >>>>>> Your bundles history-stuff contains in META-INF/MANIFEST: >>>>>> >>>>>> Require-Capability: >>>>>> osgi.service;effective:=active;objectClass="javax.sql.DataSource";filter=.... >>>>>> >>>>>> When you install with bundle:install, this header is simply ignored. >>>>>> >>>>>> BUT, when you install using features service, the feature resolver >>>>>> check all bundles requirements/capabilities. >>>>>> >>>>>> So, the feature resolver is looking for: >>>>>> - a bundle containing Provide-Capability header in MANIFEST >>>>>> matching the requirement >>>>>> - a feature containing <capability/> matching the requirement >>>>>> >>>>>> It's nothing related to runtime (the actual bundle installed and >>>>>> running), only the MANIFEST cap/req matter; >>>>>> >>>>>> So, in your case, you can just provide the capability in the feature >>>>>> providing the datasource. It's exactly what you can see in the >>>>>> karaf-jpa-example: >>>>>> https://github.com/apache/karaf/blob/main/examples/karaf-jpa-example/karaf-jpa-example-features/src/main/feature/feature.xml#L28 >>>>>> >>>>>> Regards >>>>>> JB >>>>>> >>>>>> On Wed, Mar 9, 2022 at 5:30 PM Bengt Rodehav <be...@rodehav.com> >>>>>> wrote: >>>>>> >>>>>>> But the filetransfoerhistoryjta datasource is there. I've verified >>>>>>> that. And if I install the bundle directly instead of going through the >>>>>>> feature it works fine and connects to the datasource. Why can it not be >>>>>>> found when I go through the feature but when I install the bundle >>>>>>> directly? >>>>>>> >>>>>>> /Bengt >>>>>>> >>>>>>> Den ons 9 mars 2022 kl 17:10 skrev Jean-Baptiste Onofré < >>>>>>> j...@nanthrax.net>: >>>>>>> >>>>>>>> I don't think anything changed on the resolver, maybe you updated >>>>>>>> maven-bundle-plugin or bnd to create your bundle, and now it includes >>>>>>>> the >>>>>>>> requirement (whereas your bundles didn't contain requirement in >>>>>>>> MANIFEST >>>>>>>> before). >>>>>>>> >>>>>>>> On Wed, Mar 9, 2022 at 4:59 PM Bengt Rodehav <be...@rodehav.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I didn't have any problems with this using Karaf 4.3.3. Do you >>>>>>>>> know if something has changed? I'm using Karaf 4.3.6 now. >>>>>>>>> >>>>>>>>> /Bengt >>>>>>>>> >>>>>>>>> Den ons 9 mars 2022 kl 16:46 skrev Bengt Rodehav < >>>>>>>>> be...@rodehav.com>: >>>>>>>>> >>>>>>>>>> Is there any way to stop the feature installer from using the >>>>>>>>>> resolver? >>>>>>>>>> >>>>>>>>>> /Bengt >>>>>>>>>> >>>>>>>>>> Den ons 9 mars 2022 kl 16:37 skrev Bengt Rodehav < >>>>>>>>>> be...@rodehav.com>: >>>>>>>>>> >>>>>>>>>>> Unfortunately I didn't get any extra information. I got the same >>>>>>>>>>> as before which is: >>>>>>>>>>> >>>>>>>>>>> 2022-03-09T16:26:02,494 | INFO | pipe-feature:install -v >>>>>>>>>>> connect-filetransfer-history-db | FeaturesServiceImpl >>>>>>>>>>> | 18 - >>>>>>>>>>> org.apache.karaf.features.core - 4.3.6 | Adding features: >>>>>>>>>>> connect-filetransfer-history-db/[3.1.0.SNAPSHOT,3.1.0.SNAPSHOT] >>>>>>>>>>> 2022-03-09T16:26:02,901 | ERROR | Karaf local console user karaf >>>>>>>>>>> | ShellUtil | 70 - >>>>>>>>>>> org.apache.karaf.shell.core - >>>>>>>>>>> 4.3.6 | Exception caught while executing command >>>>>>>>>>> org.apache.felix.resolver.reason.ReasonException: Unable to >>>>>>>>>>> resolve root: missing requirement [root] osgi.identity; >>>>>>>>>>> osgi.identity=connect-filetransfer-history-db; type=karaf.feature; >>>>>>>>>>> version="[3.1.0.SNAPSHOT,3.1.0.SNAPSHOT]"; >>>>>>>>>>> filter:="(&(osgi.identity=connect-filetransfer-history-db)(type=karaf.feature)(version>=3.1.0.SNAPSHOT)(version<=3.1.0.SNAPSHOT))" >>>>>>>>>>> [caused by: Unable to resolve >>>>>>>>>>> connect-filetransfer-history-db/3.1.0.SNAPSHOT: missing requirement >>>>>>>>>>> [connect-filetransfer-history-db/3.1.0.SNAPSHOT] osgi.identity; >>>>>>>>>>> osgi.identity=se.digia.connect.services.filetransfer.history-domain; >>>>>>>>>>> type=osgi.bundle; version="[3.1.0.SNAPSHOT,3.1.0.SNAPSHOT]"; >>>>>>>>>>> resolution:=mandatory [caused by: Unable to resolve >>>>>>>>>>> se.digia.connect.services.filetransfer.history-domain/3.1.0.SNAPSHOT: >>>>>>>>>>> missing requirement >>>>>>>>>>> [se.digia.connect.services.filetransfer.history-domain/3.1.0.SNAPSHOT] >>>>>>>>>>> osgi.service; objectClass=javax.sql.DataSource; effective:=active; >>>>>>>>>>> filter:="(osgi.jndi.service.name=jdbc/filetransferhistoryjta)"]] >>>>>>>>>>> at >>>>>>>>>>> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> at >>>>>>>>>>> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:433) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> at >>>>>>>>>>> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:420) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> at >>>>>>>>>>> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:374) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> at >>>>>>>>>>> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> at >>>>>>>>>>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:399) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> at >>>>>>>>>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1069) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> at >>>>>>>>>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:264) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> at >>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> at >>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> at java.lang.Thread.run(Thread.java:833) [?:?] >>>>>>>>>>> Caused by: org.apache.felix.resolver.reason.ReasonException: >>>>>>>>>>> Unable to resolve connect-filetransfer-history-db/3.1.0.SNAPSHOT: >>>>>>>>>>> missing >>>>>>>>>>> requirement [connect-filetransfer-history-db/3.1.0.SNAPSHOT] >>>>>>>>>>> osgi.identity; >>>>>>>>>>> osgi.identity=se.digia.connect.services.filetransfer.history-domain; >>>>>>>>>>> type=osgi.bundle; version="[3.1.0.SNAPSHOT,3.1.0.SNAPSHOT]"; >>>>>>>>>>> resolution:=mandatory [caused by: Unable to resolve >>>>>>>>>>> se.digia.connect.services.filetransfer.history-domain/3.1.0.SNAPSHOT: >>>>>>>>>>> missing requirement >>>>>>>>>>> [se.digia.connect.services.filetransfer.history-domain/3.1.0.SNAPSHOT] >>>>>>>>>>> osgi.service; objectClass=javax.sql.DataSource; effective:=active; >>>>>>>>>>> filter:="(osgi.jndi.service.name=jdbc/filetransferhistoryjta)"] >>>>>>>>>>> at >>>>>>>>>>> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> ... 12 more >>>>>>>>>>> Caused by: org.apache.felix.resolver.reason.ReasonException: >>>>>>>>>>> Unable to resolve >>>>>>>>>>> se.digia.connect.services.filetransfer.history-domain/3.1.0.SNAPSHOT: >>>>>>>>>>> missing requirement >>>>>>>>>>> [se.digia.connect.services.filetransfer.history-domain/3.1.0.SNAPSHOT] >>>>>>>>>>> osgi.service; objectClass=javax.sql.DataSource; effective:=active; >>>>>>>>>>> filter:="(osgi.jndi.service.name=jdbc/filetransferhistoryjta)" >>>>>>>>>>> at >>>>>>>>>>> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> at >>>>>>>>>>> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) >>>>>>>>>>> ~[?:?] >>>>>>>>>>> ... 12 more >>>>>>>>>>> >>>>>>>>>>> I tried the "--store" option which gave me a quite large file >>>>>>>>>>> that I unfortunately did not understand fully. Not sure if it helps >>>>>>>>>>> any. >>>>>>>>>>> >>>>>>>>>>> /Bengt >>>>>>>>>>> >>>>>>>>>>> Den ons 9 mars 2022 kl 16:22 skrev Bengt Rodehav < >>>>>>>>>>> be...@rodehav.com>: >>>>>>>>>>> >>>>>>>>>>>> OK - thanks. Will try that. >>>>>>>>>>>> >>>>>>>>>>>> /Bengt >>>>>>>>>>>> >>>>>>>>>>>> Den ons 9 mars 2022 kl 16:16 skrev Jean-Baptiste Onofré < >>>>>>>>>>>> j...@nanthrax.net>: >>>>>>>>>>>> >>>>>>>>>>>>> Hi >>>>>>>>>>>>> >>>>>>>>>>>>> The main difference is that feature used the resolver to >>>>>>>>>>>>> optimize the installation. Bundle installation doesn’t use the >>>>>>>>>>>>> feature >>>>>>>>>>>>> resolver. >>>>>>>>>>>>> >>>>>>>>>>>>> You can use feature:install -v to get resolver output and you >>>>>>>>>>>>> will probably see the chain found by the resolver. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> JB >>>>>>>>>>>>> >>>>>>>>>>>>> Le mer. 9 mars 2022 à 15:22, Bengt Rodehav <be...@rodehav.com> >>>>>>>>>>>>> a écrit : >>>>>>>>>>>>> >>>>>>>>>>>>>> I have a very strange problem (in Karaf 4.3.6). I use JPA and >>>>>>>>>>>>>> have a bundle containing a persistence.xml in which a datasource >>>>>>>>>>>>>> is >>>>>>>>>>>>>> referenced: >>>>>>>>>>>>>> >>>>>>>>>>>>>> <jta-data-source>osgi:service/javax.sql.DataSource/( >>>>>>>>>>>>>> osgi.jndi.service.name >>>>>>>>>>>>>> =jdbc/filetransferhistoryjta)</jta-data-source> >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the datasource is not available when I install this bundle >>>>>>>>>>>>>> then I will get an error complaining that the datasource is not >>>>>>>>>>>>>> present. >>>>>>>>>>>>>> The strange thing is that it seems to be dependent on how I >>>>>>>>>>>>>> install this >>>>>>>>>>>>>> bundle - directly installing the bundle or doing it via a >>>>>>>>>>>>>> feature. In the >>>>>>>>>>>>>> first case it works but in the latter it doesn't. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If I first install all the prerequisites I need and then >>>>>>>>>>>>>> issue the following command in the Karaf shell: >>>>>>>>>>>>>> >>>>>>>>>>>>>> bundle:install -s >>>>>>>>>>>>>> mvn:se.digia.connect.services.filetransfer/history-domain/3.1-SNAPSHOT >>>>>>>>>>>>>> >>>>>>>>>>>>>> Then it works fine. It even works if I remove the "-s" and >>>>>>>>>>>>>> start the bundle afterwards instead. >>>>>>>>>>>>>> >>>>>>>>>>>>>> However, if I use the following feature: >>>>>>>>>>>>>> >>>>>>>>>>>>>> <feature name="connect-filetransfer-history-db" >>>>>>>>>>>>>> version="3.1-SNAPSHOT"> >>>>>>>>>>>>>> >>>>>>>>>>>>>> <bundle>mvn:se.digia.connect.services.filetransfer/history-domain/3.1-SNAPSHOT</bundle> >>>>>>>>>>>>>> </feature> >>>>>>>>>>>>>> >>>>>>>>>>>>>> And then issue the following command: >>>>>>>>>>>>>> >>>>>>>>>>>>>> feature:install connect-filetransfer-history-db >>>>>>>>>>>>>> >>>>>>>>>>>>>> Then the datasource cannot be found and the install fails. >>>>>>>>>>>>>> This happens consistently. I am using Pax-Jdbc for exposing the >>>>>>>>>>>>>> datasource >>>>>>>>>>>>>> via JNDI. >>>>>>>>>>>>>> >>>>>>>>>>>>>> First I thought that there might be a timing problem and that >>>>>>>>>>>>>> you have to wait a while to get the datasource published but it >>>>>>>>>>>>>> doesn't >>>>>>>>>>>>>> seem to have anything to do with that at all. I can wait 5 >>>>>>>>>>>>>> minutes after >>>>>>>>>>>>>> installing the datasource. I also check with the command >>>>>>>>>>>>>> "jndi:names" that >>>>>>>>>>>>>> it is published. But it still doesn't work using a feature. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can anyone tell me what is being done differently when I use >>>>>>>>>>>>>> a feature compared to when I just install the bundle directly? >>>>>>>>>>>>>> There is >>>>>>>>>>>>>> apparently some kind of difference. >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Bengt >>>>>>>>>>>>>> >>>>>>>>>>>>>>
