You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Bengt Rodehav <be...@rodehav.com> on 2013/10/04 10:04:02 UTC
iPOJO, problems with @Controller and @ServiceController
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?
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
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?
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
Re: iPOJO, problems with @Controller and @ServiceController
Posted by Bengt Rodehav <be...@rodehav.com>.
Thanks Clement. You're right about the typo as well.
/Bengt
Den tisdagen den 8:e oktober 2013 skrev Clement Escoffier<
clement.escoffier@gmail.com>:
> Hi,
>
> On 8 oct. 2013, at 13:19, Bengt Rodehav <be...@rodehav.com> 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 <cl...@gmail.com>
>>
>>> Hi,
>>>
>>>
>>> On 4 oct. 2013, at 10:04, Bengt Rodehav <be...@rodehav.com> 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<
Re: iPOJO, problems with @Controller and @ServiceController
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 8 oct. 2013, at 13:19, Bengt Rodehav <be...@rodehav.com> 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 <cl...@gmail.com>
>
>> Hi,
>>
>>
>> On 4 oct. 2013, at 10:04, Bengt Rodehav <be...@rodehav.com> 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
>>
>>
Re: iPOJO, problems with @Controller and @ServiceController
Posted by Bengt Rodehav <be...@rodehav.com>.
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
}
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.
/Bengt
2013/10/7 Clement Escoffier <cl...@gmail.com>
> Hi,
>
>
> On 4 oct. 2013, at 10:04, Bengt Rodehav <be...@rodehav.com> 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
>
>
Re: iPOJO, problems with @Controller and @ServiceController
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 4 oct. 2013, at 10:04, Bengt Rodehav <be...@rodehav.com> 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