Re: Multiple oak repositories using an OSGI whiteboard
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 dpfis...@adobe.com 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
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 david.bosscha...@gmail.com: 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 dpfis...@adobe.com 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 cziege...@apache.org
RE: Multiple oak repositories using an OSGI whiteboard
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 cziege...@apache.org Sent: Wednesday, July 16, 2014 3:50 PM To: oak-dev@jackrabbit.apache.org 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 david.bosscha...@gmail.com: 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 dpfis...@adobe.com 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 cziege...@apache.org
Re: Multiple oak repositories using an OSGI whiteboard
Hi, 2014-07-16 7:59 GMT-07:00 Dominique Pfister dpfis...@adobe.com: 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 cziege...@apache.org Sent: Wednesday, July 16, 2014 3:50 PM To: oak-dev@jackrabbit.apache.org 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 david.bosscha...@gmail.com: 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 dpfis...@adobe.com 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 cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Multiple oak repositories using an OSGI whiteboard
Hi Dominique, I don't think that this is possible, since many of the OSGi services are kind of singletons. As long OSGi does not offer sandboxing, this won't be possible. I think you have better chance starting 2 oaks w/o OSGi. See the oak-run project for examples. Regards, Toby On Tue, Jul 15, 2014 at 1:23 PM, Dominique Pfister dpfis...@adobe.com 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
