You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2015/11/07 06:14:16 UTC
Bug in Assembly??
Gang,
I am chasing an Activation bug (I get activate() called twice), so I made
the testcase below. But here I get ZERO activate() called. Have I/we broken
the activation system completely when going to Java 8? Or am I missing
something bleeding obvious?
Cheers
Niclas
public class ServiceAssemblyTest extends AbstractZestTest
{
@Test
public void
givenMyServiceWithTwoDeclarationsWhenActivatingServiceExpectServiceActivatedOnce()
throws PassivationException
{
ServiceReference<MyService> ref = module.findService( MyService.class );
MyService underTest = ref.get();
assertThat(underTest.activated(), equalTo(1)); // Fails here!!!
underTest.passivate();
assertThat(underTest.passivated(), equalTo(1));
}
@Override
public void assemble( ModuleAssembly module )
throws AssemblyException
{
module.services( MyService.class ).instantiateOnStartup();
module.services( MyService.class ).setMetaInfo( "Hello" );
}
@Mixins( MyServiceMixin.class )
public static interface MyService extends Activation
{
int activated();
int passivated();
}
public static class MyServiceMixin implements MyService, Activation
{
private int activated;
private int passivated;
@Override
public int activated()
{
return activated;
}
@Override
public int passivated()
{
return passivated;
}
@Override
public void activate()
throws ActivationException
{
activated++;
}
@Override
public void passivate()
throws PassivationException
{
passivated++;
}
}
}
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Bug in Assembly??
Posted by Niclas Hedhman <ni...@hedhman.org>.
You make good points... So that became a Jira ticket ;-)
https://issues.apache.org/jira/browse/ZEST-129
On Sat, Nov 14, 2015 at 3:40 AM, Kent Sølvsten <ke...@gmail.com>
wrote:
> I agree that the mix and match between composites and mixin declarations
> of the same @Activators concept might lead to confusion - not a good idea.
>
> But a whole new thought .... aren't we reinventing the wheel here.
>
> We have Initializable interface - declaring a method (on the mixin)
> invoked after construction
> We have ServiceActivation - with 2 initialize/destroy methods
> implemented by a mixin - and sort of referenced from the declarations on
> the composites
> We have @Activators -- that may be declared on the composite - with wide
> flexibility implementation-wise.
>
> But .... the JDK already has @PostConstruct and @PreDestroy annotations.
> These were originally JEE stuff, but have been in the JDK for several
> years.
> And it is the same thing! Keeping a special Initializable interface is,
> frankly, a quite dated way of doing stuff.
>
> I would say we should add support for declaring @PostConstruct and
> @PreDestroy on Mixins - and support for @PostConstruct on plain objects
> (instantiated by ObjectFactory).
> And simply remove (or just deprecate) Initializable and
> ServiceActivation alltogether.
>
> I am more uncertain whether the @Activators should be kept or not.
> On one hand I cannot find a single usage in the whole codebase using
> beforeActivation and afterPassivation - so not sure anyone would miss
> those features.
> On the other hand it might be handy to be able to reuse the same
> activation logic across several composites
> - And there could be some potential of reusing the Activator as a
> listener for UnitOfWork activation/passivation instead of module
> activation/passivation.
> The afterPassivation could have some usages in that context.
>
> So I think we should keep that concept for now.
>
> /Kent
>
> Den 12-11-2015 kl. 16:36 skrev Niclas Hedhman:
> > Kent,
> > I think you are right that we can't have this on Objects and Values, as
> you
> > point out, we don't control the destruction,
> >
> > The problem of supporting ServiceActivator on the composites together
> with
> > Mixins at the same time is that there is a 'precedence' problem; If
> several
> > Mixins implements it, then one of them will be called via the invocation
> > stack whereas the others won't. It makes an imbalanced execution
> > expectation on the Mixins. Maybe not major, but a bit odd.
> >
> > Niclas
> >
> >
> > On Thu, Nov 12, 2015 at 6:19 PM, Kent Sølvsten <kent.soelvsten@gmail.com
> >
> > wrote:
> >
> >> What about something like
> >>
> >> (1) @Activators can be declared either on composites or mixins (today
> >> only on composites)
> >> (2) As as side-effect, both a composite or a mixin may implements
> >> ServiceActivation with the desired effect (just syntactical sugar around
> >> @Activators)
> >> (3) Initializable could be changed to be syntactical sugar around
> >> @Activators - so may be used both on composites or mixins
> >>
> >> Open question: Can ObjectFactory#newObject in any meaningful way be
> >> changed to use @Activators instead of Initializable?
> >> I guess not, since the destruction methods would never be invoked, thus
> >> potentially leading to confusion.
> >>
> >> /Kent
> >>
> >>
> >> Den 12-11-2015 kl. 09:52 skrev Paul Merlin:
> >>> Niclas Hedhman a écrit :
> >>>> Ok, naming might be an issue, but there is a deeper one.
> >>>>
> >>>> Is it correct that the ServiceActivation.activateService() is called
> on
> >> the
> >>>> ServiceComposite and not each Mixin implementing it??
> >>> Correct.
> >>>
> >>>> Just like Initializable was changed to be called on the Mixin, instead
> >> of
> >>>> the Composite, I think a similar lifecycle method pair is needed for
> >>>> Services. Otherwise it is really hard to make very generic Mixins that
> >>>> works independently of the whole ServiceComposite.
> >>>>
> >>>> Lifecycle is another interface with these semantics for entities.
> >>> Makes sense. Could you please capture that in a JIRA?
> >>>
> >>> Cheers
> >>>
> >>> /Paul
> >>>
> >>
> >
>
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Bug in Assembly??
Posted by Kent Sølvsten <ke...@gmail.com>.
I agree that the mix and match between composites and mixin declarations
of the same @Activators concept might lead to confusion - not a good idea.
But a whole new thought .... aren't we reinventing the wheel here.
We have Initializable interface - declaring a method (on the mixin)
invoked after construction
We have ServiceActivation - with 2 initialize/destroy methods
implemented by a mixin - and sort of referenced from the declarations on
the composites
We have @Activators -- that may be declared on the composite - with wide
flexibility implementation-wise.
But .... the JDK already has @PostConstruct and @PreDestroy annotations.
These were originally JEE stuff, but have been in the JDK for several years.
And it is the same thing! Keeping a special Initializable interface is,
frankly, a quite dated way of doing stuff.
I would say we should add support for declaring @PostConstruct and
@PreDestroy on Mixins - and support for @PostConstruct on plain objects
(instantiated by ObjectFactory).
And simply remove (or just deprecate) Initializable and
ServiceActivation alltogether.
I am more uncertain whether the @Activators should be kept or not.
On one hand I cannot find a single usage in the whole codebase using
beforeActivation and afterPassivation - so not sure anyone would miss
those features.
On the other hand it might be handy to be able to reuse the same
activation logic across several composites
- And there could be some potential of reusing the Activator as a
listener for UnitOfWork activation/passivation instead of module
activation/passivation.
The afterPassivation could have some usages in that context.
So I think we should keep that concept for now.
/Kent
Den 12-11-2015 kl. 16:36 skrev Niclas Hedhman:
> Kent,
> I think you are right that we can't have this on Objects and Values, as you
> point out, we don't control the destruction,
>
> The problem of supporting ServiceActivator on the composites together with
> Mixins at the same time is that there is a 'precedence' problem; If several
> Mixins implements it, then one of them will be called via the invocation
> stack whereas the others won't. It makes an imbalanced execution
> expectation on the Mixins. Maybe not major, but a bit odd.
>
> Niclas
>
>
> On Thu, Nov 12, 2015 at 6:19 PM, Kent Sølvsten <ke...@gmail.com>
> wrote:
>
>> What about something like
>>
>> (1) @Activators can be declared either on composites or mixins (today
>> only on composites)
>> (2) As as side-effect, both a composite or a mixin may implements
>> ServiceActivation with the desired effect (just syntactical sugar around
>> @Activators)
>> (3) Initializable could be changed to be syntactical sugar around
>> @Activators - so may be used both on composites or mixins
>>
>> Open question: Can ObjectFactory#newObject in any meaningful way be
>> changed to use @Activators instead of Initializable?
>> I guess not, since the destruction methods would never be invoked, thus
>> potentially leading to confusion.
>>
>> /Kent
>>
>>
>> Den 12-11-2015 kl. 09:52 skrev Paul Merlin:
>>> Niclas Hedhman a écrit :
>>>> Ok, naming might be an issue, but there is a deeper one.
>>>>
>>>> Is it correct that the ServiceActivation.activateService() is called on
>> the
>>>> ServiceComposite and not each Mixin implementing it??
>>> Correct.
>>>
>>>> Just like Initializable was changed to be called on the Mixin, instead
>> of
>>>> the Composite, I think a similar lifecycle method pair is needed for
>>>> Services. Otherwise it is really hard to make very generic Mixins that
>>>> works independently of the whole ServiceComposite.
>>>>
>>>> Lifecycle is another interface with these semantics for entities.
>>> Makes sense. Could you please capture that in a JIRA?
>>>
>>> Cheers
>>>
>>> /Paul
>>>
>>
>
Re: Bug in Assembly??
Posted by Niclas Hedhman <ni...@hedhman.org>.
Kent,
I think you are right that we can't have this on Objects and Values, as you
point out, we don't control the destruction,
The problem of supporting ServiceActivator on the composites together with
Mixins at the same time is that there is a 'precedence' problem; If several
Mixins implements it, then one of them will be called via the invocation
stack whereas the others won't. It makes an imbalanced execution
expectation on the Mixins. Maybe not major, but a bit odd.
Niclas
On Thu, Nov 12, 2015 at 6:19 PM, Kent Sølvsten <ke...@gmail.com>
wrote:
> What about something like
>
> (1) @Activators can be declared either on composites or mixins (today
> only on composites)
> (2) As as side-effect, both a composite or a mixin may implements
> ServiceActivation with the desired effect (just syntactical sugar around
> @Activators)
> (3) Initializable could be changed to be syntactical sugar around
> @Activators - so may be used both on composites or mixins
>
> Open question: Can ObjectFactory#newObject in any meaningful way be
> changed to use @Activators instead of Initializable?
> I guess not, since the destruction methods would never be invoked, thus
> potentially leading to confusion.
>
> /Kent
>
>
> Den 12-11-2015 kl. 09:52 skrev Paul Merlin:
> > Niclas Hedhman a écrit :
> >> Ok, naming might be an issue, but there is a deeper one.
> >>
> >> Is it correct that the ServiceActivation.activateService() is called on
> the
> >> ServiceComposite and not each Mixin implementing it??
> > Correct.
> >
> >> Just like Initializable was changed to be called on the Mixin, instead
> of
> >> the Composite, I think a similar lifecycle method pair is needed for
> >> Services. Otherwise it is really hard to make very generic Mixins that
> >> works independently of the whole ServiceComposite.
> >>
> >> Lifecycle is another interface with these semantics for entities.
> > Makes sense. Could you please capture that in a JIRA?
> >
> > Cheers
> >
> > /Paul
> >
>
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Bug in Assembly??
Posted by Kent Sølvsten <ke...@gmail.com>.
What about something like
(1) @Activators can be declared either on composites or mixins (today
only on composites)
(2) As as side-effect, both a composite or a mixin may implements
ServiceActivation with the desired effect (just syntactical sugar around
@Activators)
(3) Initializable could be changed to be syntactical sugar around
@Activators - so may be used both on composites or mixins
Open question: Can ObjectFactory#newObject in any meaningful way be
changed to use @Activators instead of Initializable?
I guess not, since the destruction methods would never be invoked, thus
potentially leading to confusion.
/Kent
Den 12-11-2015 kl. 09:52 skrev Paul Merlin:
> Niclas Hedhman a écrit :
>> Ok, naming might be an issue, but there is a deeper one.
>>
>> Is it correct that the ServiceActivation.activateService() is called on the
>> ServiceComposite and not each Mixin implementing it??
> Correct.
>
>> Just like Initializable was changed to be called on the Mixin, instead of
>> the Composite, I think a similar lifecycle method pair is needed for
>> Services. Otherwise it is really hard to make very generic Mixins that
>> works independently of the whole ServiceComposite.
>>
>> Lifecycle is another interface with these semantics for entities.
> Makes sense. Could you please capture that in a JIRA?
>
> Cheers
>
> /Paul
>
Re: Bug in Assembly??
Posted by Paul Merlin <pa...@nosphere.org>.
Niclas Hedhman a écrit :
> Ok, naming might be an issue, but there is a deeper one.
>
> Is it correct that the ServiceActivation.activateService() is called on the
> ServiceComposite and not each Mixin implementing it??
Correct.
> Just like Initializable was changed to be called on the Mixin, instead of
> the Composite, I think a similar lifecycle method pair is needed for
> Services. Otherwise it is really hard to make very generic Mixins that
> works independently of the whole ServiceComposite.
>
> Lifecycle is another interface with these semantics for entities.
Makes sense. Could you please capture that in a JIRA?
Cheers
/Paul
Re: Bug in Assembly??
Posted by Niclas Hedhman <ni...@hedhman.org>.
Ok, naming might be an issue, but there is a deeper one.
Is it correct that the ServiceActivation.activateService() is called on the
ServiceComposite and not each Mixin implementing it??
Just like Initializable was changed to be called on the Mixin, instead of
the Composite, I think a similar lifecycle method pair is needed for
Services. Otherwise it is really hard to make very generic Mixins that
works independently of the whole ServiceComposite.
Lifecycle is another interface with these semantics for entities.
Cheers
Niclas
On Thu, Nov 12, 2015 at 6:32 AM, Paul Merlin <pa...@nosphere.org> wrote:
> Niclas,
>
> Theses two interfaces are not the same thing.
> Maybe they are misnamed/misplaced.
>
> Activation Javadoc says: "Application and Layer expose this interface so
> you can activate and passivate them. Module and ServiceComposite
> activation/passivation is handled by the Zest runtime."
>
> Module activation is indeed handled by the runtime.
> For services, one can register Activators at assembly time, which are
> plain java objects.
>
> Then, ServiceActivation is a convenience interface that helps setting up
> "Service Activation" and comes up with a corresponding ServiceActivator.
>
> /Paul
>
>
> Niclas Hedhman a écrit :
> > So, I noticed that I did the wrong thing, that one needs to use
> > ServiceActivation instead of Activation. Then it works.
> >
> > But why is there two interfaces for the same thing? What am I missing?
> >
> >
> > Cheers
> > Niclas
> >
> > On Sat, Nov 7, 2015 at 1:41 PM, Niclas Hedhman <ni...@hedhman.org>
> wrote:
> >
> >> Some debugging done...
> >>
> >> 1. Activation reaches ServiceReferenceInstance.activate(), and since
> >> it is instantiateOnStartup(), it calls getInstance();
> >>
> >> 2. The ServiceReferenceInstance has an activationModel of;
> >>
> >> ActivationDelegate{target=MyService(active=false,module='Module 1'),
> >> targetActivators=null, activeChildren=[]}
> >> Which seems fine to me. activate() is called on that
> >> activationModel.
> >>
> >> 3. In the ActivationDelegate's activate() method, the iteration of
> >> "children" will be done on the ServiceInstance, and the child.activate()
> >> actually happens on the ServiceInstance.activate() which has a NOOP
> >> implementation.
> >>
> >> IIRC, Paul's intention was that each Mixin can implement Activation and
> >> should be called accordingly. But where is this code? Was it forgotten?
> And
> >> should I simply add a loop in ServiceInstance.activate() where each of
> the
> >> Mixins that implements Activation gets called?
> >>
> >> I am somewhat uncertain what the intentions are here...
> >>
> >> Cheers
> >> Niclas
> >>
> >> On Sat, Nov 7, 2015 at 1:14 PM, Niclas Hedhman <ni...@hedhman.org>
> wrote:
> >>
> >>> Gang,
> >>>
> >>> I am chasing an Activation bug (I get activate() called twice), so I
> made
> >>> the testcase below. But here I get ZERO activate() called. Have I/we
> broken
> >>> the activation system completely when going to Java 8? Or am I missing
> >>> something bleeding obvious?
> >>>
> >>> Cheers
> >>> Niclas
> >>>
> >>> public class ServiceAssemblyTest extends AbstractZestTest
> >>> {
> >>> @Test
> >>> public void
> givenMyServiceWithTwoDeclarationsWhenActivatingServiceExpectServiceActivatedOnce()
> >>> throws PassivationException
> >>> {
> >>> ServiceReference<MyService> ref = module.findService(
> MyService.class );
> >>> MyService underTest = ref.get();
> >>> assertThat(underTest.activated(), equalTo(1)); // Fails here!!!
> >>> underTest.passivate();
> >>> assertThat(underTest.passivated(), equalTo(1));
> >>> }
> >>>
> >>> @Override
> >>> public void assemble( ModuleAssembly module )
> >>> throws AssemblyException
> >>> {
> >>> module.services( MyService.class ).instantiateOnStartup();
> >>> module.services( MyService.class ).setMetaInfo( "Hello" );
> >>> }
> >>>
> >>> @Mixins( MyServiceMixin.class )
> >>> public static interface MyService extends Activation
> >>> {
> >>> int activated();
> >>> int passivated();
> >>> }
> >>>
> >>> public static class MyServiceMixin implements MyService, Activation
> >>> {
> >>>
> >>> private int activated;
> >>> private int passivated;
> >>>
> >>> @Override
> >>> public int activated()
> >>> {
> >>> return activated;
> >>> }
> >>>
> >>> @Override
> >>> public int passivated()
> >>> {
> >>> return passivated;
> >>> }
> >>>
> >>> @Override
> >>> public void activate()
> >>> throws ActivationException
> >>> {
> >>> activated++;
> >>> }
> >>>
> >>> @Override
> >>> public void passivate()
> >>> throws PassivationException
> >>> {
> >>> passivated++;
> >>> }
> >>> }
> >>> }
> >>>
> >>>
> >>>
> >>> --
> >>> Niclas Hedhman, Software Developer
> >>> http://zest.apache.org - New Energy for Java
> >>>
> >> --
> >> Niclas Hedhman, Software Developer
> >> http://zest.apache.org - New Energy for Java
> >>
> >
> >
> >
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Bug in Assembly??
Posted by Paul Merlin <pa...@nosphere.org>.
Niclas,
Theses two interfaces are not the same thing.
Maybe they are misnamed/misplaced.
Activation Javadoc says: "Application and Layer expose this interface so
you can activate and passivate them. Module and ServiceComposite
activation/passivation is handled by the Zest runtime."
Module activation is indeed handled by the runtime.
For services, one can register Activators at assembly time, which are
plain java objects.
Then, ServiceActivation is a convenience interface that helps setting up
"Service Activation" and comes up with a corresponding ServiceActivator.
/Paul
Niclas Hedhman a écrit :
> So, I noticed that I did the wrong thing, that one needs to use
> ServiceActivation instead of Activation. Then it works.
>
> But why is there two interfaces for the same thing? What am I missing?
>
>
> Cheers
> Niclas
>
> On Sat, Nov 7, 2015 at 1:41 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>
>> Some debugging done...
>>
>> 1. Activation reaches ServiceReferenceInstance.activate(), and since
>> it is instantiateOnStartup(), it calls getInstance();
>>
>> 2. The ServiceReferenceInstance has an activationModel of;
>>
>> ActivationDelegate{target=MyService(active=false,module='Module 1'),
>> targetActivators=null, activeChildren=[]}
>> Which seems fine to me. activate() is called on that
>> activationModel.
>>
>> 3. In the ActivationDelegate's activate() method, the iteration of
>> "children" will be done on the ServiceInstance, and the child.activate()
>> actually happens on the ServiceInstance.activate() which has a NOOP
>> implementation.
>>
>> IIRC, Paul's intention was that each Mixin can implement Activation and
>> should be called accordingly. But where is this code? Was it forgotten? And
>> should I simply add a loop in ServiceInstance.activate() where each of the
>> Mixins that implements Activation gets called?
>>
>> I am somewhat uncertain what the intentions are here...
>>
>> Cheers
>> Niclas
>>
>> On Sat, Nov 7, 2015 at 1:14 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>>
>>> Gang,
>>>
>>> I am chasing an Activation bug (I get activate() called twice), so I made
>>> the testcase below. But here I get ZERO activate() called. Have I/we broken
>>> the activation system completely when going to Java 8? Or am I missing
>>> something bleeding obvious?
>>>
>>> Cheers
>>> Niclas
>>>
>>> public class ServiceAssemblyTest extends AbstractZestTest
>>> {
>>> @Test
>>> public void givenMyServiceWithTwoDeclarationsWhenActivatingServiceExpectServiceActivatedOnce()
>>> throws PassivationException
>>> {
>>> ServiceReference<MyService> ref = module.findService( MyService.class );
>>> MyService underTest = ref.get();
>>> assertThat(underTest.activated(), equalTo(1)); // Fails here!!!
>>> underTest.passivate();
>>> assertThat(underTest.passivated(), equalTo(1));
>>> }
>>>
>>> @Override
>>> public void assemble( ModuleAssembly module )
>>> throws AssemblyException
>>> {
>>> module.services( MyService.class ).instantiateOnStartup();
>>> module.services( MyService.class ).setMetaInfo( "Hello" );
>>> }
>>>
>>> @Mixins( MyServiceMixin.class )
>>> public static interface MyService extends Activation
>>> {
>>> int activated();
>>> int passivated();
>>> }
>>>
>>> public static class MyServiceMixin implements MyService, Activation
>>> {
>>>
>>> private int activated;
>>> private int passivated;
>>>
>>> @Override
>>> public int activated()
>>> {
>>> return activated;
>>> }
>>>
>>> @Override
>>> public int passivated()
>>> {
>>> return passivated;
>>> }
>>>
>>> @Override
>>> public void activate()
>>> throws ActivationException
>>> {
>>> activated++;
>>> }
>>>
>>> @Override
>>> public void passivate()
>>> throws PassivationException
>>> {
>>> passivated++;
>>> }
>>> }
>>> }
>>>
>>>
>>>
>>> --
>>> Niclas Hedhman, Software Developer
>>> http://zest.apache.org - New Energy for Java
>>>
>> --
>> Niclas Hedhman, Software Developer
>> http://zest.apache.org - New Energy for Java
>>
>
>
>
Re: Bug in Assembly??
Posted by Niclas Hedhman <ni...@hedhman.org>.
So, I noticed that I did the wrong thing, that one needs to use
ServiceActivation instead of Activation. Then it works.
But why is there two interfaces for the same thing? What am I missing?
Cheers
Niclas
On Sat, Nov 7, 2015 at 1:41 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>
> Some debugging done...
>
> 1. Activation reaches ServiceReferenceInstance.activate(), and since
> it is instantiateOnStartup(), it calls getInstance();
>
> 2. The ServiceReferenceInstance has an activationModel of;
>
> ActivationDelegate{target=MyService(active=false,module='Module 1'),
> targetActivators=null, activeChildren=[]}
> Which seems fine to me. activate() is called on that
> activationModel.
>
> 3. In the ActivationDelegate's activate() method, the iteration of
> "children" will be done on the ServiceInstance, and the child.activate()
> actually happens on the ServiceInstance.activate() which has a NOOP
> implementation.
>
> IIRC, Paul's intention was that each Mixin can implement Activation and
> should be called accordingly. But where is this code? Was it forgotten? And
> should I simply add a loop in ServiceInstance.activate() where each of the
> Mixins that implements Activation gets called?
>
> I am somewhat uncertain what the intentions are here...
>
> Cheers
> Niclas
>
> On Sat, Nov 7, 2015 at 1:14 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>
>> Gang,
>>
>> I am chasing an Activation bug (I get activate() called twice), so I made
>> the testcase below. But here I get ZERO activate() called. Have I/we broken
>> the activation system completely when going to Java 8? Or am I missing
>> something bleeding obvious?
>>
>> Cheers
>> Niclas
>>
>> public class ServiceAssemblyTest extends AbstractZestTest
>> {
>> @Test
>> public void givenMyServiceWithTwoDeclarationsWhenActivatingServiceExpectServiceActivatedOnce()
>> throws PassivationException
>> {
>> ServiceReference<MyService> ref = module.findService( MyService.class );
>> MyService underTest = ref.get();
>> assertThat(underTest.activated(), equalTo(1)); // Fails here!!!
>> underTest.passivate();
>> assertThat(underTest.passivated(), equalTo(1));
>> }
>>
>> @Override
>> public void assemble( ModuleAssembly module )
>> throws AssemblyException
>> {
>> module.services( MyService.class ).instantiateOnStartup();
>> module.services( MyService.class ).setMetaInfo( "Hello" );
>> }
>>
>> @Mixins( MyServiceMixin.class )
>> public static interface MyService extends Activation
>> {
>> int activated();
>> int passivated();
>> }
>>
>> public static class MyServiceMixin implements MyService, Activation
>> {
>>
>> private int activated;
>> private int passivated;
>>
>> @Override
>> public int activated()
>> {
>> return activated;
>> }
>>
>> @Override
>> public int passivated()
>> {
>> return passivated;
>> }
>>
>> @Override
>> public void activate()
>> throws ActivationException
>> {
>> activated++;
>> }
>>
>> @Override
>> public void passivate()
>> throws PassivationException
>> {
>> passivated++;
>> }
>> }
>> }
>>
>>
>>
>> --
>> Niclas Hedhman, Software Developer
>> http://zest.apache.org - New Energy for Java
>>
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Bug in Assembly??
Posted by Niclas Hedhman <ni...@hedhman.org>.
Some debugging done...
1. Activation reaches ServiceReferenceInstance.activate(), and since it
is instantiateOnStartup(), it calls getInstance();
2. The ServiceReferenceInstance has an activationModel of;
ActivationDelegate{target=MyService(active=false,module='Module
1'), targetActivators=null, activeChildren=[]}
Which seems fine to me. activate() is called on that
activationModel.
3. In the ActivationDelegate's activate() method, the iteration of
"children" will be done on the ServiceInstance, and the child.activate()
actually happens on the ServiceInstance.activate() which has a NOOP
implementation.
IIRC, Paul's intention was that each Mixin can implement Activation and
should be called accordingly. But where is this code? Was it forgotten? And
should I simply add a loop in ServiceInstance.activate() where each of the
Mixins that implements Activation gets called?
I am somewhat uncertain what the intentions are here...
Cheers
Niclas
On Sat, Nov 7, 2015 at 1:14 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Gang,
>
> I am chasing an Activation bug (I get activate() called twice), so I made
> the testcase below. But here I get ZERO activate() called. Have I/we broken
> the activation system completely when going to Java 8? Or am I missing
> something bleeding obvious?
>
> Cheers
> Niclas
>
> public class ServiceAssemblyTest extends AbstractZestTest
> {
> @Test
> public void givenMyServiceWithTwoDeclarationsWhenActivatingServiceExpectServiceActivatedOnce()
> throws PassivationException
> {
> ServiceReference<MyService> ref = module.findService( MyService.class );
> MyService underTest = ref.get();
> assertThat(underTest.activated(), equalTo(1)); // Fails here!!!
> underTest.passivate();
> assertThat(underTest.passivated(), equalTo(1));
> }
>
> @Override
> public void assemble( ModuleAssembly module )
> throws AssemblyException
> {
> module.services( MyService.class ).instantiateOnStartup();
> module.services( MyService.class ).setMetaInfo( "Hello" );
> }
>
> @Mixins( MyServiceMixin.class )
> public static interface MyService extends Activation
> {
> int activated();
> int passivated();
> }
>
> public static class MyServiceMixin implements MyService, Activation
> {
>
> private int activated;
> private int passivated;
>
> @Override
> public int activated()
> {
> return activated;
> }
>
> @Override
> public int passivated()
> {
> return passivated;
> }
>
> @Override
> public void activate()
> throws ActivationException
> {
> activated++;
> }
>
> @Override
> public void passivate()
> throws PassivationException
> {
> passivated++;
> }
> }
> }
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java