Thanks you for this 'inner workings' overview, very instructive, but
I am not sure we are talking about the same thing.
It is about calling some VC Properties set methods *from inside* a
composite (very probable case) and getting the VC proxy nullified when
it leaves the confines of the composite.
Then when you call UoW.apply(), you get an exception... this is not a
rare case.
So, if you mean that I have to call dereference when I set() the VC
Property, sometimes, It will be, IMHO, very hard to learn Qi4j, since
it works for entities... and not for VC!
phil
Le 29 août 2009 à 04:49, Niclas Hedhman a écrit :
I am not at the computer atm, but if you are talking about getting
rid of dereference(), then I think you are out of luck, although it
may look like working in simple tests.
Why?
Qi4j Runtime constructs an invocation stack for each method in a
composite. There is a Proxy at the top which represents the
Composite, and upon invocation it will locate *a free* stack for
that method, and if none exist create a new one. When a stack is
located it sets the stack's internal state to point to This
composite instance. This means that the reference to @This in a
fragment is only valid within the execution of a Fragment method.
The reason for this is to save memory. If we had one invocation
stack per composite instance method, well.. I think you get the
idea... and although there is a solution for this, we also need to
keep it (method invocations) fast, so that a single reference is set
to @This, instead of locating and injecting them one by one in each
Fragment.
So, the 'dereference' must happen before the call leaves the
confines of the Composite. To locate all places where this could
potentially happen is risky, and will take a perf hit in many cases.
We opted for it to be a programmer's issue, and later with the help
from the IDE which I think can quite easily make it an error to pass
these references in method calls with the dereference().
Did that answer your question?
-- Niclas
On Aug 29, 2009 1:43 AM, "philippe van dyck" <[email protected]>
wrote:
Correction...
public void set(T aNewValue) { if (isImmutable()) { throw new
IllegalStateException("Property [" + q...
value = aNewValue;
// Change property if (Proxy.isProxyClass(aNewValue.getClass()))
{ InvocationHandler handler = getI...
entityState
.setProperty(propertyInfo.qualifiedName(),
(T)
((ProxyReferenceInvocationHandler) handler)
.proxy());
return;
}
}
entityState.setProperty(propertyInfo.qualifiedName(),
aNewValue);
}
Le 28 août 2009 à 15:30, philippe van dyck a écrit :
> Rickard, > > IMHO, this kind od rare occasions will have a deep
impact on the Qi4j learning curv...
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
