Hello 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 ??? >
I'd personally not mix "bundle requirements" with "service requirements". In my opinion, bundle should not be unresolved just because one service is missing - OSGi services may come and go... But others may have different opinion... About the capabilities you used: > <capability>osgi.service;objectClass=javax.jdbc.DataSource);effective:=active</capability> > > <capability>osgi.service;objectClass=javax.jdbc.XADataSource);effective:=active</capability> > These effectively mean that your "my-test-26-karaf-s-db" Karaf feature "provides data sources" - without specifying their names... That's bringing effectively zero information (IMO)... I simply wouldn't treat <_removeheaders>Import-Service</_removeheaders> as dirty hack ;) regards Grzegorz Grzybek pt., 21 paź 2022 o 13:51 Ephemeris Lappis <[email protected]> napisał(a): > 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 >
