Hi, 2014-07-16 7:59 GMT-07:00 Dominique Pfister <[email protected]>:
> 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? > > I assume that you don't register any of the constructed services for M in the service registry - therefore there shouldn't be an interference as T will never see those services through the whiteboard pattern. Regards Carsten > 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] > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
