Thanks Peter. Could you please expand on what you mean by this?
> Notice that you can easily share (non managed service) configurations between > components. Also, thanks a lot for this: > BTW, I updated the v2archive.osgi.enroute to build again. So the snapshots > are also available now again. I tried to release this version but I did not > have authority. Will try to get that. Cheers, =David > On Jul 16, 2018, at 16:07, Peter Kriens <peter.kri...@aqute.biz> wrote: > > Just be careful with these things. I call it the C++ effect. You get really > thrilled about all the things you could do and how easy life is when you got > that function. Then after a few years when you have it you see that the > complexity went to your lambdas. I did that a lot in C++ from there the name > :-) > > In my experience you want your configuration to be simple and any processing > should be done by the component. Notice that you can easily share (non > managed service) configurations between components. > > BTW, I updated the v2archive.osgi.enroute to build again. So the snapshots > are also available now again. I tried to release this version but I did not > have authority. Will try to get that. > > Kind regards, > > Peter Kriens > >> On 16 Jul 2018, at 03:09, David Leangen via osgi-dev <osgi-dev@mail.osgi.org >> <mailto:osgi-dev@mail.osgi.org>> wrote: >> >> >> Thanks, Peter. That could actually be useful in some cases. >> >> I guess what I’m really looking for right now though is a way to inject a >> lambda function. >> >> I suppose what I could do it have a 2-step configuration: the first step >> would have constant configuration values being read as per usual via the >> Configurator, and my lambdas provided from a Java class (or perhaps parsed >> from a configuration file if I can find a way to do that). Then for the >> second step the two could be combined, put into a Dictionary, and the actual >> service would be instantiated based on the combined constant+lambda >> configuration. >> >> I would ideally like to keep the constants and the lambdas together in a >> configuration file, but maybe that is just not possible right now. >> >> In any case, this sounds very frameworky to me, so I was hoping that >> something like this already exists… >> >> >> Cheers, >> =David >> >> >> >>> On Jul 15, 2018, at 1:01, Peter Kriens <peter.kri...@aqute.biz >>> <mailto:peter.kri...@aqute.biz>> wrote: >>> >>> The v2Archive OSGi enRoute has a Configurer that uses a subset of the bnd >>> Macro language. This supports ${system;..} and ${system_allow_fail}. These >>> take shell command lines. >>> >>> P >>> >>> >>> >>>> On 14 Jul 2018, at 09:07, David Leangen via osgi-dev >>>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote: >>>> >>>> >>>> Thanks, BJ. >>>> >>>> Yeah, right now I am using a Dictionary exactly how you mentioned, but I >>>> am wondering if there is a way to maintain it the same way I do as for my >>>> configurations. >>>> >>>> Has there ever been a discussion about possibly including this type of >>>> thing in the spec? For instance, a spec could include a script (saved in a >>>> configuration file), and the script could be parsed and included in a >>>> Configuration. >>>> >>>> Has nobody ever encountered this use case? If you have, how did you solve >>>> it? >>>> >>>> >>>> Cheers, >>>> =David >>>> >>>> >>>>> On Jul 14, 2018, at 5:04, BJ Hargrave <hargr...@us.ibm.com >>>>> <mailto:hargr...@us.ibm.com>> wrote: >>>>> >>>>> Component properties are basically service properties which are basically >>>>> meant to be things that can go in a Configuration: >>>>> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#i3217016 >>>>> >>>>> <https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#i3217016>. >>>>> Complex objects including objects implementing functional interfaces are >>>>> not in scope for a Configuration. >>>>> >>>>> That said, I imagine you could pass any value object in the Dictionary >>>>> supplied to ComponentFactory.newInstance since they are not stored in >>>>> Configuration Admin and SCR would not police the value object types :-) >>>>> -- >>>>> >>>>> BJ Hargrave >>>>> Senior Technical Staff Member, IBM // office: +1 386 848 1781 >>>>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 >>>>> hargr...@us.ibm.com <mailto:hargr...@us.ibm.com> >>>>> >>>>> >>>>> ----- Original message ----- >>>>> From: David Leangen via osgi-dev <osgi-dev@mail.osgi.org >>>>> <mailto:osgi-dev@mail.osgi.org>> >>>>> Sent by: osgi-dev-boun...@mail.osgi.org >>>>> <mailto:osgi-dev-boun...@mail.osgi.org> >>>>> To: David Leangen via osgi-dev <osgi-dev@mail.osgi.org >>>>> <mailto:osgi-dev@mail.osgi.org>> >>>>> Cc: >>>>> Subject: [osgi-dev] Functions as configuration >>>>> Date: Fri, Jul 13, 2018 3:32 PM >>>>> >>>>> Hi! >>>>> >>>>> Is there any way to include functions as part of a component >>>>> configuration? >>>>> >>>>> >>>>> Cheers, >>>>> =David >>>>> >>>>> _______________________________________________ >>>>> 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 <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 <mailto: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
