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
>>>>>>>>>>>
>>>>>>>>>>>

Reply via email to