Hi Scott, The DS snippet below looks promising - I’m assuming that the problem that you’re having is that the component won’t activate because the JDBCConnectionProvider reference is unsatisfied?
If this is the case then one of two things is happening: There is no JDBCConnectionProvider service in the service registry There *is* a JDBCConnectionProvider service in the service registry, but your target filter is preventing it from binding Option 1 could be caused by a few different issues, most of which are pretty simple (and you’ve probably already checked them) but are worth listing: Do you have all the necessary bundles installed and started? You will need: A configurable Transaction Control JDBC Provider implementation. Either Aries Tx JDBC Local <https://github.com/apache/aries-tx-control/tree/master/tx-control-providers/jdbc/tx-control-provider-jdbc-local>, or Aries Tx JDBC XA <https://github.com/apache/aries-tx-control/tree/master/tx-control-providers/jdbc/tx-control-provider-jdbc-xa> would work A suitable JDBC service <https://osgi.org/specification/osgi.cmpn/7.0.0/service.jdbc.html> implementation for your database, which registers a DataSourceFactory with the correct service properties (osgi.jdbc.driver.class is critical!). H2 and Postgres support this natively, for other providers consider using PAX-JDBC or “rolling your own”, which is pretty trivial. A Configuration Admin <https://osgi.org/specification/osgi.cmpn/7.0.0/service.cm.html> implementation and some mechanism for populating it. You may wish to use the Configurator specification <https://osgi.org/specification/osgi.cmpn/7.0.0/service.configurator.html> (which would need something like the Felix Configurator <https://mvnrepository.com/artifact/org.apache.felix/org.apache.felix.configurator> implementation) or something like Felix File Install <https://mvnrepository.com/artifact/org.apache.felix/org.apache.felix.fileinstall> If you’re still in Karaf then this should be available using the normal Karaf configuration mechanisms. Do you have the correct configuration defined for your JDBCConnectionProvider Are you using the correct PID? The Aries implementations use *factory* configurations (singleton configurations are ignored) and the Local/XA implementations have different factory PIDs Did you include the necessary mandatory properties: You must include one of “osgi.jdbc.driver.class” or “aries.dsf.target.filter”. The former is the JDBC driver class name and must *exactly* match the value of the same property on the DataSourceFactory. The latter is an LDAP filter (remember the parentheses) which will be used to locate the DataSourceFactory service The JDBC properties <https://github.com/apache/aries-tx-control/tree/master/tx-control-providers/jdbc/tx-control-provider-jdbc-xa#jdbc-properties> needed to connect to the database, at a minimum I would expect a url, username and password. These will be put into a Properties object and passed to the DataSourceFactory, so make sure you include everything you would normally pass if creating the DataSource programmatically Did you set any configuration properties to logically inconsistent values (e.g. both local and xa transactions disabled) If you are seeing a JDBCConnectionProvider service registered then the problem will be one of: Your target filter is blocking the bind - try checking the target filter to make sure that the property it is looking for is actually set on the JDBCConnectionProvider. There’s an issue with the class space of your application. Somehow you have multiple copies of the org.osgi.transaction.control and/or org.osgi.transaction.control.jdbc packages and your application is wired to an incompatible view of the service. In this case you would need to look at why multiple copies of the API are available and also why they aren’t able to resolve into a single class space. Hopefully the issue turns out to be simple, and this gives you some useful places to look :) Good Luck, Tim > On 22 Apr 2020, at 14:04, Leschke, Scott via osgi-dev > <osgi-dev@mail.osgi.org> wrote: > > 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 <mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <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
