It looks to me like your article leaves out an important detail, namely what is supposed to cause the service tracker extensions to get set up in the first place. I'd suggest that the ideal answer is…. a DS component. If your per-service objects need other "constant" service references (i.e. they get the same ref for each per-service instance) then these can be provided as DS references in this DS component.
I agree that using ServiceTracker in this way is reasonable and simpler than only using DS. thanks david jencks On Apr 24, 2015, at 12:05 PM, Neil Bartlett <[email protected]> wrote: > Service tracker really is better for this. See my (very old) blog post: > > http://njbartlett.name/2010/08/05/when-servicetrackers-trump-ds.html > > In your case I recommend returning the ServiceRegistration object from > addingService(). > > Neil > > -- > Neil Bartlett > > > On Friday, 24 April 2015 at 16:53, Pawel Pogorzelski wrote: > >> Guys, >> what's the standard approach for registering a DS component/OSGi service in >> response to a service appearing in the container? Is ServiceTracker the way >> to go? I'm using Declarative Services and would like stick to DS if >> possible. Explanation of what I'm trying to accomplish below. >> >> I'm using Felix with Gemini JPA which registers EntityManagerFactory as >> OSGi service per each persistence unit configuration. Since I need to open >> connections to multiple DBs with the same schema I end up having multiple >> EntityManagerFactories in the container. I'd like to map them to DAL >> classes one-by-one. So, assuming I have PersonReposity in DAL I'd like to >> have as many instances of it as EntityManagerFactories for the given >> schema. Is SCR able to do it? >> >> Cheers, >> Pawel >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
