I agree that it sucks having to use Dictionary instances with Configuration Admin, but that’s not the recommended way to receive configuration. You’re much better off accepting a Map (or better yet a Component Property Type) into your DS component’s activate method (or activation field in R7).
The only people who should need to access the Configuration Admin service itself are people who are writing a configuration management agent. This is not a common thing as it means you’re building your own infrastructure - usually people use something like Felix File Install, Felix web console, Karaf, or some vendor product and don’t touch the “management side” of Config Admin in their applications at all. Best Regards, Tim > On 22 Nov 2017, at 17:28, Leschke, Scott <slesc...@medline.com> wrote: > > Hey Tim, > > You make a good point about obsolete vs. deprecated. Anyway, I was just > looking at ConfigAdmin recently, I seem to recall seeing Dictionary exposed > there. While I agree that changing something like that would be a breaking > change, it seems to me that users would have the choice to continue to use R6 > (or lower) versions of services if they needed to / felt so inclined. That’s > kind of the point of OSGi, right, that you have that option? > > I’m kind of radical in my thinking in this regard, I’ll admit. Backwards > compatibility is great, to a point. Sooner or later, if you want to bake a > cake, you have to break some eggs. Oh well, one man’s opinion. Thanks for > the response, > > Scott > > From: Timothy Ward [mailto:tim.w...@paremus.com] > Sent: Wednesday, November 22, 2017 11:17 AM > To: user@karaf.apache.org > Subject: Re: Pax JDBC DataSourceFactory connection pooling config > > 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 > <mailto: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
