Authentication with configuration: Bundle vs DeclarativeService?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Authentication with configuration: Bundle vs DeclarativeService?

kamilantlgc
Dear Karaf users,

I'm aware that this post is more about OSGi, but you were so helpful so far,
that I hope it will be the same this time :)

I have a case with three requirements explained below:

1) I must implement "something" (Bundle or Component) that will receive
configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use
both:

a) BundleActivator with ManagedService approach:


b) DeclarativeService approach:


2) But the second requirement is, that config MUST be available before
Bundle/Component starts (because my Bundle/Component must authenticate
itself using credentials from the config). Therefore:

a) I have no idea how to achieve it using BundleActivator

b) Using DeclarativeService approach it is easy:


3) And the third requirement is: if authentication fails - bundle must stop
itself:

a) it is easy using BundleActivator, because if start method throws
exception - Bundle stops itself


b) I have no idea how to achieve it using DeclarativeService (let's say that
there is just one service per bundle)


Could you help me please with figuring out how I can achieve all three
requirements at the same time?

Kind regards,
Kamil



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Reply | Threaded
Open this post in threaded view
|

ODP: Authentication with configuration: Bundle vs DeclarativeService?

kamilantlgc

I see that my examples where trimmed. So I send them once again:


I have a case with three requirements explained below:

1) I must implement "something" (Bundle or Component) that will receive configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use both:

a) BundleActivator with ManagedService approach:

@Override
public final void start(final BundleContext bundleContext) throws InterruptedException {
  serviceReg = bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
}


b) DeclarativeService approach:

@Component(
    configurationPid = MyService.CONFIGURATION_PID
)
public class MyService {
  @Activate
  public MyService(final MyConfiguration configuration) throws Exception {
  }
}


2) But the second requirement is, that config MUST be available before Bundle/Component starts (because my Bundle/Component must authenticate itself using credentials from the config). Therefore:

a) I have no idea how to achieve it using BundleActivator

b) Using DeclarativeService approach it is easy:

@Component(
    immediate = true,
    configurationPolicy = ConfigurationPolicy.REQUIRE,
    configurationPid = MyService.CONFIGURATION_PID
)


3) And the third requirement is: if authentication fails - bundle must stop itself:

a) it is easy using BundleActivator, because if start method throws exception - Bundle stops itself

  @Override
  public final void start(final BundleContext bundleContext) throws InterruptedException {
    bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
  }
 
  private final class ConfigUpdater implements ManagedService {
      @Override
      public void updated(final Dictionary<String, ?> config) throws ConfigurationException {
        if (authenticate(config) == false) {
          throw new NotAuthenticatedException();
        }
      }
   }
}


b) I have no idea how to achieve it using DeclarativeService (let's say that there is just one service per bundle)


Could you help me please with figuring out how I can achieve all three requirements at the same time?

Kind regards,
Kamil

 

Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 14:19
Do: [hidden email]
Temat: Authentication with configuration: Bundle vs DeclarativeService?

 

Dear Karaf users,

 

I'm aware that this post is more about OSGi, but you were so helpful so far,

that I hope it will be the same this time :)

 

I have a case with three requirements explained below:

 

1) I must implement "something" (Bundle or Component) that will receive

configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use

both:

 

a) BundleActivator with ManagedService approach:

 

 

b) DeclarativeService approach:

 

 

2) But the second requirement is, that config MUST be available before

Bundle/Component starts (because my Bundle/Component must authenticate

itself using credentials from the config). Therefore:

 

a) I have no idea how to achieve it using BundleActivator

 

b) Using DeclarativeService approach it is easy:

 

 

3) And the third requirement is: if authentication fails - bundle must stop

itself:

 

a) it is easy using BundleActivator, because if start method throws

exception - Bundle stops itself

 

 

b) I have no idea how to achieve it using DeclarativeService (let's say that

there is just one service per bundle)

 

 

Could you help me please with figuring out how I can achieve all three

requirements at the same time?

 

Kind regards,

Kamil

 

 

 

--

Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

 

Reply | Threaded
Open this post in threaded view
|

Re: ODP: Authentication with configuration: Bundle vs DeclarativeService?

David Jencks-2
I suggest you:
-Reinterpret the 3rd requirement to be that a service is registered only when a configuration is present and that configuration results in valid authentication. Why do you care if the bundle is active? What’s usually important is whether a service is present.
-write a ManagedService as a DS component that authenticates and if successful creates the actual service.

David Jencks 


Sent from my iPhone

On Aug 19, 2019, at 5:21 AM, Kamil Paśko <[hidden email]> wrote:

I see that my examples where trimmed. So I send them once again:


I have a case with three requirements explained below:

1) I must implement "something" (Bundle or Component) that will receive configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use both:

a) BundleActivator with ManagedService approach:

@Override
public final void start(final BundleContext bundleContext) throws InterruptedException {
  serviceReg = bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
}


b) DeclarativeService approach:

@Component(
    configurationPid = MyService.CONFIGURATION_PID
)
public class MyService {
  @Activate
  public MyService(final MyConfiguration configuration) throws Exception {
  }
}


2) But the second requirement is, that config MUST be available before Bundle/Component starts (because my Bundle/Component must authenticate itself using credentials from the config). Therefore:

a) I have no idea how to achieve it using BundleActivator

b) Using DeclarativeService approach it is easy:

@Component(
    immediate = true,
    configurationPolicy = ConfigurationPolicy.REQUIRE,
    configurationPid = MyService.CONFIGURATION_PID
)


3) And the third requirement is: if authentication fails - bundle must stop itself:

a) it is easy using BundleActivator, because if start method throws exception - Bundle stops itself

  @Override
  public final void start(final BundleContext bundleContext) throws InterruptedException {
    bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
  }
 
  private final class ConfigUpdater implements ManagedService {
      @Override
      public void updated(final Dictionary<String, ?> config) throws ConfigurationException {
        if (authenticate(config) == false) {
          throw new NotAuthenticatedException();
        }
      }
   }
}


b) I have no idea how to achieve it using DeclarativeService (let's say that there is just one service per bundle)


Could you help me please with figuring out how I can achieve all three requirements at the same time?

Kind regards,
Kamil

 

Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 14:19
Do: [hidden email]
Temat: Authentication with configuration: Bundle vs DeclarativeService?

 

Dear Karaf users,

 

I'm aware that this post is more about OSGi, but you were so helpful so far,

that I hope it will be the same this time :)

 

I have a case with three requirements explained below:

 

1) I must implement "something" (Bundle or Component) that will receive

configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use

both:

 

a) BundleActivator with ManagedService approach:

 

 

b) DeclarativeService approach:

 

 

2) But the second requirement is, that config MUST be available before

Bundle/Component starts (because my Bundle/Component must authenticate

itself using credentials from the config). Therefore:

 

a) I have no idea how to achieve it using BundleActivator

 

b) Using DeclarativeService approach it is easy:

 

 

3) And the third requirement is: if authentication fails - bundle must stop

itself:

 

a) it is easy using BundleActivator, because if start method throws

exception - Bundle stops itself

 

 

b) I have no idea how to achieve it using DeclarativeService (let's say that

there is just one service per bundle)

 

 

Could you help me please with figuring out how I can achieve all three

requirements at the same time?

 

Kind regards,

Kamil

 

 

 

--

Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

 

Reply | Threaded
Open this post in threaded view
|

ODP: ODP: Authentication with configuration: Bundle vsDeclarativeService?

kamilantlgc

@David,

 

Thank you for your answer.

I care „if the bundle is active” because as far as I know, Karaf console and API allows me to check the state of bundles – not particular services.

Please, correct me if I’m wrong.

 

Moreover - all our monitoring tools verify bundles health, and are able to restart them when bundle will be able to authenticate again.

 

That is why I need to stop whole bundle if authentication fails and I must care about whole bundle – not particular service.

 

Does it make sense?

 

Kind regards,

Kamil

 

Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 16:07
Do: [hidden email]
Temat: Re: ODP: Authentication with configuration: Bundle vsDeclarativeService?

 

I suggest you:

-Reinterpret the 3rd requirement to be that a service is registered only when a configuration is present and that configuration results in valid authentication. Why do you care if the bundle is active? What’s usually important is whether a service is present.

-write a ManagedService as a DS component that authenticates and if successful creates the actual service.

 

David Jencks 

 

Sent from my iPhone


On Aug 19, 2019, at 5:21 AM, Kamil Paśko <[hidden email]> wrote:

I see that my examples where trimmed. So I send them once again:


I have a case with three requirements explained below:

1) I must implement "something" (Bundle or Component) that will receive configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use both:

a) BundleActivator with ManagedService approach:


@Override
public final void start(final BundleContext bundleContext) throws InterruptedException {
  serviceReg = bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
}


b) DeclarativeService approach:


@Component(
    configurationPid = MyService.CONFIGURATION_PID
)
public class MyService {
  @Activate
  public MyService(final MyConfiguration configuration) throws Exception {
  }
}


2) But the second requirement is, that config MUST be available before Bundle/Component starts (because my Bundle/Component must authenticate itself using credentials from the config). Therefore:

a) I have no idea how to achieve it using BundleActivator

b) Using DeclarativeService approach it is easy:


@Component(
    immediate = true,
    configurationPolicy = ConfigurationPolicy.REQUIRE,
    configurationPid = MyService.CONFIGURATION_PID
)


3) And the third requirement is: if authentication fails - bundle must stop itself:

a) it is easy using BundleActivator, because if start method throws exception - Bundle stops itself


  @Override
  public final void start(final BundleContext bundleContext) throws InterruptedException {
    bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
  }
 
  private final class ConfigUpdater implements ManagedService {
      @Override
      public void updated(final Dictionary<String, ?> config) throws ConfigurationException {
        if (authenticate(config) == false) {
          throw new NotAuthenticatedException();
        }
      }
   }
}


b) I have no idea how to achieve it using DeclarativeService (let's say that there is just one service per bundle)


Could you help me please with figuring out how I can achieve all three requirements at the same time?

Kind regards,
Kamil

 

Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 14:19
Do: [hidden email]
Temat: Authentication with configuration: Bundle vs DeclarativeService?

 

Dear Karaf users,

 

I'm aware that this post is more about OSGi, but you were so helpful so far,

that I hope it will be the same this time :)

 

I have a case with three requirements explained below:

 

1) I must implement "something" (Bundle or Component) that will receive

configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use

both:

 

a) BundleActivator with ManagedService approach:

 

 

b) DeclarativeService approach:

 

 

2) But the second requirement is, that config MUST be available before

Bundle/Component starts (because my Bundle/Component must authenticate

itself using credentials from the config). Therefore:

 

a) I have no idea how to achieve it using BundleActivator

 

b) Using DeclarativeService approach it is easy:

 

 

3) And the third requirement is: if authentication fails - bundle must stop

itself:

 

a) it is easy using BundleActivator, because if start method throws

exception - Bundle stops itself

 

 

b) I have no idea how to achieve it using DeclarativeService (let's say that

there is just one service per bundle)

 

 

Could you help me please with figuring out how I can achieve all three

requirements at the same time?

 

Kind regards,

Kamil

 

 

 

--

Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

 

 

Reply | Threaded
Open this post in threaded view
|

Re: ODP: ODP: Authentication with configuration: Bundle vsDeclarativeService?

David Jencks-2
Services don’t have state, other than their properties, and you can certainly investigate services with the console. Ds components do have state, which you can investigate using the console.

Your answer doesn’t make sense to me yet. What is the nature of the authentication? If it’s entirely self contained then changes to the configuration will be automatically propagated to a configuration-aware component anyway without your doing anything special, and if it relies on some sort of remote service I’d expect your component would be the only reasonable place to track this remote services availability.

I don’t recall ever finding a situation where restarting a bundle was a reasonable response.

I may not understand your situation...
David Jencks 

Sent from my iPhone

On Aug 23, 2019, at 4:43 AM, Kamil Paśko <[hidden email]> wrote:

@David,

 

Thank you for your answer.

I care „if the bundle is active” because as far as I know, Karaf console and API allows me to check the state of bundles – not particular services.

Please, correct me if I’m wrong.

 

Moreover - all our monitoring tools verify bundles health, and are able to restart them when bundle will be able to authenticate again.

 

That is why I need to stop whole bundle if authentication fails and I must care about whole bundle – not particular service.

 

Does it make sense?

 

Kind regards,

Kamil

 

Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 16:07
Do: [hidden email]
Temat: Re: ODP: Authentication with configuration: Bundle vsDeclarativeService?

 

I suggest you:

-Reinterpret the 3rd requirement to be that a service is registered only when a configuration is present and that configuration results in valid authentication. Why do you care if the bundle is active? What’s usually important is whether a service is present.

-write a ManagedService as a DS component that authenticates and if successful creates the actual service.

 

David Jencks 

 

Sent from my iPhone


On Aug 19, 2019, at 5:21 AM, Kamil Paśko <[hidden email]> wrote:

I see that my examples where trimmed. So I send them once again:


I have a case with three requirements explained below:

1) I must implement "something" (Bundle or Component) that will receive configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use both:

a) BundleActivator with ManagedService approach:


@Override
public final void start(final BundleContext bundleContext) throws InterruptedException {
  serviceReg = bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
}


b) DeclarativeService approach:


@Component(
    configurationPid = MyService.CONFIGURATION_PID
)
public class MyService {
  @Activate
  public MyService(final MyConfiguration configuration) throws Exception {
  }
}


2) But the second requirement is, that config MUST be available before Bundle/Component starts (because my Bundle/Component must authenticate itself using credentials from the config). Therefore:

a) I have no idea how to achieve it using BundleActivator

b) Using DeclarativeService approach it is easy:


@Component(
    immediate = true,
    configurationPolicy = ConfigurationPolicy.REQUIRE,
    configurationPid = MyService.CONFIGURATION_PID
)


3) And the third requirement is: if authentication fails - bundle must stop itself:

a) it is easy using BundleActivator, because if start method throws exception - Bundle stops itself


  @Override
  public final void start(final BundleContext bundleContext) throws InterruptedException {
    bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
  }
 
  private final class ConfigUpdater implements ManagedService {
      @Override
      public void updated(final Dictionary<String, ?> config) throws ConfigurationException {
        if (authenticate(config) == false) {
          throw new NotAuthenticatedException();
        }
      }
   }
}


b) I have no idea how to achieve it using DeclarativeService (let's say that there is just one service per bundle)


Could you help me please with figuring out how I can achieve all three requirements at the same time?

Kind regards,
Kamil

 

Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 14:19
Do: [hidden email]
Temat: Authentication with configuration: Bundle vs DeclarativeService?

 

Dear Karaf users,

 

I'm aware that this post is more about OSGi, but you were so helpful so far,

that I hope it will be the same this time :)

 

I have a case with three requirements explained below:

 

1) I must implement "something" (Bundle or Component) that will receive

configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use

both:

 

a) BundleActivator with ManagedService approach:

 

 

b) DeclarativeService approach:

 

 

2) But the second requirement is, that config MUST be available before

Bundle/Component starts (because my Bundle/Component must authenticate

itself using credentials from the config). Therefore:

 

a) I have no idea how to achieve it using BundleActivator

 

b) Using DeclarativeService approach it is easy:

 

 

3) And the third requirement is: if authentication fails - bundle must stop

itself:

 

a) it is easy using BundleActivator, because if start method throws

exception - Bundle stops itself

 

 

b) I have no idea how to achieve it using DeclarativeService (let's say that

there is just one service per bundle)

 

 

Could you help me please with figuring out how I can achieve all three

requirements at the same time?

 

Kind regards,

Kamil

 

 

 

--

Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

 

 

Reply | Threaded
Open this post in threaded view
|

ODP: ODP: ODP: Authentication with configuration: BundlevsDeclarativeService?

kamilantlgc

@Dawid,

 

Ok, here’s my situation:

  1. Let’s say I have hundreds of weather stations
  2. Each weather station gathers different data (some only the temperature, some humidity, some both and some let’s say – radiation). They’re completly independent of each other. Can be deployed separately, have different versions etc. That’s why I represented each weather station as separate bundle in Karaf cluster.
  3. Each weather station sends it’s data to the server using „WeatherService”
  4. But before weather station can send it’s first data – it must use „AuthenticationService” and it’s own Configuration (containing it’s login and password) in order to authenticate itself. If it can not – is should stop and do not send data
  5. Why restarting the bundle helps with authentication? Because Operator can create weather station’s account in the system and restart the bundle – then it’ll authenticate itself successfuly

 

I hope that this explains my situation.

 

Kind regards,

Kamil

 

 

Od: [hidden email]
Wysłano: piątek, 23 sierpnia 2019 15:41
Do: [hidden email]
Temat: Re: ODP: ODP: Authentication with configuration: BundlevsDeclarativeService?

 

Services don’t have state, other than their properties, and you can certainly investigate services with the console. Ds components do have state, which you can investigate using the console.

 

Your answer doesn’t make sense to me yet. What is the nature of the authentication? If it’s entirely self contained then changes to the configuration will be automatically propagated to a configuration-aware component anyway without your doing anything special, and if it relies on some sort of remote service I’d expect your component would be the only reasonable place to track this remote services availability.

 

I don’t recall ever finding a situation where restarting a bundle was a reasonable response.

 

I may not understand your situation...

David Jencks 

Sent from my iPhone


On Aug 23, 2019, at 4:43 AM, Kamil Paśko <[hidden email]> wrote:

@David,

 

Thank you for your answer.

I care „if the bundle is active” because as far as I know, Karaf console and API allows me to check the state of bundles – not particular services.

Please, correct me if I’m wrong.

 

Moreover - all our monitoring tools verify bundles health, and are able to restart them when bundle will be able to authenticate again.

 

That is why I need to stop whole bundle if authentication fails and I must care about whole bundle – not particular service.

 

Does it make sense?

 

Kind regards,

Kamil

 

Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 16:07
Do: [hidden email]
Temat: Re: ODP: Authentication with configuration: Bundle vsDeclarativeService?

 

I suggest you:

-Reinterpret the 3rd requirement to be that a service is registered only when a configuration is present and that configuration results in valid authentication. Why do you care if the bundle is active? What’s usually important is whether a service is present.

-write a ManagedService as a DS component that authenticates and if successful creates the actual service.

 

David Jencks 

 

Sent from my iPhone


On Aug 19, 2019, at 5:21 AM, Kamil Paśko <[hidden email]> wrote:

I see that my examples where trimmed. So I send them once again:


I have a case with three requirements explained below:

1) I must implement "something" (Bundle or Component) that will receive configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use both:

a) BundleActivator with ManagedService approach:



@Override
public final void start(final BundleContext bundleContext) throws InterruptedException {
  serviceReg = bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
}


b) DeclarativeService approach:



@Component(
    configurationPid = MyService.CONFIGURATION_PID
)
public class MyService {
  @Activate
  public MyService(final MyConfiguration configuration) throws Exception {
  }
}


2) But the second requirement is, that config MUST be available before Bundle/Component starts (because my Bundle/Component must authenticate itself using credentials from the config). Therefore:

a) I have no idea how to achieve it using BundleActivator

b) Using DeclarativeService approach it is easy:



@Component(
    immediate = true,
    configurationPolicy = ConfigurationPolicy.REQUIRE,
    configurationPid = MyService.CONFIGURATION_PID
)


3) And the third requirement is: if authentication fails - bundle must stop itself:

a) it is easy using BundleActivator, because if start method throws exception - Bundle stops itself



  @Override
  public final void start(final BundleContext bundleContext) throws InterruptedException {
    bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
  }
 
  private final class ConfigUpdater implements ManagedService {
      @Override
      public void updated(final Dictionary<String, ?> config) throws ConfigurationException {
        if (authenticate(config) == false) {
          throw new NotAuthenticatedException();
        }
      }
   }
}


b) I have no idea how to achieve it using DeclarativeService (let's say that there is just one service per bundle)


Could you help me please with figuring out how I can achieve all three requirements at the same time?

Kind regards,
Kamil

 

Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 14:19
Do: [hidden email]
Temat: Authentication with configuration: Bundle vs DeclarativeService?

 

Dear Karaf users,

 

I'm aware that this post is more about OSGi, but you were so helpful so far,

that I hope it will be the same this time :)

 

I have a case with three requirements explained below:

 

1) I must implement "something" (Bundle or Component) that will receive

configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use

both:

 

a) BundleActivator with ManagedService approach:

 

 

b) DeclarativeService approach:

 

 

2) But the second requirement is, that config MUST be available before

Bundle/Component starts (because my Bundle/Component must authenticate

itself using credentials from the config). Therefore:

 

a) I have no idea how to achieve it using BundleActivator

 

b) Using DeclarativeService approach it is easy:

 

 

3) And the third requirement is: if authentication fails - bundle must stop

itself:

 

a) it is easy using BundleActivator, because if start method throws

exception - Bundle stops itself

 

 

b) I have no idea how to achieve it using DeclarativeService (let's say that

there is just one service per bundle)

 

 

Could you help me please with figuring out how I can achieve all three

requirements at the same time?

 

Kind regards,

Kamil

 

 

 

--

Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Authentication with configuration: BundlevsDeclarativeService?

David Jencks-2
Hi Kamil,

Is the operator creating the account in the authentication service, so that the previously invalid credentials become valid?

How does your system deal with failures in communication to the authentication service? Is the operator required to restart all the “weather station” bundles? Is it possible to treat “invalid credentials” the same as “no communication to the authentication service”?

In any case, with my proposal, restarting the bundle will certainly result in another attempt to authenticate if the configuration is present.  Can you use the service presence rather than the bundle state to determine “health”?

David Jencks

On Aug 23, 2019, at 7:07 AM, Kamil Paśko <[hidden email]> wrote:

@Dawid,
 
Ok, here’s my situation:
  1. Let’s say I have hundreds of weather stations 
  2. Each weather station gathers different data (some only the temperature, some humidity, some both and some let’s say – radiation). They’re completly independent of each other. Can be deployed separately, have different versions etc. That’s why I represented each weather station as separate bundle in Karaf cluster.
  3. Each weather station sends it’s data to the server using „WeatherService”
  4. But before weather station can send it’s first data – it must use „AuthenticationService” and it’s own Configuration (containing it’s login and password) in order to authenticate itself. If it can not – is should stop and do not send data
  5. Why restarting the bundle helps with authentication? Because Operator can create weather station’s account in the system and restart the bundle – then it’ll authenticate itself successfuly
 
I hope that this explains my situation.
 
Kind regards,
Kamil
 
 
Od: [hidden email]
Wysłano: piątek, 23 sierpnia 2019 15:41
Do: [hidden email]
Temat: Re: ODP: ODP: Authentication with configuration: BundlevsDeclarativeService?
 
Services don’t have state, other than their properties, and you can certainly investigate services with the console. Ds components do have state, which you can investigate using the console.
 
Your answer doesn’t make sense to me yet. What is the nature of the authentication? If it’s entirely self contained then changes to the configuration will be automatically propagated to a configuration-aware component anyway without your doing anything special, and if it relies on some sort of remote service I’d expect your component would be the only reasonable place to track this remote services availability.
 
I don’t recall ever finding a situation where restarting a bundle was a reasonable response.
 
I may not understand your situation...

David Jencks 

Sent from my iPhone


On Aug 23, 2019, at 4:43 AM, Kamil Paśko <[hidden email]> wrote:

@David,
 
Thank you for your answer.
I care „if the bundle is active” because as far as I know, Karaf console and API allows me to check the state of bundles – not particular services. 
Please, correct me if I’m wrong.
 
Moreover - all our monitoring tools verify bundles health, and are able to restart them when bundle will be able to authenticate again.
 
That is why I need to stop whole bundle if authentication fails and I must care about whole bundle – not particular service.
 
Does it make sense?
 
Kind regards,
Kamil
 
Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 16:07
Do: [hidden email]
Temat: Re: ODP: Authentication with configuration: Bundle vsDeclarativeService?
 
I suggest you:
-Reinterpret the 3rd requirement to be that a service is registered only when a configuration is present and that configuration results in valid authentication. Why do you care if the bundle is active? What’s usually important is whether a service is present.
-write a ManagedService as a DS component that authenticates and if successful creates the actual service.
 
David Jencks 

 

Sent from my iPhone


On Aug 19, 2019, at 5:21 AM, Kamil Paśko <[hidden email]> wrote:

I see that my examples where trimmed. So I send them once again:

I have a case with three requirements explained below:

1) I must implement "something" (Bundle or Component) that will receive configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use both:

a) BundleActivator with ManagedService approach:



@Override
public final void start(final BundleContext bundleContext) throws InterruptedException {
  serviceReg = bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
}

b) DeclarativeService approach:



@Component(
    configurationPid = MyService.CONFIGURATION_PID
)
public class MyService {
  @Activate
  public MyService(final MyConfiguration configuration) throws Exception {
  }
}

2) But the second requirement is, that config MUST be available before Bundle/Component starts (because my Bundle/Component must authenticate itself using credentials from the config). Therefore:

a) I have no idea how to achieve it using BundleActivator

b) Using DeclarativeService approach it is easy:



@Component(
    immediate = true,
    configurationPolicy = ConfigurationPolicy.REQUIRE,
    configurationPid = MyService.CONFIGURATION_PID
)

3) And the third requirement is: if authentication fails - bundle must stop itself:

a) it is easy using BundleActivator, because if start method throws exception - Bundle stops itself



  @Override
  public final void start(final BundleContext bundleContext) throws InterruptedException {
    bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
  }
 
  private final class ConfigUpdater implements ManagedService {
      @Override
      public void updated(final Dictionary<String, ?> config) throws ConfigurationException {
        if (authenticate(config) == false) {
          throw new NotAuthenticatedException();
        }
      }
   }
}

b) I have no idea how to achieve it using DeclarativeService (let's say that there is just one service per bundle)


Could you help me please with figuring out how I can achieve all three requirements at the same time?

Kind regards,
Kamil
 
Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 14:19
Do: [hidden email]
Temat: Authentication with configuration: Bundle vs DeclarativeService?
 
Dear Karaf users,
 
I'm aware that this post is more about OSGi, but you were so helpful so far,
that I hope it will be the same this time :)
 
I have a case with three requirements explained below:
 
1) I must implement "something" (Bundle or Component) that will receive
configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use
both: 
 
a) BundleActivator with ManagedService approach:
 
 
b) DeclarativeService approach:
 
 
2) But the second requirement is, that config MUST be available before
Bundle/Component starts (because my Bundle/Component must authenticate
itself using credentials from the config). Therefore:
 
a) I have no idea how to achieve it using BundleActivator
 
b) Using DeclarativeService approach it is easy:
 
 
3) And the third requirement is: if authentication fails - bundle must stop
itself:
 
a) it is easy using BundleActivator, because if start method throws
exception - Bundle stops itself
 
 
b) I have no idea how to achieve it using DeclarativeService (let's say that
there is just one service per bundle)
 
 
Could you help me please with figuring out how I can achieve all three
requirements at the same time?
 
Kind regards,
Kamil
 
 
 
--

Reply | Threaded
Open this post in threaded view
|

ODP: Authentication with configuration: BundlevsDeclarativeService?

kamilantlgc

David,

 

> Is the operator creating the account in the authentication service, so that the previously invalid credentials become valid?

 

Exactly

 

> How does your system deal with failures in communication to the authentication service? Is the operator required to restart all the “weather station” bundles? Is it possible to treat “invalid credentials” the same as “no communication to the authentication service”?

 

In both cases it’s the same: in case of „no communication” or „invalid credentials” – bundle should stop (with proper message in logs) and should not send any data

So neither  bundle, nor the  service have any state. If bundle  can not authenticate itself – it just stops.

 

> Can you use the service presence rather than the bundle state to determine “health”?

 

I don’t quite understand that

 

Kind regards,

Kamil

 

 

Od: [hidden email]
Wysłano: piątek, 23 sierpnia 2019 16:53
Do: [hidden email]
Temat: Re: Authentication with configuration: BundlevsDeclarativeService?

 

Hi Kamil,

 

Is the operator creating the account in the authentication service, so that the previously invalid credentials become valid?

 

How does your system deal with failures in communication to the authentication service? Is the operator required to restart all the “weather station” bundles? Is it possible to treat “invalid credentials” the same as “no communication to the authentication service”?

 

In any case, with my proposal, restarting the bundle will certainly result in another attempt to authenticate if the configuration is present.  Can you use the service presence rather than the bundle state to determine “health”?

 

David Jencks



On Aug 23, 2019, at 7:07 AM, Kamil Paśko <[hidden email]> wrote:

 

@Dawid,

 

Ok, here’s my situation:

  1. Let’s say I have hundreds of weather stations 
  2. Each weather station gathers different data (some only the temperature, some humidity, some both and some let’s say – radiation). They’re completly independent of each other. Can be deployed separately, have different versions etc. That’s why I represented each weather station as separate bundle in Karaf cluster.
  3. Each weather station sends it’s data to the server using „WeatherService”
  4. But before weather station can send it’s first data – it must use „AuthenticationService” and it’s own Configuration (containing it’s login and password) in order to authenticate itself. If it can not – is should stop and do not send data
  5. Why restarting the bundle helps with authentication? Because Operator can create weather station’s account in the system and restart the bundle – then it’ll authenticate itself successfuly

 

I hope that this explains my situation.

 

Kind regards,

Kamil

 

 

Od: [hidden email]
Wysłano: piątek, 23 sierpnia 2019 15:41
Do: [hidden email]
Temat: Re: ODP: ODP: Authentication with configuration: BundlevsDeclarativeService?

 

Services don’t have state, other than their properties, and you can certainly investigate services with the console. Ds components do have state, which you can investigate using the console.

 

Your answer doesn’t make sense to me yet. What is the nature of the authentication? If it’s entirely self contained then changes to the configuration will be automatically propagated to a configuration-aware component anyway without your doing anything special, and if it relies on some sort of remote service I’d expect your component would be the only reasonable place to track this remote services availability.

 

I don’t recall ever finding a situation where restarting a bundle was a reasonable response.

 

I may not understand your situation...

David Jencks 

Sent from my iPhone


On Aug 23, 2019, at 4:43 AM, Kamil Paśko <[hidden email]> wrote:

@David,

 

Thank you for your answer.

I care „if the bundle is active” because as far as I know, Karaf console and API allows me to check the state of bundles – not particular services. 

Please, correct me if I’m wrong.

 

Moreover - all our monitoring tools verify bundles health, and are able to restart them when bundle will be able to authenticate again.

 

That is why I need to stop whole bundle if authentication fails and I must care about whole bundle – not particular service.

 

Does it make sense?

 

Kind regards,

Kamil

 

Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 16:07
Do: [hidden email]
Temat: Re: ODP: Authentication with configuration: Bundle vsDeclarativeService?

 

I suggest you:

-Reinterpret the 3rd requirement to be that a service is registered only when a configuration is present and that configuration results in valid authentication. Why do you care if the bundle is active? What’s usually important is whether a service is present.

-write a ManagedService as a DS component that authenticates and if successful creates the actual service.

 

David Jencks 

 

Sent from my iPhone


On Aug 19, 2019, at 5:21 AM, Kamil Paśko <[hidden email]> wrote:

I see that my examples where trimmed. So I send them once again:


I have a case with three requirements explained below:

1) I must implement "something" (Bundle or Component) that will receive configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use both:

a) BundleActivator with ManagedService approach:




@Override
public final void start(final BundleContext bundleContext) throws InterruptedException {
  serviceReg = bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
}


b) DeclarativeService approach:




@Component(
    configurationPid = MyService.CONFIGURATION_PID
)
public class MyService {
  @Activate
  public MyService(final MyConfiguration configuration) throws Exception {
  }
}


2) But the second requirement is, that config MUST be available before Bundle/Component starts (because my Bundle/Component must authenticate itself using credentials from the config). Therefore:

a) I have no idea how to achieve it using BundleActivator

b) Using DeclarativeService approach it is easy:




@Component(
    immediate = true,
    configurationPolicy = ConfigurationPolicy.REQUIRE,
    configurationPid = MyService.CONFIGURATION_PID
)


3) And the third requirement is: if authentication fails - bundle must stop itself:

a) it is easy using BundleActivator, because if start method throws exception - Bundle stops itself




  @Override
  public final void start(final BundleContext bundleContext) throws InterruptedException {
    bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
  }
 
  private final class ConfigUpdater implements ManagedService {
      @Override
      public void updated(final Dictionary<String, ?> config) throws ConfigurationException {
        if (authenticate(config) == false) {
          throw new NotAuthenticatedException();
        }
      }
   }
}


b) I have no idea how to achieve it using DeclarativeService (let's say that there is just one service per bundle)


Could you help me please with figuring out how I can achieve all three requirements at the same time?

Kind regards,
Kamil

 

Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 14:19
Do: [hidden email]
Temat: Authentication with configuration: Bundle vs DeclarativeService?

 

Dear Karaf users,

 

I'm aware that this post is more about OSGi, but you were so helpful so far,

that I hope it will be the same this time :)

 

I have a case with three requirements explained below:

 

1) I must implement "something" (Bundle or Component) that will receive

configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use

both: 

 

a) BundleActivator with ManagedService approach:

 

 

b) DeclarativeService approach:

 

 

2) But the second requirement is, that config MUST be available before

Bundle/Component starts (because my Bundle/Component must authenticate

itself using credentials from the config). Therefore:

 

a) I have no idea how to achieve it using BundleActivator

 

b) Using DeclarativeService approach it is easy:

 

 

3) And the third requirement is: if authentication fails - bundle must stop

itself:

 

a) it is easy using BundleActivator, because if start method throws

exception - Bundle stops itself

 

 

b) I have no idea how to achieve it using DeclarativeService (let's say that

there is just one service per bundle)

 

 

Could you help me please with figuring out how I can achieve all three

requirements at the same time?

 

Kind regards,

Kamil

 

 

 

--

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Authentication with configuration: BundlevsDeclarativeService?

David Jencks-2


On Aug 23, 2019, at 8:00 AM, Kamil Paśko <[hidden email]> wrote:

David,
 
> Is the operator creating the account in the authentication service, so that the previously invalid credentials become valid?
 
Exactly
 
> How does your system deal with failures in communication to the authentication service? Is the operator required to restart all the “weather station” bundles? Is it possible to treat “invalid credentials” the same as “no communication to the authentication service”?
 
In both cases it’s the same: in case of „no communication” or „invalid credentials” – bundle should stop (with proper message in logs) and should not send any data
So neither  bundle, nor the  service have any state. If bundle  can not authenticate itself – it just stops.
 
> Can you use the service presence rather than the bundle state to determine “health”?
 
I don’t quite understand that

There may be other points of view than mine….
The osgi systems I’ve worked with all used bundle state to indicate whether the bundle wiring was satisfactory.  Then, services were made available based on whether the configuration and required dependent services were available. If I understand correctly, you want to use bundle state to indicate whether a required configuration is present, whether communication with a remote service is operational, and whether a particular interaction with the remote service returns “OK”.  I don’t think that’s a good division of responsibility.  It’s much easier to flag all these things by registering a service when everything is fine and unregistering it when not.  Services are just as easy to detect as bundles.

If you really need to use a bundle to indicate health, perhaps you could split the problem into two parts: one bundle contains code, for instance a DS component, that has a required configuration; when the component is started  (because the configuration is present) is starts another bundle which, in its bundle activator, tries remote authentication and shuts down if it fails. If the configuration disappears, the component deactivate method can stop the other bundle.

David Jencks

 
Kind regards,
Kamil
 
 
Od: [hidden email]
Wysłano: piątek, 23 sierpnia 2019 16:53
Do: [hidden email]
Temat: Re: Authentication with configuration: BundlevsDeclarativeService?
 
Hi Kamil,
 
Is the operator creating the account in the authentication service, so that the previously invalid credentials become valid?
 
How does your system deal with failures in communication to the authentication service? Is the operator required to restart all the “weather station” bundles? Is it possible to treat “invalid credentials” the same as “no communication to the authentication service”?
 
In any case, with my proposal, restarting the bundle will certainly result in another attempt to authenticate if the configuration is present.  Can you use the service presence rather than the bundle state to determine “health”?
 
David Jencks


On Aug 23, 2019, at 7:07 AM, Kamil Paśko <[hidden email]> wrote:
 
@Dawid,
 
Ok, here’s my situation:
  1. Let’s say I have hundreds of weather stations 
  2. Each weather station gathers different data (some only the temperature, some humidity, some both and some let’s say – radiation). They’re completly independent of each other. Can be deployed separately, have different versions etc. That’s why I represented each weather station as separate bundle in Karaf cluster.
  3. Each weather station sends it’s data to the server using „WeatherService”
  4. But before weather station can send it’s first data – it must use „AuthenticationService” and it’s own Configuration (containing it’s login and password) in order to authenticate itself. If it can not – is should stop and do not send data
  5. Why restarting the bundle helps with authentication? Because Operator can create weather station’s account in the system and restart the bundle – then it’ll authenticate itself successfuly
 
I hope that this explains my situation.
 
Kind regards,
Kamil
 
 
Od: [hidden email]
Wysłano: piątek, 23 sierpnia 2019 15:41
Do: [hidden email]
Temat: Re: ODP: ODP: Authentication with configuration: BundlevsDeclarativeService?
 
Services don’t have state, other than their properties, and you can certainly investigate services with the console. Ds components do have state, which you can investigate using the console.
 
Your answer doesn’t make sense to me yet. What is the nature of the authentication? If it’s entirely self contained then changes to the configuration will be automatically propagated to a configuration-aware component anyway without your doing anything special, and if it relies on some sort of remote service I’d expect your component would be the only reasonable place to track this remote services availability.
 
I don’t recall ever finding a situation where restarting a bundle was a reasonable response.
 
I may not understand your situation...

David Jencks 

Sent from my iPhone


On Aug 23, 2019, at 4:43 AM, Kamil Paśko <[hidden email]> wrote:

@David,
 
Thank you for your answer.
I care „if the bundle is active” because as far as I know, Karaf console and API allows me to check the state of bundles – not particular services. 
Please, correct me if I’m wrong.
 
Moreover - all our monitoring tools verify bundles health, and are able to restart them when bundle will be able to authenticate again.
 
That is why I need to stop whole bundle if authentication fails and I must care about whole bundle – not particular service.
 
Does it make sense?
 
Kind regards,
Kamil
 
Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 16:07
Do: [hidden email]
Temat: Re: ODP: Authentication with configuration: Bundle vsDeclarativeService?
 
I suggest you:
-Reinterpret the 3rd requirement to be that a service is registered only when a configuration is present and that configuration results in valid authentication. Why do you care if the bundle is active? What’s usually important is whether a service is present.
-write a ManagedService as a DS component that authenticates and if successful creates the actual service.
 
David Jencks 
 
Sent from my iPhone


On Aug 19, 2019, at 5:21 AM, Kamil Paśko <[hidden email]> wrote:

I see that my examples where trimmed. So I send them once again:

I have a case with three requirements explained below:

1) I must implement "something" (Bundle or Component) that will receive configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use both:

a) BundleActivator with ManagedService approach:




@Override
public final void start(final BundleContext bundleContext) throws InterruptedException {
  serviceReg = bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
}

b) DeclarativeService approach:




@Component(
    configurationPid = MyService.CONFIGURATION_PID
)
public class MyService {
  @Activate
  public MyService(final MyConfiguration configuration) throws Exception {
  }
}

2) But the second requirement is, that config MUST be available before Bundle/Component starts (because my Bundle/Component must authenticate itself using credentials from the config). Therefore:

a) I have no idea how to achieve it using BundleActivator

b) Using DeclarativeService approach it is easy:




@Component(
    immediate = true,
    configurationPolicy = ConfigurationPolicy.REQUIRE,
    configurationPid = MyService.CONFIGURATION_PID
)

3) And the third requirement is: if authentication fails - bundle must stop itself:

a) it is easy using BundleActivator, because if start method throws exception - Bundle stops itself




  @Override
  public final void start(final BundleContext bundleContext) throws InterruptedException {
    bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
  }
 
  private final class ConfigUpdater implements ManagedService {
      @Override
      public void updated(final Dictionary<String, ?> config) throws ConfigurationException {
        if (authenticate(config) == false) {
          throw new NotAuthenticatedException();
        }
      }
   }
}

b) I have no idea how to achieve it using DeclarativeService (let's say that there is just one service per bundle)


Could you help me please with figuring out how I can achieve all three requirements at the same time?

Kind regards,
Kamil
 
Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 14:19
Do: [hidden email]
Temat: Authentication with configuration: Bundle vs DeclarativeService?
 
Dear Karaf users,
 
I'm aware that this post is more about OSGi, but you were so helpful so far,
that I hope it will be the same this time :)
 
I have a case with three requirements explained below:
 
1) I must implement "something" (Bundle or Component) that will receive
configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use
both: 
 
a) BundleActivator with ManagedService approach:
 
 
b) DeclarativeService approach:
 
 
2) But the second requirement is, that config MUST be available before
Bundle/Component starts (because my Bundle/Component must authenticate
itself using credentials from the config). Therefore:
 
a) I have no idea how to achieve it using BundleActivator
 
b) Using DeclarativeService approach it is easy:
 
 
3) And the third requirement is: if authentication fails - bundle must stop
itself:
 
a) it is easy using BundleActivator, because if start method throws
exception - Bundle stops itself
 
 
b) I have no idea how to achieve it using DeclarativeService (let's say that
there is just one service per bundle)
 
 
Could you help me please with figuring out how I can achieve all three
requirements at the same time?
 
Kind regards,
Kamil
 
 
 
--

Reply | Threaded
Open this post in threaded view
|

ODP: Authentication with configuration: BundlevsDeclarativeService?

kamilantlgc

David,

 

On Aug 23, 2019, at 8:00 AM, wrote:

 

David,

 

> Is the operator creating the account in the authentication service, so that the previously invalid credentials become valid?

 

Exactly

 

> How does your system deal with failures in communication to the authentication service? Is the operator required to restart all the “weather station” bundles? Is it possible to treat “invalid credentials” the same as “no communication to the authentication service”?

 

In both cases it’s the same: in case of „no communication” or „invalid credentials” – bundle should stop (with proper message in logs) and should not send any data

So neither  bundle, nor the  service have any state. If bundle  can not authenticate itself – it just stops.

 

> Can you use the service presence rather than the bundle state to determine “health”?

 

I don’t quite understand that

 

There may be other points of view than mine….

The osgi systems I’ve worked with all used bundle state to indicate whether the bundle wiring was satisfactory.  

 

By „Bundle state” you mean „Active", „Waiting”, „Resolved”?

 

Then, services were made available based on whether the configuration and required dependent services were available. If I understand correctly, you want to use bundle state to indicate whether a required configuration is present, whether communication with a remote service is operational, and whether a particular interaction with the remote service returns “OK”.

 

Yes. I want my bundle to be „Active” only if configuration is present and authentication is successful.

 

I don’t think that’s a good division of responsibility.  It’s much easier to flag all these things by registering a service when everything is fine and unregistering it when not.  Services are just as easy to detect as bundles.

 

But many bundles are using „Authentication service” so why should I unregister „Authentication service” when one of the bundles fail to authenticate itself?

 

If you really need to use a bundle to indicate health, perhaps you could split the problem into two parts: one bundle contains code, for instance a DS component, that has a required configuration; when the component is started  (because the configuration is present) is starts another bundle which, in its bundle activator, tries remote authentication and shuts down if it fails. If the configuration disappears, the component deactivate method can stop the other bundle.

 

That’s a good idea, thanks! Although I think I found another one which might be a little bit easier:

 

@Component(

    immediate = true,

    scope = ServiceScope.BUNDLE,

    configurationPolicy = ConfigurationPolicy.REQUIRE,

    configurationPid = MyComponent.CONFIGURATION_PID

)

public class MyComponent {

  static final String CONFIGURATION_PID = "e8e99fa700d44e7e922c16ea0f0e688f";

 

  @Activate

  public MyComponent (final BundleContext bundleContext, final Map<String, Object> config,

                                     @Reference(cardinality = ReferenceCardinality.MANDATORY) final AuthenticationService authenticationService) {

  if(authenticationService.authenticate() == false) {

      try {

        bundleContext.getBundle().stop();

      } catch (final BundleException be) {

        log.error("Error while stopping bundle", be);

      }

      throw new RuntimeException(e);

    }

  }

 

  @Deactivate

  public void deactivate() {

//cleanup

  }

}

 

And it almost works as expected, with exception to one thing, which I suspect is a Karaf bug:

When I do „bundle:list” bundle is indeed „Resolved” so it seems to be ok (but it’s not).

When I do „bundle:start” – my bundle immediatelly becomes „Active” and does not activate MyComponent again!

But when I do bundle:stop (nothing happens again) and then bundle:start again, then MyComponent is activated properly and tries to authenticate itself again.

 

Do you think it’s indeed a Karaf bug?

 

Kind regards,

Kamil

 

 

David Jencks

 

Kind regards,

Kamil

 

 

Od: [hidden email]
Wysłano: piątek, 23 sierpnia 2019 16:53
Do: [hidden email]
Temat: Re: Authentication with configuration: BundlevsDeclarativeService?

 

Hi Kamil,

 

Is the operator creating the account in the authentication service, so that the previously invalid credentials become valid?

 

How does your system deal with failures in communication to the authentication service? Is the operator required to restart all the “weather station” bundles? Is it possible to treat “invalid credentials” the same as “no communication to the authentication service”?

 

In any case, with my proposal, restarting the bundle will certainly result in another attempt to authenticate if the configuration is present.  Can you use the service presence rather than the bundle state to determine “health”?

 

David Jencks




On Aug 23, 2019, at 7:07 AM, Kamil Paśko <[hidden email]> wrote:

 

@Dawid,

 

Ok, here’s my situation:

  1. Let’s say I have hundreds of weather stations 
  2. Each weather station gathers different data (some only the temperature, some humidity, some both and some let’s say – radiation). They’re completly independent of each other. Can be deployed separately, have different versions etc. That’s why I represented each weather station as separate bundle in Karaf cluster.
  3. Each weather station sends it’s data to the server using „WeatherService”
  4. But before weather station can send it’s first data – it must use „AuthenticationService” and it’s own Configuration (containing it’s login and password) in order to authenticate itself. If it can not – is should stop and do not send data
  5. Why restarting the bundle helps with authentication? Because Operator can create weather station’s account in the system and restart the bundle – then it’ll authenticate itself successfuly

 

I hope that this explains my situation.

 

Kind regards,

Kamil

 

 

Od: [hidden email]
Wysłano: piątek, 23 sierpnia 2019 15:41
Do: [hidden email]
Temat: Re: ODP: ODP: Authentication with configuration: BundlevsDeclarativeService?

 

Services don’t have state, other than their properties, and you can certainly investigate services with the console. Ds components do have state, which you can investigate using the console.

 

Your answer doesn’t make sense to me yet. What is the nature of the authentication? If it’s entirely self contained then changes to the configuration will be automatically propagated to a configuration-aware component anyway without your doing anything special, and if it relies on some sort of remote service I’d expect your component would be the only reasonable place to track this remote services availability.

 

I don’t recall ever finding a situation where restarting a bundle was a reasonable response.

 

I may not understand your situation...

David Jencks 

Sent from my iPhone


On Aug 23, 2019, at 4:43 AM, Kamil Paśko <[hidden email]> wrote:

@David,

 

Thank you for your answer.

I care „if the bundle is active” because as far as I know, Karaf console and API allows me to check the state of bundles – not particular services. 

Please, correct me if I’m wrong.

 

Moreover - all our monitoring tools verify bundles health, and are able to restart them when bundle will be able to authenticate again.

 

That is why I need to stop whole bundle if authentication fails and I must care about whole bundle – not particular service.

 

Does it make sense?

 

Kind regards,

Kamil

 

Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 16:07
Do: [hidden email]
Temat: Re: ODP: Authentication with configuration: Bundle vsDeclarativeService?

 

I suggest you:

-Reinterpret the 3rd requirement to be that a service is registered only when a configuration is present and that configuration results in valid authentication. Why do you care if the bundle is active? What’s usually important is whether a service is present.

-write a ManagedService as a DS component that authenticates and if successful creates the actual service.

 

David Jencks 

 

Sent from my iPhone


On Aug 19, 2019, at 5:21 AM, Kamil Paśko <[hidden email]> wrote:

I see that my examples where trimmed. So I send them once again:


I have a case with three requirements explained below:

1) I must implement "something" (Bundle or Component) that will receive configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use both:

a) BundleActivator with ManagedService approach:





@Override
public final void start(final BundleContext bundleContext) throws InterruptedException {
  serviceReg = bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
}


b) DeclarativeService approach:





@Component(
    configurationPid = MyService.CONFIGURATION_PID
)
public class MyService {
  @Activate
  public MyService(final MyConfiguration configuration) throws Exception {
  }
}


2) But the second requirement is, that config MUST be available before Bundle/Component starts (because my Bundle/Component must authenticate itself using credentials from the config). Therefore:

a) I have no idea how to achieve it using BundleActivator

b) Using DeclarativeService approach it is easy:





@Component(
    immediate = true,
    configurationPolicy = ConfigurationPolicy.REQUIRE,
    configurationPid = MyService.CONFIGURATION_PID
)


3) And the third requirement is: if authentication fails - bundle must stop itself:

a) it is easy using BundleActivator, because if start method throws exception - Bundle stops itself





  @Override
  public final void start(final BundleContext bundleContext) throws InterruptedException {
    bundleContext.registerService(ManagedService.class, new ConfigUpdater(), new Hashtable<>(singletonMap(Constants.SERVICE_PID, pid)));
  }
 
  private final class ConfigUpdater implements ManagedService {
      @Override
      public void updated(final Dictionary<String, ?> config) throws ConfigurationException {
        if (authenticate(config) == false) {
          throw new NotAuthenticatedException();
        }
      }
   }
}


b) I have no idea how to achieve it using DeclarativeService (let's say that there is just one service per bundle)


Could you help me please with figuring out how I can achieve all three requirements at the same time?

Kind regards,
Kamil

 

Od: [hidden email]
Wysłano: poniedziałek, 19 sierpnia 2019 14:19
Do: [hidden email]
Temat: Authentication with configuration: Bundle vs DeclarativeService?

 

Dear Karaf users,

 

I'm aware that this post is more about OSGi, but you were so helpful so far,

that I hope it will be the same this time :)

 

I have a case with three requirements explained below:

 

1) I must implement "something" (Bundle or Component) that will receive

configuration (placed in $KARAF_HOME/etc/myPID.cfg), therefore I can use

both: 

 

a) BundleActivator with ManagedService approach:

 

 

b) DeclarativeService approach:

 

 

2) But the second requirement is, that config MUST be available before

Bundle/Component starts (because my Bundle/Component must authenticate

itself using credentials from the config). Therefore:

 

a) I have no idea how to achieve it using BundleActivator

 

b) Using DeclarativeService approach it is easy:

 

 

3) And the third requirement is: if authentication fails - bundle must stop

itself:

 

a) it is easy using BundleActivator, because if start method throws

exception - Bundle stops itself

 

 

b) I have no idea how to achieve it using DeclarativeService (let's say that

there is just one service per bundle)

 

 

Could you help me please with figuring out how I can achieve all three

requirements at the same time?

 

Kind regards,

Kamil

 

 

 

--