Hi, Thanks everybody for their responses.
Yes, there is some special code looking up the second repository, and I thought about registering the second repository with a separate interface, so it can still be bound. My concern, however, is what happens with all the "inner" components, that are not directly coupled to the repository but rather registered in a whiteboard, and still contribute to the correct functioning. To be more precise, let's say I'd like to create 1 oak repository of type Tar (T) and 1 of type Mongo (M): I give T an OSGI whiteboard, while M gets a default implementation that doesn't register its services in OSGI. Let's further say that the construction code of T @References an oak OSGI component (e.g. SecurityProvider), while M constructs one programmatically (e.g. an instance of type SecurityProviderImpl). Would this cause an interference, e.g. could the one explicitly built for M also be implicitly used for T? Thanks Dominique ________________________________________ From: Carsten Ziegeler <[email protected]> Sent: Wednesday, July 16, 2014 3:50 PM To: [email protected] Subject: Re: Multiple oak repositories using an OSGI whiteboard As David points out subsystems might help our writing your own service registry hooks. If you're not using one of those, you have a flat/shared service registry and usually services using a repository service just pick up one from the service registry and that's the one with the highest ranking at the point of asking the registry. Therefore repository services which are registered after this point in time are not even considered and there is no rebinding (unless e.g. DS is used with a greedy reference). As you don't want to rewrite all the code using a repository service, namespacing is the only option. However, the question is, what do you do with this second repository service? Is there special code just looking up the second repository? Maybe in that case, the simpler option could be to register the repository with a different service interface - something like a marker interface SecondaryRepository etc. (maybe with a better name) Regards Carsten 2014-07-16 3:08 GMT-07:00 David Bosschaert <[email protected]>: > Hi Dominique, > > You could look into OSGi Application Subsystems (OSGi Enterprise Spec > 5 chapter 134). Application subsystems provide separate namespaces and > by default don't share out services. Other subsystem types include > Feature subsystems (where everything is shared) and Composite > subsystems where you define explicitly what is shared and what is not. > > I wrote a blog a while ago on how to get Apache Aries subsystems > running on Apache Felix, which might be useful: > > http://coderthoughts.blogspot.com/2014/01/osgi-subsytems-on-apache-felix.html > > Alternatively you can create your own service namespaces by using OSGi > Service Registry hooks, but these are a bit more low-level than > subsystems... > > Best regards, > > David > > On 15 July 2014 21:23, Dominique Pfister <[email protected]> wrote: > > Hi, > > > > > > I'd like to setup two distinct Oak repositories in the same VM, each > containing an OSGI whiteboard. > > > > > > Looking at the components inside oak-core that announce their > availability using this whiteboard and the way the registration is > implemented in the OSGI whiteboard, I was wondering whether above setup is > possible without causing a clash in the OSGI service registry. If so, what > would be the easiest way to create separate "namespaces" where every > component is automatically associated with its designated whiteboard? > > > > > > Kind regards > > > > Dominique > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
