Hi Tim,
> In summary, don’t try to pass functions using service properties, use
> services because it’s what they are for.
Hmmmm. Ok, interesting point. I’ll have to dwell on that a little more, but I
think it makes sense.
Thanks a lot for the suggestions. I think it puts me on the right path.
Cheers,
=David
> On Jul 16, 2018, at 16:16, Tim Ward <tim.w...@paremus.com> wrote:
>
> I think what you’re looking for is DS!
>
> Take the following (apologies for classes typed in email, these may be
> missing semicolons etc)"
>
> @Component(configurationPid=“my.class”, configurationPolicy=REQUIRE)
> public class MyClass {
>
> @Reference
> ScriptFunction function;
>
> // Rest of your implementation in here
>
> }
>
> @Component(configurationPid=“my.function”, configurationPolicy=REQUIRE)
> public class FunctionComponent implements ScriptFunction {
>
> @Config {
> String[] script() default {“return”};
>
> boolean chained() default false;
> }
>
> @Reference(cardinality=OPTIONAL)
> ScriptFunction function;
>
> @Activate
> Void start(Config config) {
> // Get the script and set up the ScriptEngine
> }
>
> @Override
> public Object execute(Object[] args) {
> // run the function, and if chained, apply the next function
> }
> }
>
> Then use configurations to set up the functions:
>
> // Target your component at the start
> my.class: {
> “function.target”: “(name=start)"
> },
>
> // Set up the start function and make its reference mandatory
> "my.function~start”: {
> “name”: “start”,
> “script”: “return args[0] + 1”,
> “chained”: true,
> “function.target”: “(name=end)”,
> “function.cardinality.minimum”: 1
> },
>
> // Set up an end function
> "my.function~start”: {
> “name”: “end”,
> “script”: “return args[0] * 7”
> }
>
>
> All done with configuration, and probably 100 lines of code. In summary,
> don’t try to pass functions using service properties, use services because
> it’s what they are for. You can then make it easy to add configurable
> scripting functions, optimised native functions, or whatever else you want to
> apply!
>
> Best Regards,
>
> Tim
>
>> On 16 Jul 2018, at 02: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
