Hi Scott, The Dictionary type is actually not deprecated (although it is obsolete). Moving the OSGi core framework away from Dictionary would be a huge breaking change for users (rather than implementers), and simply isn’t going to happen. On the other hand there is really no need to interact with the OSGi framework at this level. In the general case, new specifications will attempt to make use of the best practices when they are made. These best practices may later turn out to have been wrong (c.f. Dictionary) but the alliance will avoid making breaking changes wherever possible in specification updates.
I would honestly be surprised if you had regular (or even any) contact with the Dictionary type when using R7 specifications. Regards, Tim > On 22 Nov 2017, at 17:06, Leschke, Scott <slesc...@medline.com> wrote: > > Hi Tim, > > I’ve looked at this in the past a bit, unfortunately using it would require a > more change on my part than just using the DSF with pooling. I’ll look at it > again to see exactly what it would require as this pooling issue is a bit > problematic. > > Regarding OSGi Release 7, I have a general question for you since you’re > involved in the spec process. Is there any effort going toward not using > deprecated Java APIs in service specs? I have a real issue with continuing > to expose deprecated APIs. I was hoping the Java 9 would go so far as hide > (not export) all deprecated classes but I don’t believe this has happened. > > The one that comes to mind is the use of java.util.Dictionary in numerous > places. I’m sure there are others. Since OSGi supports runtime versioning, > it would seem that replacing Dictionary with Map would be reasonable, as well > as any other deprecated APIs that are exposed. > > Regards, > > Scott > > From: Timothy Ward [mailto:tim.w...@paremus.com > <mailto:tim.w...@paremus.com>] > Sent: Tuesday, November 21, 2017 4:01 AM > To: user@karaf.apache.org <mailto:user@karaf.apache.org> > Subject: Re: Pax JDBC DataSourceFactory connection pooling config > > Hi Scott, > > If you’re interested in using JDBC with pooling in an OSGi environment then I > really would recommend looking at the Transaction Control service. This is a > new specification coming in OSGi release 7, and it provides significant > extensions to the DataSourceFactory model, including pooling, managed > lifecycles for your database connection usage, standard configuration > properties, and transaction support (both local and XA). > > The proposed reference implementation is available from Apache Aries, and > implements all of the features from the specification draft. It also has a > large number of tests for the various components, including local and XA JPA > support (if that’s of interest). > > Regards, > > Tim > > > On 20 Nov 2017, at 21:47, Leschke, Scott <slesc...@medline.com > <mailto:slesc...@medline.com>> wrote: > > How does one configure the underlying connection pool when using Pax JDBC > DataSourceFactory? I’ve been using this for a while and recently discovered > it’s not behaving as I intended. I’m using Hikari as my CP, and want to > configure the following Hikari properties: > > poolName > maximumPoolSize > minimumIdle > idleTimeout > maxLifetime > > I’ve been prefixing each of these “hikari.” (which I concluded was the proper > way to do it some months ago), but it appears that Hikari is using defaults. > When I configure as follows, > > hikari.poolName = Composite Enterprise Data > hikari.maximumPoolSize = 1 > hikari.minimumIdle = 0 > hikari.idleTimeout = 28800000 > hikari.maxLifetime = 0 > > I immediately get 10 connections to the datastore, even before a connection > is actually requested to run a query (Cisco Information Server (aka, > Composite)). > This would be the default behavior if none of the above get used. I also > tried prefixing with “pool.” btw (which makes more sense to me), but get the > same behavior. > > Scott
