Hello and thanks for your quick reply!

> Try to remove the "abstract" and provide dummy methods for what you
> are not interested in. The abstract class will be subclassed with
> CGLib and I suspect that it could be related.

Done that and no difference. In fact, I have a Concern implemented in
the same way which works:

abstract class MessageConcern extends ConcernOf<MessageBehaviour>
implements MessageBehaviour {
    String giveMeContent() {
        return 'concern for ' + next.giveMeContent()
    }
}

And this side effect also works:

abstract class MessageSideEffect extends ConcernOf<MessageBehaviour>
implements MessageBehaviour {
    String giveMeContent() {
        println "sideeffect in action"
        return null
    }
}

But as soon as I access the methods on the "next" object, I get the
classcastexception. This works however:

abstract class MessageSideEffect extends ConcernOf<MessageBehaviour>
implements MessageBehaviour {
    String giveMeContent() {
        println "sideeffect in action " + next
        return null
    }
}

It gives the result:

sideeffect in action concern for speak
concern for speak
shout

> Can you break that down and point to exactly what is Null? And doesn
> it work in Java?

Sorry, can't make it happen again. But it was the subject property
which was null:

        builder.stateFor(MessageState.class).subject().set "shout"

The NPE didn't occur in the Java code.

> We have not yet designed the mechanism, and the latest break-through
> in persistence (seen in recent 6 part post) will touch on this again.

Meaning migration still is a problem? How do you usually solve data
migration after class changes?

> At persistence level, only Property, Association and ManyAssociation
> are persisted. And for Property, the generic type must either be
> serializable (we might even reconsider this), discrete or a
> ValueComposite. For Associations, only the reference to the other
> Entity is saved.

What about ListAssocation and SetAssociation? Aren't those persisted?
If only the references are persisted, does that mean that I have to
wire the associated entities back together myself after retrieval? Is
it done by searching for the reference id:s? I really would like to
have an object graph back from the store.

> in your bootstrap code;
>
>  module.addAssembler( new JdbmEntityStoreAssembler( "jdbm-config" ) );
> module.addAssembler( new RdfNativeSesameStoreAssembler() );

Thanks for this!

Regards,
Pelle P

_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev

Reply via email to