On Thu, Jun 8, 2017 at 6:22 PM, Michael Vorburger <vorbur...@redhat.com>
wrote:
> Abhishek,
>
> On Wed, Jun 7, 2017 at 6:41 AM, abhishek Sharma <
> abhishek.sharma...@yahoo.com> wrote:
>
>> Hello Team,
>>
>> Is there any way to control installation of a feature based upon certain
>> condition?
>>
>
> I don't think this is possible with Karaf. Your email is a little unclear
> though if you would like (a) a feature to be soft of auto installed when a
> certain condition like presence of a configuration file happens; OR (b)
> you'd like to avoid the activation of a feature by a human if a certain
> condition like presence of a configuration file is not met?
>
>
>> As per my use case, the feature should be installed if it gets certain
>> configuration files otherwise it should not allow to install the feature.
>>
>
> That's (b) and even though Karaf's feature management does not have
> anything for this natively, you could probably "emulate" it in your code -
> like you are showing, either with the exception from a constructor /
> init-method, which would fail the blueprint setup, so any e.g. bundles
> dependant on that failed one would not start. IMHO that's not such a bad
>
You could do that but the exception will be logged - also what happens when
the condition is met whereby the bundle can "activate". Also our blueprint
extensions will retry failed bundles indefinitely - something to consider.
As an alternative you coild periodically check the condition in code and
activate when satisfied instead of throwing an exception. We could take
this even further and add a blueprint extension to do it, ie delay the
startup of the blueprint container until some condition is satisfied
(blueprint already does this with service imports).
> solution - if you absolutely require something without which you cannot
> run at all (whether it's a file or a dependant local OSGi service or a
> remote service of some kind on the network), just completely fail the
> start-up - at least it's very clear that a bundle of your feature cannot
> operate, in the log and in something like bundle:list. (The new ready
> service I'm building in infrautils would also pick up on this.)
>
> You could alternatively instead of something quite so drastic perhaps also
> just set some sort of boolean flag in your code if your condition is not
> met, and then if the services if your bundle is used, like throw exceptions
> if that boolean flag is not showing the expected state? This model may be
> more suitable if you want the bundle to become active if that file is added
> after it already started (in the solution above you would have to restart
> it).
>
> For (a) you could perhaps hack something weird with two features, one base
> one which checks something which if met programmatically installs another
> sub-feature... but this could be confusing for end-users ("I just installed
> feature A, why is there suddenly feature B?!"), and unless you have a very
> very good reason for needing this, I would probably keep it simple and not
> do anything like this.
>
>
>> For the same I tried following changes :
>>
>> 1. Blueprint.xml
>>
>> <bean id="provider"
>> class="org.opendaylight.example.impl.MyProvider"
>> init-method="init" destroy-method="close">
>> <argument ref="dataBroker" />
>> <argument ref="rpcRegistry" />
>> </bean>
>>
>> 2. Provider class :
>>
>> public MyProvider(final DataBroker dataBroker , RpcProviderRegistry
>> rpcProviderRegistry) {
>> this.dataBroker = dataBroker;
>> this.rpcProviderRegistry = rpcProviderRegistry;
>> }
>>
>> /**
>> * Method called when the blueprint container is created.
>> */
>> public void init() {
>> LOG.info("MyProvider Session Initiated");
>>
>> // Logic to test presence of configuration file if not throw an
>> exception
>> }
>>
>> As init() and constructor of my provider is called after installation of
>> the feature. So kindly suggest how to get control to achieve conditional
>> feature installation.
>>
>
> HTH?
>
> Tx,
> M.
> --
> Michael Vorburger, Red Hat
> vorbur...@redhat.com | IRC: vorburger @freenode | ~ = http://vorburger.ch
>
>
>>
>>
>> Many thanks,
>>
>> Abhishek Sharma
>>
>> _______________________________________________
>> controller-dev mailing list
>> controller-dev@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>
>>
>
> _______________________________________________
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
