Duplicate SideEffect appearing if @SideEffects declared on role interface.

[Dominic Jones]

First of all, a brief hello - I have been following the project for some time, and like where you are trying to go with it! Qi4j is enjoyable to use. That said, I hit a small snag..

I have a side effect (code for which does not add much to the example..)

A role interface..

@SideEffects(ExampleSideEffect.class)

interface Turn extends TransientComposite {

}

...and a mixin.

class TurnMixin implements Turn {

}

In a setup like this, I am finding the content of the mixin is executed twice. A glance inside the runtime shows two SampleSideEffect declarations. It appears to be inheriting from the Turn role, and the TurnMixin implementation of the role?

For now, declaring a separate TurnTransient interface (with the @SideEffects annotation) prevents the duplicate occurrence. Perhaps that is best practice anyway - the examples are mixed on which style is preferred.

Regardless, this behaviour seems counter-intuitive. If you consider it a bug, do you want a failing test added somewhere?

[Niclas Hedhman]

It sounds like a bug, unless you are doing something peculiar. Can you provide all the classes? Perhaps on GitHub?? Including assembly code...

Thanks

Niclas

--
You received this message because you are subscribed to the Google Groups "qi4j-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qi4j-dev+u...@googlegroups.com.
To post to this group, send email to qi4j...@googlegroups.com.
Visit this group at http://groups.google.com/group/qi4j-dev.
For more options, visit https://groups.google.com/d/optout.

--
Niclas Hedhman, Software Developer
河南南路555弄15号1901室。
http://www.qi4j.org - New Energy for Java

I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/6a2pl4j
I relax here; http://tinyurl.com/2cgsug

[Dominic Jones]

Thanks for your swift answer, Niclas.

I have reproduced the situation with a basic failing case here: https://github.com/dominic-jones/sideeffect-invocation 

My experience so far with testing using Qi4j is a little limited, so please excuse the roundabout nature of testing the invocation. Not sure how I would examine the SideEffect invocations otherwise.

Declaring the Transient with a separate interface (that the mixin does not implement) or using .withSideEffects() on transient assembly appear to sidestep this situation.

[Niclas Hedhman]

Thanks a lot... 

I am on this now, have located the problem area and hopefully I will have a fix committed before I sleep (Europe).

Cheers

Niclas

--

You received this message because you are subscribed to the Google Groups "qi4j-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qi4j-dev+u...@googlegroups.com.
To post to this group, send email to qi4j...@googlegroups.com.
Visit this group at http://groups.google.com/group/qi4j-dev.
For more options, visit https://groups.google.com/d/optout.

[Niclas Hedhman]

Fixed... 

[Niclas Hedhman]

Dominic,

you can also see how did a slightly simpler testcase out of yours, for ideas on how...

Not that the SideEffect is part of the Composite and can therefor access the Properties (or any other method) of the Componsite.

Cheers

Niclas

[Dominic Jones]

Thanks Niclas, it is good to see your example. I prefer an explicit test style to test for a method being called, but given the nature of Qi4j's composable framework, your test is far more concise. I shall adopt that going forward.

In stepping through the api debugging this initially, I noticed a lot of similarity in the code paths taken by Concerns and SideEffects. I want to put together a similar test case to check this defect does not also cover Concerns.