Hi Scott, 

the real Tim will be able to give you the 'official answer' but I think you 
want some thing like 

protected Connection connection ; 
//protected JdbcTemplate jdbcTemplate ; 
//protected NamedParameterJdbcTemplate namedParameterJdbcTemplate ; 
protected JDBCConnectionProvider jDBCConnectionProvider ; 
protected TransactionControl txControl ; 

@Reference (target = "(dataSourceName=data_source_name)" ) 
public void setJDBCConnectionProvider(JDBCConnectionProvider 
jDBCConnectionProvider) { 
this . jDBCConnectionProvider = jDBCConnectionProvider; 
} 

@Reference 
public void setTxControl(TransactionControl txControl) { 
this . txControl = txControl; 
} 

@Activate 
public void activate() { 
connection = jDBCConnectionProvider .getResource( txControl ); 
// jdbcTemplate = new JdbcTemplate( new SingleConnectionDataSource( connection 
, false )); 
// namedParameterJdbcTemplate = new NamedParameterJdbcTemplate( new 
SingleConnectionDataSource( connection , false )); 
} 


and possibly a config file e.g. for xa would be some thing like 
org.apache.aries.tx.control.jdbc.xa-data_source_name .cfg 

osgi.local.enabled =true 
osgi.xa.enabled =false 
osgi.connection.min =5 
osgi.connection.max =5 
osgi.connection.timeout =300000 
aries.jdbc.property.names =user,password,url 
osgi.jdbc.driver.class =org.postgresql.Driver 
url =jdbc:postgresql://localhost:5432/xxxx 
databaseName =xxxx 
serverName =localhost 
portNumber =5432 
user = 
password = 
dataSourceName = data_source_name 

Regards, 

Tim Jones 



From: "Leschke, Scott via osgi-dev" <osgi-dev@mail.osgi.org> 
To: "Timothy Ward" <tim.w...@paremus.com>, "OSGi Developer Mail List" 
<osgi-dev@mail.osgi.org> 
Sent: Wednesday, 22 April, 2020 8:31:09 AM 
Subject: Re: [osgi-dev] Regarding Transaction Control 



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 [ 
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$
 | 
tx-control-service-local ] and [ 
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$
 | 
tx-control-provider-jdbc-local ] 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 [ 
https://urldefense.com/v3/__https:/osgi.org/specification/osgi.cmpn/7.0.0/service.namespaces.html*service.namespaces-osgi.contract.namespace__;Iw!!PoMpmxQzTok3!vfYoZjwajhz4OBP2gfqvCLtPVAbmJYHEWzRV5zJve8JmyDb9gQrQsI7Rwyfu3Co$
 | 
“osgi.contract” namespace ] there is a [ 
https://urldefense.com/v3/__https:/www.osgi.org/portable-java-contract-definitions/__;!!PoMpmxQzTok3!vfYoZjwajhz4OBP2gfqvCLtPVAbmJYHEWzRV5zJve8JmyDb9gQrQsI7R1eoLCE4$
 | 
contract name defined for JPA ] . 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 < [ 
mailto:osgi-dev@mail.osgi.org | 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://urldefense.com/v3/__https:/github.com/maggu2810/osgideps/blob/master/runtime/pom.xml__;!!PoMpmxQzTok3!vfYoZjwajhz4OBP2gfqvCLtPVAbmJYHEWzRV5zJve8JmyDb9gQrQsI7Ri4rnzkQ$
 | https://github.com/maggu2810/osgideps/blob/master/runtime/pom.xml ] 

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://urldefense.com/v3/__https:/mail.osgi.org/mailman/listinfo/osgi-dev__;!!PoMpmxQzTok3!vfYoZjwajhz4OBP2gfqvCLtPVAbmJYHEWzRV5zJve8JmyDb9gQrQsI7RMYiSoUk$
 | https://mail.osgi.org/mailman/listinfo/osgi-dev ] 







_______________________________________________ 
OSGi Developer Mail List 
osgi-dev@mail.osgi.org 
https://mail.osgi.org/mailman/listinfo/osgi-dev 
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to