:-)

> On 13 Mar 2017, at 16:21, Daghan ACAY <daghana...@hotmail.com> 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 <http://www.mail-wise.com/installation/2> – See your emails 
> as clean, short chats.
> 
> 
> 
> -------- Original Message --------
> From: Peter Kriens <peter.kri...@aqute.biz>
> Sent: Monday, March 13, 2017 07:25 PM
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Subject: Re: [osgi-dev] Building a "profile" system with declarative services 
> and configuration admin?
> 
>> On 13 Mar 2017, at 12:57, Daghan ACAY <daghana...@hotmail.com 
>> <mailto:daghana...@hotmail.com>> 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: list+org.o...@io7m.com <mailto:list+org.o...@io7m.com>
>> Sent: Monday, March 13, 2017 03:05 PM
>> To: Peter Kriens <peter.kri...@aqute.biz <mailto:peter.kri...@aqute.biz>>
>> Subject: Re: [osgi-dev] Building a "profile" system with declarative 
>> services and configuration admin?
>> CC: OSGi Developer Mail List <osgi-dev@mail.osgi.org 
>> <mailto:osgi-dev@mail.osgi.org>>
>> 
>> On 2017-03-13T09:03:49 +0100
>> Peter Kriens <peter.kri...@aqute.biz <mailto:peter.kri...@aqute.biz>> 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
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

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

Reply via email to