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 >
