> On 13 Mar 2017, at 12:57, Daghan ACAY <[email protected]> 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<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
system.
Kind regards,
Peter Kriens
> Thanks in advance.
>
> -daghan
>
>
> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails
> as clean, short chats.
>
>
>
> -------- Original Message --------
> From: [email protected]
> Sent: Monday, March 13, 2017 03:05 PM
> To: Peter Kriens <[email protected]>
> Subject: Re: [osgi-dev] Building a "profile" system with declarative services
> and configuration admin?
> CC: OSGi Developer Mail List <[email protected]>
>
> On 2017-03-13T09:03:49 +0100
> Peter Kriens <[email protected]> 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 `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
> [email protected] <mailto:[email protected]>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
