The below may look like an afirmative phrase, but it should be seem as of "please shoot on me".
Can you help me on this? Quoting [EMAIL PROTECTED]: >>>>>>>>>>>>>>>>> > Thx, > > The NullPointException is happening on a collection field, which is lazy > loaded > by JPOX, but at this time, the field was not loaded. > > The JDO spec states the access to fields is not allowed, but the TCK test > does > in the jdoPreClear. If I'm correct, this situation is not determined by the > spec, and we may have any kind of problems, from returning undetermined > values > to the user or raising exceptions to returning the correct value. > > Regards, >>>>>>>>>>>>>>>> > > Quoting Craig Russell <[EMAIL PROTECTED]>: > > > Hi Erik, > > > > On Jul 17, 2005, at 2:15 AM, [EMAIL PROTECTED] wrote: > > > > > TCK: org.apache.jdo.tck.api.instancecallbacks.CallingJdoPreclear - > > > JIRA #70 > > > > > > During commit jdoPreClear is called in p-deleted instances. > > > jdoPreClear is not > > > enhanced, and access to persistent fields is not allowed on p-deleted > > > instances, but the TCK does. Should jdoPreClear be called on p-deleted > > > instances? > > > > Yes. The idea is that jdoPreClear cannot affect the persistent state > > of instances because it's called during afterCompletion. And the > > method is not enhanced so no one will ever know. The job of > > jdoPreClear is to do any cleanup of the instance that might be needed > > before it transitions to transient. > > > > Access to persistent fields (except for identity fields which can > > always be accessed) of deleted instances is detected by enhanced code > > that ends up calling the StateManager. While in jdoPreDelete, nothing > > that the method does is mediated, which is why it cannot call other > > methods that are enhanced! > > > > Craig > > > > Craig Russell > > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > > 408 276-5638 mailto:[EMAIL PROTECTED] > > P.S. A good JDO? O, Gasp! > > > > > > >
