Thanks Tim, That was very helpful and as I remembered it. I had this working quite some time ago but shelved it because I decided to just wait for R7 support in Karaf. Decided to move ahead with this change but ended up grabbing the wrong jar file I guess because it wanted JPA even though I didn’t.
Anyway, the issue I’m having now is trying to inject an @Reference to a JDBCConnectionProvider into my component. Per the Transaction Control 147.5.2.4 The JDBCConnectionProviderFactory The JDBCConnectionProvider may be provided as a service directly in the OSGi service registry, I’m pretty sure this is the way I did it previously and since the spec and OSGi jars haven’t changed I believe it’s on me. I thought using one of: conProvider.target = (databaseName=dbName) conProvider.target = (dataSourceName=ds/name) would work but no such luck. It’s definitely possible that I’m misremembering the details of this and have left something out that I did before as there have been a number of other changes since then. Regards, Scott From: Tim Ward <tim.w...@paremus.com> Sent: Tuesday, April 07, 2020 6:25 AM To: Leschke, Scott <slesc...@medline.com>; OSGi Developer Mail List <osgi-dev@mail.osgi.org> Cc: Markus Rathgeb <maggu2...@gmail.com> Subject: Re: [osgi-dev] Regarding Transaction Control Hi Scott, If you’re using JDBC you don’t really care about JPA. Therefore you should compile against the OSGi jar, but not worry about deploying it at runtime. Instead you can just deploy the Aries Transaction Control implementation (which includes a substitutable export of the Transaction Control API). I would suggest that you want to start by using tx-control-service-local<https://urldefense.com/v3/__https:/github.com/apache/aries-tx-control/tree/tx-control-1.0.1/tx-control-services/tx-control-service-local__;!!PoMpmxQzTok3!vfYoZjwajhz4OBP2gfqvCLtPVAbmJYHEWzRV5zJve8JmyDb9gQrQsI7R12pC9Qk$> and tx-control-provider-jdbc-local<https://urldefense.com/v3/__https:/github.com/apache/aries-tx-control/tree/tx-control-1.0.1/tx-control-providers/jdbc/tx-control-provider-jdbc-local__;!!PoMpmxQzTok3!vfYoZjwajhz4OBP2gfqvCLtPVAbmJYHEWzRV5zJve8JmyDb9gQrQsI7RokJbr-M$> at runtime. Now, the JPA dependency. The JPA (much like the servlet container) specification versioning policy is not done very well. Marketing versions have been used for the APIs despite the fact that backward compatibility has been maintained between versions. This breaks the cardinal rule of semantic versioning, which is that changes to the major version indicate breaking changes. In any event, there is a part of the transaction control specification (in this case the JPA resource provider) which provides EntityManager instances, coupling it to the JPA API (there is a similar coupling for the JDBC resource provider and javax.sql). The reason that the version range starts at 1.0 is not because the specification is old, but because all versions (back to 1.0) are supported. Unfortunately where JPA APIs have been versioned using their marketing versions (2.0, 2.1, 2.2) this means that they don’t match a version range of "[1,2)”. The general solution to this is to use the “osgi.contract” namespace<https://urldefense.com/v3/__https:/osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html*service.namespaces-osgi.contract.namespace__;Iw!!PoMpmxQzTok3!vfYoZjwajhz4OBP2gfqvCLtPVAbmJYHEWzRV5zJve8JmyDb9gQrQsI7Rwyfu3Co$> there is a contract name defined for JPA<https://urldefense.com/v3/__https:/www.osgi.org/portable-java-contract-definitions/__;!!PoMpmxQzTok3!vfYoZjwajhz4OBP2gfqvCLtPVAbmJYHEWzRV5zJve8JmyDb9gQrQsI7R1eoLCE4$>. This however needs API bundles that provide the contract... Please get in touch if you have more questions, All the best, Tim On 7 Apr 2020, at 05:57, Markus Rathgeb via osgi-dev <osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org>> wrote: As I am using OSGi for a lot of projects on a pure Maven build with the help of all the bnd maven plugins. For easily testing I used bndrun files. I don't want to create the set of bundles that are allowed to be used at runtime all the time and so I started to create pom files that contains all of them (one for bundles that are used at compile time and one for bundles that are potentially used at runtime). Using that approach my bnd application can depend on that runtime pom using scope "runtime" and could consume the specified artifacts to resolve its requirements. The runtime pom contains also the bundles that has been necessary for me to use transaction control, hibernate, ... If you want to have a look at: https://github.com/maggu2810/osgideps/blob/master/runtime/pom.xml<https://urldefense.com/v3/__https:/github.com/maggu2810/osgideps/blob/master/runtime/pom.xml__;!!PoMpmxQzTok3!vfYoZjwajhz4OBP2gfqvCLtPVAbmJYHEWzRV5zJve8JmyDb9gQrQsI7Ri4rnzkQ$> As you can see I used the following persistence API bundle: org.apache.aries.jpa.javax.persistence javax.persistence_2.1 2.7.0 _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev<https://urldefense.com/v3/__https:/mail.osgi.org/mailman/listinfo/osgi-dev__;!!PoMpmxQzTok3!vfYoZjwajhz4OBP2gfqvCLtPVAbmJYHEWzRV5zJve8JmyDb9gQrQsI7RMYiSoUk$>
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
