Managing OSGi services programatically

Avatar

Avatar

ArpitVarshney

MVP

Avatar

ArpitVarshney

MVP

ArpitVarshney
MVP

22-04-2020

Hi Team,

 

Can anyone help what would be perfect way to achieve this requirement:

We have number of OSGi services in our project and divided into 2 sets.

Based on a parameter passed during build, we need to enable one set of OSGi services and disable other set.

For Example:

We have OSGi service1, service2, service3, service4.

If param == enableFirstSet ----> then enable service1 & service2

If param == enableSecondSet ----> then enable service3 & service4

 

Also,

I have tried below code in activate method to deactivate individual services  based on param but the problem is their attached OCD(configuration) still available in OSGi configuration tab as those configurations attached at bundle level rather than component level.

 

context.disableComponent((String) properties.get(Constants.SERVICE_PID));

 Any pointer will be good.

View Entire Topic

Avatar

Avatar

Jörg_Hoh

Employee

Total Posts

3.0K

Likes

996

Correct Reply

1.0K

Avatar

Jörg_Hoh

Employee

Total Posts

3.0K

Likes

996

Correct Reply

1.0K
Jörg_Hoh
Employee

23-04-2020

Andrew gave a few suggestions how you could achieve it, but I have a more generic question: Why do you want to do this during runtime? Because then you cannot deploy the same artifact(s) on any environment, but you will have specialized builds. Which could make sense if you have multiple production environments. But for every other case (multiple/different development stages) I would definitely use runmodes.

 

And even if you have different PROD environments because you client1, client2 and client3 and they run the same application bundle with some specialities, you still can use runmodes. Just give them the name "client1", "client2" and "client3", and still have all services/components in the same bundle.

 

If this approach doesn't work, you should really think of splitting the functionality in separate bundles and build dedicated deployment packages. Then it is not a decision of the application which services/components to start and stop, but it's a decision at deployment time.

 

There are ways to stop and start services, but these operations are not persisted, unless you switch the value of the service property "enabled" and persist it (see https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html, search for "enabled"; this is R7 but also works for OSGI R6). But be warned: This is a real hack and from my point of view a sign of bad application design and architecture. I would always try to solve this by runmodes.