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]

Reply via email to