Hi,
On 8 oct. 2013, at 13:19, Bengt Rodehav <[email protected]> wrote:
> Thanks for the excellent documentation Clement!
>
> But, I still have one question...
>
> Now, if I use @ServiceController I want to explicitly start my underlying
> service (my Camel route) before iPOJO publishes the service for others to
> consume. Starting the route in the @PostRegistration callback is therefore
> too late.
>
> When using the @Controller I usually connect the life cycle controller to a
> property managed by config admin, like so:
>
> @Controller
> @Property(name = "enabled", mandatory = true)
> private boolean mValid;
>
>
> I then start my underlying service (my Camel route) in the @Validate
> callback, like so:
>
> @Validate
> public void start() {
> // Start Camel route
> }
>
> and stop it like so:
>
> @InValidate
> public void stop() {
> // Stop Camel route
> }
>
> When using @ServiceController what would be the equivalent? Somthing like
> this?
>
> @ServiceController(value=false)
> private boolean mValid;
>
> @Property(name = "enabled", mandatory = true)
> public void setValid(boolean theValid) {
> if(theValid) {
> // Start Camel route
> }
> mValid = theValid;
> }
>
> @PostRegistration
> // Stop Camel route
> }
@PostUnregistration right ?
>
> What I want to accomplish is to make sure that the underlying service (the
> Camel route) is running for as long as the service is published to others.
Yes, this code should work as you expect.
I've a bonus track for you:
http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/service-binding-interceptors.html.
Regards,
Clement
>
>
> /Bengt
>
>
>
> 2013/10/7 Clement Escoffier <[email protected]>
>
>> Hi,
>>
>>
>> On 4 oct. 2013, at 10:04, Bengt Rodehav <[email protected]> wrote:
>>
>>> I discussed this with Clement on another thread ("iPOJO and dynamic
>>> requires") but thought I'd start a new thread that better describes the
>>> subject.
>>>
>>> A little background...
>>>
>>> Using iPOJO (currently 1.8.6), I have a system where I'm using a
>>> life-cycle-controller (@Controller) to enable(start) / disable(stop) my
>>> services. A lot of the services are Camel routes that are then started
>> and
>>> stopped by changing a config admin property (in a GUI).
>>>
>>> Basically the code looks like this:
>>>
>>> @Controller
>>> @Property(name = "enabled", mandatory = true, value = "false")
>>> private boolean mValid;
>>>
>>> @Validate
>>> public void start() {
>>> System.out.println("Starting... valid is: " + mValid);
>>> // Start the Camel route
>>> }
>>>
>>> @Invalidate
>>> public void stop() {
>>> System.out.println("Stopping... valid is: " + mValid);
>>> // Stop the Camel route
>>> }
>>>
>>> On startup, if the "enabled" property is set to false, nothing is logged.
>>> When I set the enabled property to true I get:
>>>
>>> Starting... valid is: true
>>>
>>> If I then set the enabled property to false I get:
>>>
>>> Stopping... valid is: false
>>>
>>> This is the way I want it to work. I use the "enabled" property to
>>> start/stop my services.
>>>
>>> However, I now need to make the life-cycle controller more dynamic. In
>>> addition to looking at the "enabled" property I also want to add my
>> custom
>>> extra constraints. Something like this:
>>>
>>> private boolean mValid;
>>>
>>> @Property(name = "enabled", mandatory = true, value = "false")
>>> public void setValid(boolean theValid) {
>>> System.out.println("Setting valid to: " + theValid);
>>> mValid = theValid;
>>> mAggregateValid = mValid; // I also add extra constraints not shown
>>> here: mAggregateValid = mValid && <extra constraints>
>>> }
>>>
>>> @Controller
>>> private boolean mAggregateValid;
>>>
>>> @Validate
>>> public void start() {
>>> System.out.println("Starting... mValid is: " + mValid + ",
>>> mAggregateValid is: " + mAggregateValid);
>>> // Start the Camel route
>>> }
>>>
>>> @Invalidate
>>> public void stop() {
>>> System.out.println("Stopping... mValid is: " + mValid + ",
>>> mAggregateValid is: " + mAggregateValid);
>>> // Stop the Camel route
>>> }
>>>
>>> I now get:
>>>
>>> Starting... mValid is: false, mAggregateValid is: false
>>> Stopping... mValid is: false, mAggregateValid is: false
>>>
>>> This is not the way I wanted. Although I've set the @Controller to
>>> "mAggregateValid", the instance is becoming valid when the
>> mAggregateValid
>>> is false. It does stop shortly afterwards but I get a false start this
>> way
>>> that gives me problems.
>>>
>>> Question 1: Why does the instance become valid despite the fact that my
>>> life-cycle-controller is false?
>>
>> Because the instance lifecycle controller does not allowed default value.
>>
>>>
>>> Clement, you suggested that I should use the @ServiceController instead.
>> I
>>> tried this but it seems like the @Validate callback will be called no
>>> matter what value my @ServiceController has. I noticed that there are
>> other
>>> callbacks that I might be able to use instead: @PostRegistration and
>>> @PostUnregistration. However, they seem to be called "after the fact".
>> If I
>>> use those callbacks to actually start my services it would mean that I
>>> first publish a service and afterwards make it work. Should be the other
>>> way around.
>>>
>>> Question 2: For my use case, should I use @Controller or
>> @ServiceController
>>
>> In your case you should use @ServiceController. I've published a new page
>> about controllers:
>>
>> http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/instance-vs-service-controller.html
>>
>>
>>>
>>> Looking at the annotations documentation (
>>>
>> http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.html
>> )
>>> I noticed that @Controller is not mentioned at all.
>>>
>>> Question 3: Is @Controller deprecated or does the documentation need to
>> be
>>> updated?
>>
>> This is a mistake…. We will add it ASAP.
>>
>> Regards,
>>
>> Clement
>>
>>>
>>> When the new version of iPOJO is released I might not need to use an
>>> "aggregated controller" but could use interceptors instead (see my
>> original
>>> thread). But I would still like to know why I can't get the above to work
>>> correctly.
>>>
>>> Thanks,
>>>
>>> /Bengt
>>
>>
