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