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 <tim.jo...@mccarthy.co.nz>
Sent: Tuesday, April 21, 2020 8:42 PM
To: Leschke, Scott <slesc...@medline.com>; OSGi Developer Mail List
<osgi-dev@mail.osgi.org>
Cc: Timothy Ward <tim.w...@paremus.com>
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=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<mailto:osgi-dev@mail.osgi.org>>
To: "Timothy Ward" <tim.w...@paremus.com<mailto:tim.w...@paremus.com>>, "OSGi
Developer Mail List" <osgi-dev@mail.osgi.org<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 <tim.w...@paremus.com<mailto:tim.w...@paremus.com>>
Sent: Tuesday, April 07, 2020 6:25 AM
To: Leschke, Scott <slesc...@medline.com<mailto:slesc...@medline.com>>; OSGi
Developer Mail List <osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org>>
Cc: Markus Rathgeb <maggu2...@gmail.com<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 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<mailto: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<mailto: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!vowZo6IhMfWGXw_1oita3SzA7-mwGNltZOkvK0nmSVY25exzMAyCFuJgrSALFVU$>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
