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
