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>
> 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
> 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
