Hello again :) ! Well, as you suggested, I've tested the "<_removeheaders>Import-Service</_removeheaders>", and it seems to work. I suppose that removing the service import from my manifest also remove the check from Karaf installer, and let my bundle starts. Whats strange is that the OSGi service resolution is still working for the different services that my bundle imports. An explanation perhaps ?
So I have now my DataSource feature with the desired blueprint (see attachment) and the following feature that declares dependencies for the DataSource wrapping : <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <features xmlns="http://karaf.apache.org/xmlns/features/v1.6.0"; name="my-test-26-karaf-s-db"> <feature name="my-test-26-karaf-s-db-cfg" description="Fifi-T26 :: DB Data Source - Configuration" version="0.0.1.SNAPSHOT"> <details>Fifi-T26 :: DB Data Source - Configuration</details> <configfile finalname="/etc/my_test_26_karaf_s_db.cfg">mvn:my.tests/my-test-26-karaf-s-db/0.0.1-SNAPSHOT/cfg/configuration</configfile> </feature> <feature name="my-test-26-karaf-s-db" description="Fifi-T26 :: DB" version="0.0.1.SNAPSHOT"> <details>Fifi-T26 :: DB Data Source</details> <feature version="0.0.1-SNAPSHOT" prerequisite="true">my-test-26-karaf-s-db-cfg</feature> <feature version="4.4.1" prerequisite="true">aries-blueprint</feature> <feature prerequisite="true">transaction</feature> <bundle>mvn:org.apache.aries.transaction/org.apache.aries.transaction.wrappers/1.0.0</bundle> <bundle>mvn:my.tests/my-test-26-karaf-s-db/0.0.1-SNAPSHOT</bundle> <bundle>mvn:org.postgresql/postgresql/42.4.2</bundle> <capability>osgi.service;objectClass=javax.jdbc.DataSource);effective:=active</capability> <capability>osgi.service;objectClass=javax.jdbc.XADataSource);effective:=active</capability> </feature> </features> When the feature is installed, the blueprint bundle creates the XADataSource, and then the wrapper takes the resulting service to expose a "XA aware" DataSource adding pooling and XA management. Then my Camel routes feature is installed with no missing requirement, and works... But I'm not sure this way is the best one. I'm going to look ahead for : - either manage my data sources according to your links and verify if it could be a valid solution but without any workaround about bundle headers (this headers removal seems to be some kind of lie about the bundle real requirements) - or find a way to tell Karaf how get the requirement another way from the wrapping service. Perhaps an opinion on these two alternative solutions ??? Thanks a lot. Regards. Le ven. 21 oct. 2022 à 11:45, Grzegorz Grzybek <[email protected]> a écrit : > > > > pt., 21 paź 2022 o 11:30 Ephemeris Lappis <[email protected]> > napisał(a): >> >> Hello again. >> >> Sorry for the last interrupted mail... >> >> For sure, this wrapping mechanism is a bit confusing. It was confusing >> for us too when we were working on it, long time ago, with Fuse (and >> ServiceMix too I think), looking for solutions to declare and use >> XADataSource while Camel components like SQL only accept simple >> DataSource. >> >> For Fuse, this page >> (https://access.redhat.com/documentation/en-us/red_hat_jboss_fuse/6.3/html/transaction_guide/xajdbc-autoenlist) >> explains how it works, and identifies the bundle that does the magic : >> org.apache.aries.transaction.wrappers. >> >> I don't know exactly how the bundle comes into play in Fuse 6.3 : >> indeed we declare dependencies only on features connector and >> transaction, and the wrapper creates our DataSource proxy... >> >> Your examples from Fuse 7 are interesting, but if I understand them, >> the XADataSource is used explicitly as is, and not throw a simple >> DataSource proxy that Camel components only accept. > > > https://github.com/jboss-fuse/karaf-quickstarts/blob/7.x.redhat-7-11-x/persistence/databases/blueprints/postgresql-pax-jdbc-discovery.xml > is indeed registering "Database-specific, non-pooling, non-enlisting > javax.sql.XADataSource" > which is then picked up by pax-jdbc-config - > https://github.com/ops4j/org.ops4j.pax.jdbc/blob/jdbc-1.5.4/pax-jdbc-config/src/main/java/org/ops4j/pax/jdbc/config/impl/Activator.java#L65-L70 > turning it into instances of org.ops4j.pax.jdbc.config.impl.DataSourceWrapper > when pax-jdbc-config tracks an instance of DataSourceFactory - > https://github.com/ops4j/org.ops4j.pax.jdbc/blob/jdbc-1.5.4/pax-jdbc-config/src/main/java/org/ops4j/pax/jdbc/config/impl/DataSourceWrapper.java#L101 > which are registered by for example pax-jdbc-pool-dbcp2 - > https://github.com/ops4j/org.ops4j.pax.jdbc/blob/jdbc-1.5.4/pax-jdbc-pool-dbcp2/src/main/java/org/ops4j/pax/jdbc/pool/dbcp2/impl/Activator.java#L43 > pax-jdbc-config creates DataSourceRegistrations - > https://github.com/ops4j/org.ops4j.pax.jdbc/blob/jdbc-1.5.4/pax-jdbc-config/src/main/java/org/ops4j/pax/jdbc/config/impl/DataSourceWrapper.java#L103-L107 > and finally real "DataSource" (not XADataSource) is registered - > https://github.com/ops4j/org.ops4j.pax.jdbc/blob/jdbc-1.5.4/pax-jdbc-config/src/main/java/org/ops4j/pax/jdbc/config/impl/DataSourceRegistration.java#L93 > > I know that this flow is not intuitive, but that's OSGi ;) What you > eventually get is an OSGi service with pooling, XA-enlisting "data source" > with interface of `javax.sql.DataSource`. > >> >> In our case, the same XADataSource is provided with its natural >> interface for the part of our code that needs it as is, and as the >> wrapping "XA aware" DataSource that handles automatic transaction >> enlistment when it's used in Camel. >> >> I can't find any example from my old works, but I think this feature >> was already used in old projects with ServiceMix. >> >> The question for me now, if I'm not wrong, is to find a way to make >> the Karaf feature resolver accept the wrapped service as a capability, >> or, at the opposite, avoid its checking to let it deploy and install >> our bundles that seem to be able to resolve the wrapping service (that >> what it does if the Camel bundle is already installed and the wrapper >> provides the service after ... > > > Did you try to add this to your maven-bundle-configuration to remove the > check during resolution? > > <_removeheaders>Import-Service</_removeheaders> > > it works for me... > > regards > Grzegorz Grzybek > >> >> >> Thanks again. >> >> Le ven. 21 oct. 2022 à 09:48, Grzegorz Grzybek <[email protected]> a >> écrit : >> > >> > Hello >> > >> > I'm a bit lost with this aries.transaction.wrapper - I never used it and >> > I'm not sure about its purpose... >> > >> > However, I can try with other source of examples. I know you're migrating >> > from Fuse 6 to Karaf, but let me show you something from Fuse 7 (which is >> > an evolution of Fuse 6 - without fabric8, but based on Karaf 4). There are >> > "karaf persistence quickstarts" here: >> > https://github.com/jboss-fuse/karaf-quickstarts/tree/7.x.redhat-7-11-x/persistence >> > I've investigated the scenarios related to JDBC, JMS and XA and you can >> > find there some readmes (see the "manual" folder) and example blueprints >> > (see "databases/blueprints"). I tried to put a lot of explanation >> > comments, so maybe you'll find them useful. >> > >> > I hope these help. There is even a camel-xa example (with JDBC/JPA and >> > JMS) - please check >> > https://github.com/jboss-fuse/karaf-quickstarts/tree/7.x.redhat-7-11-x/persistence/camel-xa >> > >> > regards >> > Grzegorz Grzybek >> > >> > pt., 21 paź 2022 o 09:38 Ephemeris Lappis <[email protected]> >> > napisał(a): >> >> >> >> Hello. >> >> >> >> I don't really understand how I can manage my XADataSource/DataSource >> >> with this example, and I think the resolution exception comes from >> >> another reason. >> >> >> >> I think I've not been very clear at all... I'm going to try to do it >> >> now... >> >> >> >> In a first step of my tests, I had two features : >> >> - one to create a javax.PostgreSQL sql.DataSource (bundle with a >> >> single blueprint with a bean and a service declaration), and expose it >> >> as an OSGi service with its natural interface. The feature declares >> >> the capability >> >> "osgi.service;objectClass=javax.jdbc.DataSource);effective:=active". >> >> - another one with Camel routes (blueprint with a reference to a >> >> javax.sql.DataSource service, and Camel routes with the SQL >> >> component). >> >> >> >> When y install these two features, I understand that Karaf does the >> >> following actions : >> >> - the DataSource bundle is installed, its service is exposed, and the >> >> feature is registered for its capability. >> >> - as the Camel routes bundle needs the DataSource capability, Karaf >> >> checks it and finds successfully my previous feature as a good >> >> candidate, and the bundle is finally installed with ethe resolved >> >> services. My Camel routes get the expected javax.sql.DataSource object >> >> and all work as expected. >> >> >> >> A my new step of my tests, I have three features (that are directly >> >> implied in the issue) : >> >> - another feature that provides a JMS connection factory, using >> >> dependencies on ActiveMQ client, and so on : no problem with this one. >> >> - a modified version of my PostgreSQL feature that now creates a >> >> XADataSource (same bundle with a new bean and a javax.sql.XADataSource >> >> service). I've added a bundle in the feature >> >> (mvn:org.apache.aries.transaction/org.apache.aries.transaction.wrappers/1.0.0) >> >> to handle the XADataSource wrapping. >> >> - a modified version of my Camel routes feature, adding a reference on >> >> the JMS connection factory (no problem with that), but still with the >> >> javax.sql.DataSource service reference, since the SQL component uses >> >> this type). Routes now are transacted and mix SQL and JMS operations. >> >> >> >> Now, when I install the features, I think that Karaf does that : >> >> - The JMS connection factory feature is installed >> >> - The PostgreSQL feature too, creating explicitly the >> >> javax.sql.XADataSource service and the wrapping javax.sql.DataSource >> >> using the xa.* properties set on my service declaration (I can really >> >> see the two services on the Karaf shell). >> >> - But when the Karaf resolver processes my Camel routes feature, it >> >> fails on the capability checking : the javax.sql.DataSource service is >> >> probably identified, but as it's not directly exposed by my feature >> >> and its declared capability, but by the wrapper, the resolution fails, >> >> and Karaf refuses to install the feature. >> >> >> >> I understand that the resolution exception is raised by the Karaf >> >> feature resolver, not by the OSGi service management. >> >> >> >> So I've tried that to confirm my understanding : >> >> - Install the first version of my javax.sql.DataSource feature >> >> - Install the second Camel routes (SQL+JMS) version feature : this >> >> works since both the capability and service checking are OK. In this >> >> case, the Camel routes bundle is installed, started, and the blueprint >> >> and routes are all working, but using a DataSource that is not XA. >> >> - Replace the DataSource feature with the second version, but without >> >> the wrapper : now I have an XADataSource. >> >> - When the Camel routes bundle is refreshed, it fails because no >> >> javax.sql.DataSource is found. >> >> - Install manually the wrapper bundle : it creates its >> >> javax.sql.DataSource proxy over my XADataSource, exposes the service. >> >> - The Camel routes bundle now resolves the javax.sql.DataSource >> >> service (OSGi level). >> >> - And the routes work, using now the "XA aware" proxy. >> >> >> >> I allow myself to add JB to the conversation (please forgive me), >> >> since he helped me some weeks ago on issues about the Karaf capability >> >> resolver. Perhaps JB should confirm my analysis of the observed >> >> behaviour, and propose some solution to manage these "double >> >> interfaces DataSource" that are needed for our Camel transacted >> >> routes... >> >> >> >> I'm not sure that the wrapper bundle I've used is the best way to >> >> manage my XA data sources. If a feature like the Fuse's connector >> >> exists with this wrapping mechanism, it could probably be a best >> >> solution. >> >> >> >> Thanks again for all your help. >> >> >> >> Regards. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Le ven. 21 oct. 2022 à 06:38, Grzegorz Grzybek <[email protected]> a >> >> écrit : >> >> > >> >> > Hello >> >> > >> >> > If you're moving from Fuse 6 to Karaf, you have to do few (or even >> >> > more) things manually - that's why Fuse 6 did it for you in the first >> >> > place ;) >> >> > >> >> > Karaf 4's approach to Data Sources is through much improved Pax JDBC >> >> > project and you should rather manage your data sources using >> >> > DataSourceFactory - that's standard OSGi service >> >> > (org.osgi.service.jdbc) implemented by Pax JDBC. Karaf manual provides >> >> > a link to examples: >> >> > https://github.com/apache/karaf/blob/main/examples/karaf-jdbc-example/README.md >> >> > >> >> > About "missing requirement [my-test-26-karaf-2-routes/0.0.1.SNAPSHOT] >> >> > osgi.service; effective:=active" that's (from my ~9 years experience >> >> > with OSGi) one of the most confusing and discouraging things in OSGi. >> >> > This is an error from "bundle resolver" which prevents resolving a >> >> > bundle because "a service" is not available. >> >> > What's wrong with this? because there are two "layers" or "spaces" >> >> > mixed - bundle (module) and a service. OSGi promises you that services >> >> > are highly dynamic, while bundles (modules) are more static. IMO >> >> > preventing a resolution of a bundle because a service is missing (I saw >> >> > cases that the service was being registered from this very bundle >> >> > itself!) is simply wrong. >> >> > >> >> > Fortunately maven-bundle-plugin (and bnd itself) has option to "fix" >> >> > this - I always use (especially for data source / JPA) bundles this >> >> > header: >> >> > >> >> > <_removeheaders>Import-Service</_removeheaders> >> >> > >> >> > this way, the bundle won't contain it and (OSGi) resolver won't >> >> > complain. >> >> > >> >> > regards >> >> > Grzegorz Grzybek >> >> > >> >> > czw., 20 paź 2022 o 19:28 Ephemeris Lappis <[email protected]> >> >> > napisał(a): >> >> >> >> >> >> Hello. >> >> >> >> >> >> We are working on an old Fuse 6.3, and my current work is about >> >> >> porting our works from Fuse to Karaf. >> >> >> >> >> >> So,yes, I'd like to manage my DB configurations using "off the self" >> >> >> features if possible, and avoid creating hybrid ones... >> >> >> >> >> >> Do you mean the bundle I've tested and seemed to work is not the good >> >> >> one, and I should use >> >> >> org.apache.aries.transaction:org.apache.aries.transaction.jdbc:2.1.3. >> >> >> >> >> >> On Karaf 4.4.1 the connector feature seems to be poor, and if I'm not >> >> >> wrong it doesn't provide this bundle : >> >> >> karaf@root()> feature:info connector >> >> >> Feature connector 3.1.1 >> >> >> Description: >> >> >> OSGi support for JCA Connector 1.6 >> >> >> Details: >> >> >> OSGi support for JCA Connector 1.6 >> >> >> Feature has no configuration >> >> >> Feature has no configuration files >> >> >> Feature depends on: >> >> >> transaction [2,3) >> >> >> Feature contains followed bundles: >> >> >> mvn:org.apache.geronimo.specs/geronimo-j2ee-connector_1.6_spec/1.0 >> >> >> mvn:org.apache.geronimo.specs/geronimo-validation_1.0_spec/1.1 >> >> >> mvn:org.apache.geronimo.components/geronimo-connector/3.1.4 >> >> >> Feature has no conditionals. >> >> >> >> >> >> What should I do : add a direct dependency on the bundle, look for a >> >> >> better feature ? >> >> >> >> >> >> What's strange, is that the bundle I found seemed to work when >> >> >> installing it manually on a karaf instance, but something is wrong >> >> >> when I add it as a dependency in my DB feature. The Camel routes >> >> >> bundle fails with that error : >> >> >> >> >> >> Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to >> >> >> resolve my-test-26-karaf-2-routes/0.0.1.SNAPSHOT: missing requirement >> >> >> [my-test-26-karaf-2-routes/0.0.1.SNAPSHOT] osgi.service; >> >> >> effective:=active; >> >> >> filter:="(&(objectClass=javax.sql.DataSource)(osgi.jndi.service.name=jdbc/fifi))" >> >> >> >> >> >> However, The 2 DataSource services are present, one with the >> >> >> javax.sql.DataSource interface and both with the right >> >> >> osgi.jndi.service.name=jdbc/fifi... >> >> >> >> >> >> Any idea ? >> >> >> >> >> >> Thanks for your help. >> >> >> >> >> >> Regards. >> >> >> >> >> >> >> >> >> Le jeu. 20 oct. 2022 à 17:57, Grzegorz Grzybek <[email protected]> >> >> >> a écrit : >> >> >> > >> >> >> > Hello >> >> >> > >> >> >> > >> >> >> > czw., 20 paź 2022 o 17:54 Ephemeris Lappis >> >> >> > <[email protected]> napisał(a): >> >> >> >> >> >> >> >> Hello again. >> >> >> >> >> >> >> >> Looking at my old Fuse installations I found that the bundle that >> >> >> >> wraps XADatasource services is >> >> >> >> "mvn:org.apache.aries.transaction/org.apache.aries.transaction.wrappers/1.0.0". >> >> >> >> Installing it manually, it seems to wrap my XADataSource into a >> >> >> >> simple >> >> >> >> "XA aware" DataSource. Now I can see the 2 services : >> >> >> > >> >> >> > >> >> >> > Which Fuse version do you mean? >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> [javax.sql.DataSource] >> >> >> >> ---------------------- >> >> >> >> aries.xa.aware = true >> >> >> >> aries.xa.name = xa-fifi >> >> >> >> aries.xa.pooling = true >> >> >> >> aries.xa.poolMaxSize = 10 >> >> >> >> aries.xa.poolMinSize = 3 >> >> >> >> datasource.name = postgresql-fifi >> >> >> >> osgi.jndi.service.name = jdbc/fifi >> >> >> >> osgi.service.blueprint.compname = dsBean >> >> >> >> service.bundleid = 124 >> >> >> >> service.id = 251 >> >> >> >> service.ranking = 1000 >> >> >> >> service.scope = singleton >> >> >> >> Provided by : >> >> >> >> Fifi-T26 :: DB (124) >> >> >> >> Used by: >> >> >> >> Fifi-T26 :: Camel (186) >> >> >> >> System Bundle (0) >> >> >> >> >> >> >> >> [javax.sql.XADataSource] >> >> >> >> ------------------------ >> >> >> >> aries.xa.name = xa-fifi >> >> >> >> aries.xa.pooling = true >> >> >> >> aries.xa.poolMaxSize = 10 >> >> >> >> aries.xa.poolMinSize = 3 >> >> >> >> datasource.name = postgresql-fifi >> >> >> >> osgi.jndi.service.name = jdbc/fifi >> >> >> >> osgi.service.blueprint.compname = dsBean >> >> >> >> service.bundleid = 124 >> >> >> >> service.id = 210 >> >> >> >> service.scope = bundle >> >> >> >> Provided by : >> >> >> >> Fifi-T26 :: DB (124) >> >> >> >> Used by: >> >> >> >> Fifi-T26 :: DB (124) >> >> >> >> System Bundle (0) >> >> >> >> >> >> >> >> And my Camel routes seem to get the expected DataSource and run as >> >> >> >> expected... at least for elementary tests. >> >> >> >> >> >> >> >> So, my question is now : Instead of setting this bundle as a >> >> >> >> dependency of my service feature, is there an existing Karaf feature >> >> >> >> that could be more suitable to be a dependency ? >> >> >> > >> >> >> > >> >> >> > In Fuse 6 there's "connector" feature: >> >> >> > >> >> >> > <feature name="connector" description="OSGi support for JCA >> >> >> > Connector 1.6" version="3.1.1" resolver="(obr)"> >> >> >> > <details>OSGi support for JCA Connector 1.6</details> >> >> >> > <feature version="[1.1,2)">transaction</feature> >> >> >> > <bundle >> >> >> > dependency="true">mvn:org.apache.geronimo.specs/geronimo-j2ee-connector_1.6_spec/1.0</bundle> >> >> >> > <bundle >> >> >> > dependency="true">mvn:javax.validation/validation-api/1.1.0.Final-redhat-1</bundle> >> >> >> > >> >> >> > <bundle>mvn:org.apache.geronimo.components/geronimo-connector/3.1.1</bundle> >> >> >> > <bundle >> >> >> > start-level="30">mvn:org.apache.aries.transaction/org.apache.aries.transaction.jdbc/2.1.3</bundle> >> >> >> > </feature> >> >> >> > >> >> >> > And the "wrapping" is done by org.apache.aries.transaction.jdbc. >> >> >> > >> >> >> > Are you thinking about configuring it correctly in Karaf or in Fuse? >> >> >> > >> >> >> > regards >> >> >> > Grzegorz Grzybek >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> Thanks again. >> >> >> >> >> >> >> >> Regards. >> >> >> >> >> >> >> >> >> >> >> >> Le jeu. 20 oct. 2022 à 14:46, Ephemeris Lappis >> >> >> >> <[email protected]> a écrit : >> >> >> >> > >> >> >> >> > Hello. >> >> >> >> > >> >> >> >> > I'm trying to configure a XADataSource exposed by a bundle and a >> >> >> >> > feature. (see the attachment). >> >> >> >> > >> >> >> >> > The bundle is a single blueprint that creates the PostgreSQL XA >> >> >> >> > DataSource and exposes it as a service. >> >> >> >> > >> >> >> >> > I set Aries XA properties to let Aries wrapping my datasource : I >> >> >> >> > hope >> >> >> >> > this works in my case. At the bundle level, >> >> >> >> > >> >> >> >> > The service appears like that : >> >> >> >> > [javax.sql.XADataSource] >> >> >> >> > ------------------------ >> >> >> >> > aries.xa.name = xa-fifi >> >> >> >> > aries.xa.pooling = true >> >> >> >> > aries.xa.poolMaxSize = 10 >> >> >> >> > aries.xa.poolMinSize = 3 >> >> >> >> > datasource.name = postgresql-fifi >> >> >> >> > osgi.jndi.service.name = jdbc/fifi >> >> >> >> > osgi.service.blueprint.compname = dsBean >> >> >> >> > service.bundleid = 124 >> >> >> >> > service.id = 210 >> >> >> >> > service.scope = bundle >> >> >> >> > Provided by : Fifi-T26 :: DB (124) >> >> >> >> > Used by: >> >> >> >> > System Bundle (0) >> >> >> >> > >> >> >> >> > My feature (see attachment), declares a non-XA DataSource >> >> >> >> > capability, >> >> >> >> > what is perhaps wrong... >> >> >> >> > <capability>osgi.service;objectClass=javax.jdbc.DataSource);effective:=active</capability> >> >> >> >> > >> >> >> >> > Should I declare a double capability with XADataSource ? >> >> >> >> > >> >> >> >> > But my Camel routes bundle references a jaxa.sql.DataSource >> >> >> >> > service >> >> >> >> > with the needed jndi name, but fails with this error message. >> >> >> >> > >> >> >> >> > Unable to start container for blueprint bundle >> >> >> >> > my-test-26-karaf-2-routes/0.0.1.SNAPSHOT due to unresolved >> >> >> >> > dependencies >> >> >> >> > [(&(osgi.jndi.service.name=jdbc/fifi)(objectClass=javax.sql.DataSource))] >> >> >> >> > >> >> >> >> > The same pattern works on Red-Hat Fuse with a XADataSource exposed >> >> >> >> > service and a DataSource reference in the routes bundles, because >> >> >> >> > Aries TM is wrapping the service to auto-enlist connections in JTA >> >> >> >> > transactions... >> >> >> >> > >> >> >> >> > What's wrong here ??? >> >> >> >> > Someone with any experience on transactions ? >> >> >> >> > >> >> >> >> > Thanks in advance. >> >> >> >> > >> >> >> >> > Regards. >> >> >> >> > >> >> >> >> > >> >> >> >> > I expect Aries to wrap ml
