Re: [osgi-dev] Building a "profile" system with declarative services and configuration admin?

[Peter Kriens]

:-)

> On 13 Mar 2017, at 16:21, Daghan ACAY  wrote:
> 
> Thanks for your comments. I agree the last one was an edge case and not very 
> useful in practical scenarios. It was only question to understand life cycle 
> in a better way and not abuse it unnecessarily.
> 
> Regards
> - Daghan
> 
> Sent by MailWise  – See your emails 
> as clean, short chats.
> 
> 
> 
>  Original Message 
> From: Peter Kriens 
> Sent: Monday, March 13, 2017 07:25 PM
> To: OSGi Developer Mail List 
> Subject: Re: [osgi-dev] Building a "profile" system with declarative services 
> and configuration admin?
> 
>> On 13 Mar 2017, at 12:57, Daghan ACAY > > wrote:
>> Hi peter,
>> 
>> As a clarification, i can see this design allows multiple ProfileRunner 
>> instances (actually as  many as IRCProfile configurations) at runtime where 
>> each ProfileRunner has zero or more IRFfilters whose properties obeys the 
>> LDAP filter defined by the filters_target value. Now for each ProfileRunner 
>> instance filters_target value can be configured at runtime through web 
>> console or @ConfigurerExtender using filters.target in json. Am i right?
>> 
> Yes
>> My second clarification is about life cycle of ProfileRunner. If i change 
>> the IRCProfile configuration of an existing ProfileRunner instance then that 
>> instance will be recreated and IRFFilters will be injected to the newly 
>> created instance. Am i right?
>> 
> Yes
>> Now two tricky ones. 
>> 
>> 1- if we had defined configuration for IRFFilter as you have suggested and 
>> assume we have for a single IRFFilter component e.g "filter=log". Again 
>> assume this IRFFilter instance  is already injected to one of the existing 
>> ProfileRunner instance. If i change the IRFFilter component’s property to 
>> "filter=uppercase", is this IRFFilter removed from the List 
>> without destroying the existing ProfileRunner instance?
> Yes because it is a volatile list. This makes the reference dynamic
> 
>> 2- If you had @updated method defined for ProfileRunner and changed the 
>> filters_target value for an existing ProfileRunner instance from 
>> (filter=uppercase) to (filter=log), what happens to the List 
>> member, are they refreshed according to the new filters_target value, 
>> without destroying the existing ProfileRunner instance?
>> 
> I expect they should be updated dynamically but I am not a 100% sure about 
> it. And if I felt this was an important distinction I might read through the 
> spec, but to be honest, who cares? I would never optimize a system to prevent 
> an object from being recreated until I had a real problem. Recreating an 
> object works very nice and imho has hardly any consequences in a well 
> designed OSGi system.
> 
> Kind regards,
> 
> Peter Kriens
> 
> 
>> Thanks in advance. 
>> 
>> -daghan
>> 
>> Sent by MailWise  – See your emails 
>> as clean, short chats.
>> 
>> 
>> 
>>  Original Message 
>> From: list+org.o...@io7m.com 
>> Sent: Monday, March 13, 2017 03:05 PM
>> To: Peter Kriens >
>> Subject: Re: [osgi-dev] Building a "profile" system with declarative 
>> services and configuration admin?
>> CC: OSGi Developer Mail List > >
>> 
>> On 2017-03-13T09:03:49 +0100
>> Peter Kriens > wrote:
>> 
>> > Just use configuration admin. So first define your profile configuration:
>> > 
>> >@ObjectClassDefinition
>> >@interface IRCProfile {
>> >String username();
>> >String password();
>> >String host();
>> >String filters_target() default “(filter=uppercase)“;
>> >}
>> > 
>> > You then create a a runner that does the work:
>> > 
>> >@Designate( ocd= IRCProfile.class, factory=true )
>> >@Component(service=ProfileRunner.class)
>> >public class ProfileRunner {
>> > 
>> >@Reference
>> >volatile List filters;
>> >
>> >@Activate
>> >void activate( IRCProfile profile ) {
>> >…
>> >// start a thread?
>> >}
>> > 
>> >}
>> > 
>> > This runner can now be created as many times as you want with WebConsole. 
>> > Each configuration you create is automatically cause a ProfileRunner to be 
>> > instantiated when its filters are registered. The filters are coupled to 
>> > the component via the `filters.target` configuration field. The default 
>> > currently shows that it needs the ‘uppercase’ filter. However, with the or 
>> > (|) operator you can make it any number of filters: 
>> > 

Re: [osgi-dev] Building a "profile" system with declarative services and configuration admin?

[Daghan ACAY]

Thanks for your comments. I agree the last one was an edge case and not very 
useful in practical scenarios. It was only question to understand life cycle in 
a better way and not abuse it unnecessarily.

Regards
- Daghan

Sent by MailWise – See your emails as 
clean, short chats.


 Original Message 
From: Peter Kriens 
Sent: Monday, March 13, 2017 07:25 PM
To: OSGi Developer Mail List 
Subject: Re: [osgi-dev] Building a "profile" system with declarative services 
and configuration admin?

On 13 Mar 2017, at 12:57, Daghan ACAY 
> wrote:

Hi peter,

As a clarification, i can see this design allows multiple ProfileRunner 
instances (actually as  many as IRCProfile configurations) at runtime where 
each ProfileRunner has zero or more IRFfilters whose properties obeys the LDAP 
filter defined by the filters_target value. Now for each ProfileRunner instance 
filters_target value can be configured at runtime through web console or 
@ConfigurerExtender using filters.target in json. Am i right?

Yes

My second clarification is about life cycle of ProfileRunner. If i change the 
IRCProfile configuration of an existing ProfileRunner instance then that 
instance will be recreated and IRFFilters will be injected to the newly created 
instance. Am i right?

Yes

Now two tricky ones.

1- if we had defined configuration for IRFFilter as you have suggested and 
assume we have for a single IRFFilter component e.g "filter=log". Again assume 
this IRFFilter instance  is already injected to one of the existing 
ProfileRunner instance. If i change the IRFFilter component’s property to 
"filter=uppercase", is this IRFFilter removed from the List without 
destroying the existing ProfileRunner instance?

Yes because it is a volatile list. This makes the reference dynamic


2- If you had @updated method defined for ProfileRunner and changed the 
filters_target value for an existing ProfileRunner instance from 
(filter=uppercase) to (filter=log), what happens to the List member, 
are they refreshed according to the new filters_target value, without 
destroying the existing ProfileRunner instance?

I expect they should be updated dynamically but I am not a 100% sure about it. 
And if I felt this was an important distinction I might read through the spec, 
but to be honest, who cares? I would never optimize a system to prevent an 
object from being recreated until I had a real problem. Recreating an object 
works very nice and imho has hardly any consequences in a well designed OSGi 
system.

Kind regards,

Peter Kriens



Thanks in advance.

-daghan


Sent by MailWise – See your emails as 
clean, short chats.


 Original Message 
From: list+org.o...@io7m.com
Sent: Monday, March 13, 2017 03:05 PM
To: Peter Kriens >
Subject: Re: [osgi-dev] Building a "profile" system with declarative services 
and configuration admin?
CC: OSGi Developer Mail List 
>

On 2017-03-13T09:03:49 +0100
Peter Kriens > wrote:

> Just use configuration admin. So first define your profile configuration:
>
>@ObjectClassDefinition
>@interface IRCProfile {
>String username();
>String password();
>String host();
>String filters_target() default “(filter=uppercase)“;
>}
>
> You then create a a runner that does the work:
>
>@Designate( ocd= IRCProfile.class, factory=true )
>@Component(service=ProfileRunner.class)
>public class ProfileRunner {
>
>@Reference
>volatile List filters;
>
>@Activate
>void activate( IRCProfile profile ) {
>…
>// start a thread?
>}
>
>}
>
> This runner can now be created as many times as you want with WebConsole. 
> Each configuration you create is automatically cause a ProfileRunner to be 
> instantiated when its filters are registered. The filters are coupled to the 
> component via the `filters.target` configuration field. The default currently 
> shows that it needs the ‘uppercase’ filter. However, with the or (|) operator 
> you can make it any number of filters: (|(filter=uppercase)(filter=log)). If 
> you need ordering in the filters, use the service.ranking property on the 
> filter components.
>
> You can now make any number of filters that look like:
>
>@Component( property={“filter=uppercase”, “service.ranking=-100”})
>public class UpperCaseFilter implements IRCFilterType {
>
>String process( String s) {
>return s.toUpperCase();
>  

Re: [osgi-dev] Building a "profile" system with declarative services and configuration admin?

[Peter Kriens]

> On 13 Mar 2017, at 12:57, Daghan ACAY  wrote:
> Hi peter,
> 
> As a clarification, i can see this design allows multiple ProfileRunner 
> instances (actually as  many as IRCProfile configurations) at runtime where 
> each ProfileRunner has zero or more IRFfilters whose properties obeys the 
> LDAP filter defined by the filters_target value. Now for each ProfileRunner 
> instance filters_target value can be configured at runtime through web 
> console or @ConfigurerExtender using filters.target in json. Am i right?
> 
Yes
> My second clarification is about life cycle of ProfileRunner. If i change the 
> IRCProfile configuration of an existing ProfileRunner instance then that 
> instance will be recreated and IRFFilters will be injected to the newly 
> created instance. Am i right?
> 
Yes
> Now two tricky ones. 
> 
> 1- if we had defined configuration for IRFFilter as you have suggested and 
> assume we have for a single IRFFilter component e.g "filter=log". Again 
> assume this IRFFilter instance  is already injected to one of the existing 
> ProfileRunner instance. If i change the IRFFilter component’s property to 
> "filter=uppercase", is this IRFFilter removed from the List 
> without destroying the existing ProfileRunner instance?
> 
Yes because it is a volatile list. This makes the reference dynamic

> 2- If you had @updated method defined for ProfileRunner and changed the 
> filters_target value for an existing ProfileRunner instance from 
> (filter=uppercase) to (filter=log), what happens to the List 
> member, are they refreshed according to the new filters_target value, without 
> destroying the existing ProfileRunner instance?
> 
I expect they should be updated dynamically but I am not a 100% sure about it. 
And if I felt this was an important distinction I might read through the spec, 
but to be honest, who cares? I would never optimize a system to prevent an 
object from being recreated until I had a real problem. Recreating an object 
works very nice and imho has hardly any consequences in a well designed OSGi 
system.

Kind regards,

Peter Kriens


> Thanks in advance. 
> 
> -daghan
> 
> 
> Sent by MailWise  – See your emails 
> as clean, short chats.
> 
> 
> 
>  Original Message 
> From: list+org.o...@io7m.com
> Sent: Monday, March 13, 2017 03:05 PM
> To: Peter Kriens 
> Subject: Re: [osgi-dev] Building a "profile" system with declarative services 
> and configuration admin?
> CC: OSGi Developer Mail List 
> 
> On 2017-03-13T09:03:49 +0100
> Peter Kriens  wrote:
> 
> > Just use configuration admin. So first define your profile configuration:
> > 
> >@ObjectClassDefinition
> >@interface IRCProfile {
> >String username();
> >String password();
> >String host();
> >String filters_target() default “(filter=uppercase)“;
> >}
> > 
> > You then create a a runner that does the work:
> > 
> >@Designate( ocd= IRCProfile.class, factory=true )
> >@Component(service=ProfileRunner.class)
> >public class ProfileRunner {
> > 
> >@Reference
> >volatile List filters;
> >
> >@Activate
> >void activate( IRCProfile profile ) {
> >…
> >// start a thread?
> >}
> > 
> >}
> > 
> > This runner can now be created as many times as you want with WebConsole. 
> > Each configuration you create is automatically cause a ProfileRunner to be 
> > instantiated when its filters are registered. The filters are coupled to 
> > the component via the `filters.target` configuration field. The default 
> > currently shows that it needs the ‘uppercase’ filter. However, with the or 
> > (|) operator you can make it any number of filters: 
> > (|(filter=uppercase)(filter=log)). If you need ordering in the filters, use 
> > the service.ranking property on the filter components.
> > 
> > You can now make any number of filters that look like:
> > 
> >@Component( property={“filter=uppercase”, “service.ranking=-100”}) 
> >public class UpperCaseFilter implements IRCFilterType {
> > 
> >String process( String s) {
> >return s.toUpperCase();
> >}
> >}
> > 
> > I do not think you need anything more? Of course your IRCFilterType are now 
> > components so they can be configured independently in a similar vein as the 
> > ProfileRunner.
> 
> Interesting, thanks!
> 
> I'm reading through the DS spec right now and I'm not sure I understand
> how the filters_target() method ends up coupling the components. I
> understand how filters work, I'm just not sure how the OSGi runtime
> knows to use that method...
> 
> The rest seems fairly straightforward.
> 
> > 

Re: [osgi-dev] Building a "profile" system with declarative services and configuration admin?

[Daghan ACAY]

Hi peter,

As a clarification, i can see this design allows multiple ProfileRunner 
instances (actually as  many as IRCProfile configurations) at runtime where 
each ProfileRunner has zero or more IRFfilters whose properties obeys the LDAP 
filter defined by the filters_target value. Now for each ProfileRunner instance 
filters_target value can be configured at runtime through web console or 
@ConfigurerExtender using filters.target in json. Am i right?

My second clarification is about life cycle of ProfileRunner. If i change the 
IRCProfile configuration of an existing ProfileRunner instance then that 
instance will be recreated and IRFFilters will be injected to the newly created 
instance. Am i right?

Now two tricky ones.

1- if we had defined configuration for IRFFilter as you have suggested and 
assume we have for a single IRFFilter component e.g "filter=log". Again assume 
this IRFFilter instance  is already injected to one of the existing 
ProfileRunner instance. If i change the IRFFilter component's property to 
"filter=uppercase", is this IRFFilter removed from the List without 
destroying the existing ProfileRunner instance?

2- If you had @updated method defined for ProfileRunner and changed the 
filters_target value for an existing ProfileRunner instance from 
(filter=uppercase) to (filter=log), what happens to the List member, 
are they refreshed according to the new filters_target value, without 
destroying the existing ProfileRunner instance?

Thanks in advance.

-daghan


Sent by MailWise – See your emails as 
clean, short chats.


 Original Message 
From: list+org.o...@io7m.com
Sent: Monday, March 13, 2017 03:05 PM
To: Peter Kriens 
Subject: Re: [osgi-dev] Building a "profile" system with declarative services 
and configuration admin?
CC: OSGi Developer Mail List 

On 2017-03-13T09:03:49 +0100
Peter Kriens  wrote:

> Just use configuration admin. So first define your profile configuration:
>
>@ObjectClassDefinition
>@interface IRCProfile {
>String username();
>String password();
>String host();
>String filters_target() default “(filter=uppercase)“;
>}
>
> You then create a a runner that does the work:
>
>@Designate( ocd= IRCProfile.class, factory=true )
>@Component(service=ProfileRunner.class)
>public class ProfileRunner {
>
>@Reference
>volatile List filters;
>
>@Activate
>void activate( IRCProfile profile ) {
>…
>// start a thread?
>}
>
>}
>
> This runner can now be created as many times as you want with WebConsole. 
> Each configuration you create is automatically cause a ProfileRunner to be 
> instantiated when its filters are registered. The filters are coupled to the 
> component via the `filters.target` configuration field. The default currently 
> shows that it needs the ‘uppercase’ filter. However, with the or (|) operator 
> you can make it any number of filters: (|(filter=uppercase)(filter=log)). If 
> you need ordering in the filters, use the service.ranking property on the 
> filter components.
>
> You can now make any number of filters that look like:
>
>@Component( property={“filter=uppercase”, “service.ranking=-100”})
>public class UpperCaseFilter implements IRCFilterType {
>
>String process( String s) {
>return s.toUpperCase();
>}
>}
>
> I do not think you need anything more? Of course your IRCFilterType are now 
> components so they can be configured independently in a similar vein as the 
> ProfileRunner.

Interesting, thanks!

I'm reading through the DS spec right now and I'm not sure I understand
how the filters_target() method ends up coupling the components. I
understand how filters work, I'm just not sure how the OSGi runtime
knows to use that method...

The rest seems fairly straightforward.

> Having file based configuration is always a bad smell in OSGi. Configuration 
> Admin looks different from what most developers know but it is quite powerful.

To be clear, I was referring to the property files that back Felix's
implementation of the Configuration Admin service. The implementation
appears to want one configuration file per service PID, so in a system
with a lot of components, that can mean a lot of separate configuration
files. That ends up being a fairly user-hostile thing in a system like
this because the user then has to understand service PIDs and know what
all of them are for the components in order to configure the client.

M
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Building a "profile" system with declarative services and configuration admin?

[list+org . osgi]

On 2017-03-13T09:03:49 +0100
Peter Kriens  wrote:

> Just use configuration admin. So first define your profile configuration:
> 
>   @ObjectClassDefinition
>   @interface IRCProfile {
>   String username();
>   String password();
>   String host();
>   String filters_target() default “(filter=uppercase)“;
>   }
> 
> You then create a a runner that does the work:
> 
>   @Designate( ocd= IRCProfile.class, factory=true )
>   @Component(service=ProfileRunner.class)
>   public class ProfileRunner {
> 
>   @Reference
>   volatile List filters;
>   
>   @Activate
>   void activate( IRCProfile profile ) {
>   …
>   // start a thread?
>   }
> 
>   }
> 
> This runner can now be created as many times as you want with WebConsole. 
> Each configuration you create is automatically cause a ProfileRunner to be 
> instantiated when its filters are registered. The filters are coupled to the 
> component via the `filters.target` configuration field. The default currently 
> shows that it needs the ‘uppercase’ filter. However, with the or (|) operator 
> you can make it any number of filters: (|(filter=uppercase)(filter=log)). If 
> you need ordering in the filters, use the service.ranking property on the 
> filter components.
> 
> You can now make any number of filters that look like:
> 
>   @Component( property={“filter=uppercase”, “service.ranking=-100”}) 
>   public class UpperCaseFilter implements IRCFilterType {
> 
>   String process( String s) {
>   return s.toUpperCase();
>   }
>   }
> 
> I do not think you need anything more? Of course your IRCFilterType are now 
> components so they can be configured independently in a similar vein as the 
> ProfileRunner.

Interesting, thanks!

I'm reading through the DS spec right now and I'm not sure I understand
how the filters_target() method ends up coupling the components. I
understand how filters work, I'm just not sure how the OSGi runtime
knows to use that method...

The rest seems fairly straightforward.

> Having file based configuration is always a bad smell in OSGi. Configuration 
> Admin looks different from what most developers know but it is quite powerful.

To be clear, I was referring to the property files that back Felix's
implementation of the Configuration Admin service. The implementation
appears to want one configuration file per service PID, so in a system
with a lot of components, that can mean a lot of separate configuration
files. That ends up being a fairly user-hostile thing in a system like
this because the user then has to understand service PIDs and know what
all of them are for the components in order to configure the client.

M


pgpIYxaagusTv.pgp
Description: OpenPGP digital signature
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Building a "profile" system with declarative services and configuration admin?

[Peter Kriens]

Just use configuration admin. So first define your profile configuration:

@ObjectClassDefinition
@interface IRCProfile {
String username();
String password();
String host();
String filters_target() default “(filter=uppercase)“;
}

You then create a a runner that does the work:

@Designate( ocd= IRCProfile.class, factory=true )
@Component(service=ProfileRunner.class)
public class ProfileRunner {

@Reference
volatile List filters;

@Activate
void activate( IRCProfile profile ) {
…
// start a thread?
}

}

This runner can now be created as many times as you want with WebConsole. Each 
configuration you create is automatically cause a ProfileRunner to be 
instantiated when its filters are registered. The filters are coupled to the 
component via the `filters.target` configuration field. The default currently 
shows that it needs the ‘uppercase’ filter. However, with the or (|) operator 
you can make it any number of filters: (|(filter=uppercase)(filter=log)). If 
you need ordering in the filters, use the service.ranking property on the 
filter components.

You can now make any number of filters that look like:

@Component( property={“filter=uppercase”, “service.ranking=-100”}) 
public class UpperCaseFilter implements IRCFilterType {

String process( String s) {
return s.toUpperCase();
}
}

I do not think you need anything more? Of course your IRCFilterType are now 
components so they can be configured independently in a similar vein as the 
ProfileRunner.

Having file based configuration is always a bad smell in OSGi. Configuration 
Admin looks different from what most developers know but it is quite powerful.

Kind regards,

Peter Kriens



> On 12 Mar 2017, at 21:52, list+org.o...@io7m.com wrote:
> 
> Hello.
> 
> I'm putting together a small experimental application (an IRC client)
> and would like to fundamentally base it on the idea of _profiles_. A
> profile in this case is basically a set of configuration options such
> as the username, IRC server address, a set of filters, a configuration
> for logging, etc. There can be [0, n] profiles active at any given time.
> A "filter" in this case can be thought of as a function that's evaluated
> for each received message (possibly only for the function's side
> effects). In practice, it'd be an implementation of a published
> IRCFilterType interface.
> 
> I'm running up against various architectural questions.
> 
> I think what I should do is create a Profile component that
> instantiates a tree of services/components in the whiteboard pattern: A
> component for maintaining a connection to an IRC server, a component
> that handles logging of messages, a set of components for filtering,
> etc, etc.
> 
> In my case, I'm using Felix as the OSGi container and I think what I
> need to do is create various configuration files in a directory
> monitored by the fileinstall and configuration admin services.
> For example, if the directory is "etc", then:
> 
>  etc/com.io7m.eirc.logger-PROFILE1.cfg
> 
> ... results in an instantiation of the component with service pid
> "com.io7m.eirc.logger". However, it doesn't seem like anything in the
> OSGi standards allow me to get access to the "PROFILE1" name. I'm not
> sure if this is deliberate, or an oversight, or something else.
> 
> It seems like I'd quickly need a ton of different configuration files
> and am not sure how it would be obvious to the user how all of the
> configuration files are tied together to form a profile. Do I need to
> declare some form of "profile identifier" myself? What happens if, for
> example, I want to instantiate two instances of the same component with
> different configurations within a single profile?
> 
> Is there some way to express "instantiate all required components
> that have an application-specific profile ID of P" with declarative
> services? I feel like, normally, the answer would be filtering based on
> a given "profile ID" property. In my case, though, the value of the
> property would only be known at run-time and therefore I couldn't do
> this purely through annotations.
> 
> What happens if the configuration data for a specific component is
> missing? With the configuration data spread over multiple files, can I
> get good error reporting in that case? I suspect what I'd get is
> basically silent failure... A required component can't be started up,
> so everything just sits there doing nothing.
> 
> M
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

___
OSGi Developer Mail