Re: [osgi-dev] Regarding Transaction Control

[Leschke, Scott via osgi-dev]

Thanks Other Tim for the response. I believe that’s pretty much what I’m doing. 
In my code I have

@Reference
private TransactionControl txnCtrl;

@Reference
private JDBCConnectionProvider jcp;

This is a factory component so in a config file I have

jcp.target = (dataSourceName=my_ds_name)

I’m just doing property injection instead of using setter methods

Then in the component @Activate method I get the connection object using

this.conn = jcp.getResource(txnCtrl);

Thanks again for your response,

Scott

From: Tim Jones 
Sent: Tuesday, April 21, 2020 8:42 PM
To: Leschke, Scott ; OSGi Developer Mail List 

Cc: Timothy Ward 
Subject: Re: [osgi-dev] Regarding Transaction Control

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=30
aries.jdbc.property.names=user,password,url
osgi.jdbc.driver.class=org.postgresql.Driver
url=jdbc:postgresql://localhost:5432/
databaseName=
serverName=localhost
portNumber=5432
user=
password=
dataSourceName=data_source_name

Regards,

Tim Jones



From: "Leschke, Scott via osgi-dev" 
mailto:osgi-dev@mail.osgi.org>>
To: "Timothy Ward" mailto:tim.w...@paremus.com>>, "OSGi 
Developer Mail List" mailto: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 mailto:tim.w...@paremus.com>>
Sent: Tuesday, April 07, 2020 6:25 AM
To: Leschke, Scott mailto:slesc...@medline.com>>; OSGi 
Developer Mail List mailto:osgi-dev@mail.osgi.org>>
Cc: Markus Rathgeb mailto: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 be

Re: [osgi-dev] Regarding Transaction Control

[Leschke, Scott via osgi-dev]

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 
Sent: Tuesday, April 07, 2020 6:25 AM
To: Leschke, Scott ; OSGi Developer Mail List 

Cc: Markus Rathgeb 
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 
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
___
OS

Re: [osgi-dev] Regarding Transaction Control

[Tim Ward via osgi-dev]

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 

 and 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 “osgi.contract” namespace 

 there is a 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  
> 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
> 
> 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

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

Re: [osgi-dev] Regarding Transaction Control

[Markus Rathgeb via osgi-dev]

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

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

[osgi-dev] Regarding Transaction Control

[Leschke, Scott via osgi-dev]

I'd like to start using the Transaction Control service as my preferred JDBC 
mechanism over rather than java.sql.DataSource.  it looks like the 
org.osgi.service.transcation.control-1.0.0.jar bundle depends on a pre-v2.0 
javax.persistence version.

Is this right or is that not the latest?  That's a real old JPA version as far 
as I know. I wasn't even able to find a pre 2.0 version online.

Regards,

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