> On 16 Jul 2018, at 22:47, David Leangen via osgi-dev <[email protected]>
> wrote:
> Thanks Peter.
> Could you please expand on what you mean by this?
>> Notice that you can easily share (non managed service) configurations
>> between components.
You can get the configuration from different PIDs in your component. The
`configurationPid` method in the @Component annotation takes multiple
arguments. I recall that the first is a factory pid, the others are normal
managed service pids. (Only 1 pid can control the life cycle.)
This allows you to create shared configuration between different components.
You probably need to read up on the spec about the details …
Kind regards,
Peter Kriens
> 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 <[email protected]
>> <mailto:[email protected]>> 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
>>> <[email protected] <mailto:[email protected]>> 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 <[email protected]
>>>> <mailto:[email protected]>> 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
>>>>> <[email protected] <mailto:[email protected]>> 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 <[email protected]
>>>>>> <mailto:[email protected]>> 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
>>>>>> [email protected] <mailto:[email protected]>
>>>>>>
>>>>>>
>>>>>> ----- Original message -----
>>>>>> From: David Leangen via osgi-dev <[email protected]
>>>>>> <mailto:[email protected]>>
>>>>>> Sent by: [email protected]
>>>>>> <mailto:[email protected]>
>>>>>> To: David Leangen via osgi-dev <[email protected]
>>>>>> <mailto:[email protected]>>
>>>>>> 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
>>>>>> [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] <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] <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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
