Add ipopo decorator for dynamic validation about ipopo HOT 17 CLOSED

Hi Scott,

I took the liberty to update the formatting of the issue, to keep track of some links I put in the previous discussion :)

Unfortunately I'm going to have to ask you to implement this decorator, as this week I have ECF commitments for Photon and I think my knowledge of ipopo internals might limit me.

No problem. I'm also under a constant load of work, so it won't be implemented before this weekend.

The most tricky part will be to choose when the decorated method will be called (before or after @Validate).

from ipopo.

Hi @tcalmant ,

Formatting....good idea 👍

I appreciate the effort...lmk if/how I can help. I have a use case (RSA impl) where I can try it out right away.

from ipopo.

Hi @scottslewis,

I've just pushed an early version of @ValidateComponent on branch validate_component.

It's an early version, so:

• the signature of the callback depends on the order of the list of arguments given to the decorator. I think this will stay
• the properties given to the callback are a copy of the component properties, to avoid messing with requirements based on properties. It would be possible to change that, but I don't consider this a priority.
• the bundle and component contexts given as parameters are the real ones.

Here is a snippet on how to use the new decorator:

from pelix.ipopo.decorators import ComponentFactory, \
    Instantiate, Validate, Invalidate, ValidateComponent
from pelix.ipopo.constants import ARG_BUNDLE_CONTEXT, \
    ARG_COMPONENT_CONTEXT, ARG_PROPERTIES

@ComponentFactory("sample-factory")
@Instantiate("sample")
class Sample(object):
    @ValidateComponent(ARG_COMPONENT_CONTEXT, ARG_PROPERTIES)
    def validate_ext(self, component_ctx, props):
        print("Component Context:", component_ctx)
        print("Component Props:", props)

    @Validate
    def validate(self, context):
        print("Validated")

    @Invalidate
    def invalidate(self, context):
        print("Invalidated")

You can mix the number and order of the authorized arguments and use any name for them.
The only constraint is them to be in the same order as given in the @ValidateComponent arguments

from ipopo.

Hi Scott,
I've added the tests for this decorator and it works as intended.
Let me know if you need it to be tweaked.

Once it suits your needs, I'll merge it into the master branch.

from ipopo.

Hi Thomas. I've tried it out for my use case and it seems to work fine so I'm +1 for merging to master. Thank you for adding this so quickly!

from ipopo.

Hi Thomas. One thing I noticed with further testing: If the ValidateComponent method raises an exception it does not prevent the component from being registered as a service in the service registry. Would it be possible for the ValidateComponent exception to prevent the component from being registered in the service registry?

from ipopo.

Hi Scott,
I'll take a look tomorrow. I missed it in the tests

from ipopo.

Hi Scott,
I've fixed the issue, all should work well now.

Note that when @ValidateComponent raises an exception, the component will be in ERRONEOUS state (you can call retry_erroneous to try new properties or kill it).
During the change of state @Invalidate will be called (this is the standard error handling), so be careful with the variables you use in this callback.

from ipopo.

Hi Thomas.

I see the behavior you describe wrt the component instances, but still see the service in the service registry (e.g. sl console command). To get the component instantiation failure to result in removal from the service registry (e.g. ValidateComponent raises) is it necessary to manually unregister it (and kill it from the component factory?) Can such clean up be safely done in Invalidate handler or elsewhere?

I guess the component/service registry relationship in ipopo is a little different than DS.

Thanks for any info.

from ipopo.

Hi Scott,
I'll take a look asap, but it looks like a bug.
A component must be in valid state for the "provides" handler to be called, which shouldn't happen when the component goes into erroneous state.

from ipopo.

Hi Scott,
I can't reproduce the issue, the snippets I tried seems to behave correctly.
Do you have a sample class to reproduce the issue ?

from ipopo.

Hi Thomas. Sorry for the slow response. I've been working on the RSA impl.

This s behaving as expected now (i.e. exception in ValidateComponent leads to no component and no associated service), so if you want to merge to master (perhaps you already have) then feel free to close this issue. Thanks again for your effort here, and I think ValidateComponent will be useful to others as well.

I may need to open a new issue for exception handling of the eventlistenerhook that I added, however. I'll clarify the necessary behavior and then open a new issue.

from ipopo.

Hi Scott,
That's great!

I'm just wondering if it is necessary to keep @Validate as a whole or if it could be transformed into an alias of @ValidateComponent(ARG_BUNDLE_CONTEXT).
We lose the fact that one method is called before the other, but it would seem more logical.
What do you think ?

Also, it might be interesting to have the behaviour with @InvalidateComponent.

from ipopo.

Hi Thomas,

I've already gotten into ValidateComponent/Invalidate and that's a little clumsy, so I think InvalidateComponent would be a good idea. I think the Validate/Invalidate aliasing would also make sense.

from ipopo.

Hi Scott,

The validate_component now works as described before:

• @Validate is now an alias of @ValidateComponent(ARG_BUNDLE_CONTEXT)
• @InvalidateComponent mimics the behaviour for the invalidation callback.
  Exceptions raised by the decorated callback are ignored.
• @Invalidate is now an alias of @InvalidateComponent(ARG_BUNDLE_CONTEXT)

I've added the tests for the invalidation callback and all works as intented.

Note that now, you can't use both @Validate and @ValidateComponent in the same class (as it would duplicate validation callbacks).

from ipopo.

The branch has been merged into master and deleted.
The issue can now be closed as it has been fully handled.

from ipopo.

Sounds great, thanks.

from ipopo.