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.

- 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 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<IRFFilter> 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<IRFFilter> 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 

Kind regards,

Peter Kriens

Thanks in advance.


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

-------- Original Message --------
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<IRFFilter> 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 `` 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.

OSGi Developer Mail List<>

OSGi Developer Mail List

Reply via email to