First question, are you using JavaClient applets?
Below is a Java class that might both explain and solve what you are seeing.
Chuck
package net.global_village.eofextensions;
import com.webobjects.eocontrol.*;
/**
* EOEditingContext that clears undo stack after a successful save. This is
used as a work around for a bug in EOF. There is a rather serious bug when
validateForDelete() fails to allow a deletion. This will occur if you are
using the Deny delete rule, the relationship is mandatory, or you have a custom
validateForDelete() method. The error occurs in this scenario:<br>
* 1. The editing context has multiple generations, meaning that saveChanges()
has been called one or more times after one or more EOs has been created /
inserted / updated.<br>
* 2. An EO is deleted from the editing context by deleteObject().<br>
* 3. saveChanges() fails due to an NSValidation.ValidationException raised in
validateForDelete.<br>
*
* This result of this appears to be that undo() is called on the editing
context's undo manager too many times. Instead of rolling back to the state
when saveChanges() was called it rolls back past several of previous
saveChanges()! The result of this is that the editing context shows a
historical state that does not match the object store or the database.
*
* @author Copyright (c) 2001-2005 Global Village Consulting, Inc. All rights
reserved.
* This software is published under the terms of the Educational Community
License (ECL) version 1.0,
* a copy of which has been included with this distribution in the LICENSE.TXT
file.
* @version $Revision: 7$
*/
public class ForgetfulEC extends EOEditingContext
{
/**
* Designated constructor. Creates a new ForgetfulEC object with
anObjectStore as its parent
* object store.
*
* @param anObjectStore parent object store
*/
public ForgetfulEC(EOObjectStore anObjectStore)
{
super(anObjectStore);
}
/**
* Creates a new ForgetfulEC object with the default parent object store as
its parent object
* store.
*/
public ForgetfulEC()
{
super();
}
/**
* Overridden to clear undo stack after a successful save.
*/
public void saveChanges()
{
super.saveChanges();
if (undoManager() != null)
{
undoManager().removeAllActions();
}
}
}
On 2014-10-09, 7:22 AM, "John Pollard" wrote:
My trap set up in takeStoredValueForKey() for my intermittent has triggered
reporting my bug where an attribute is being set to null. However, the stack
trace below doesn't come from anywhere obvious in my code. It is server side
processing a client request and for some reason there is an "undo" being
triggered from WOJavaClientApplet.handleClientRequest()
My trap fires off when the attribute is being changed from a non-null value to
a null value, which should never happen, but it is.
Furthermore, in my trap I make sure I don't call super.takeStoredValueForKey()
if I can see the attribute is about to be set to null...but somehow the value
is still being set to null on the database.
Any thoughts welcome!
John
at mp.gen.Utils.getStackTraceAsString(Utils.java:2819)
at mp.eo.Transaction.takeStoredValueForKey(Transaction.java:1920)
at
com.webobjects.eocontrol.EOCustomObject.updateFromSnapshot(EOCustomObject.java:581)
at
er.extensions.eof.ERXGenericRecord.updateFromSnapshot(ERXGenericRecord.java:1267)
at
com.webobjects.eocontrol.EOEditingContext._undoUpdate(EOEditingContext.java:1629)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:622)
at com.webobjects.foundation.NSSelector.invoke(NSSelector.java:358)
at com.webobjects.foundation.NSSelector._safeInvokeSelector(NSSelector.java:110)
at
com.webobjects.foundation.NSUndoManager$_NSUndoLightInvocation.invoke(NSUndoManager.java:1002)
at
com.webobjects.foundation.NSUndoManager$_NSUndoStack.popAndInvoke(NSUndoManager.java:1280)
at
com.webobjects.foundation.NSUndoManager.undoNestedGroup(NSUndoManager.java:733)
at com.webobjects.foundation.NSUndoManager.undo(NSUndoManager.java:693)
at
com.webobjects.eodistribution.EODistributionContext.responseToClientMessage(EODistributionContext.java:627)
at
com.webobjects.eodistribution.WOJavaClientApplet.handleClientRequest(WOJavaClientApplet.java:978)
at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:622)
at
com.webobjects.foundation.NSKeyValueCoding$ValueAccessor$1.methodValue(NSKeyValueCoding.java:636)
at
com.webobjects.foundation.NSKeyValueCoding$_MethodBinding.valueInObject(NSKeyValueCoding.java:1134)
at
com.webobjects.foundation.NSKeyValueCoding$DefaultImplementation.valueForKey(NSKeyValueCoding.java:1324)
at com.webobjects.appserver.WOComponent.valueForKey(WOComponent.java:1736)
at
com.webobjects.foundation.NSKeyValueCoding$Utility.valueForKey(NSKeyValueCoding.java:447)
at
com.webobjects.foundation.NSKeyValueCodingAdditions$DefaultImplementation.valueForKeyPath(NSKeyValueCodingAdditions.java:212)
at com.webobjects.appserver.WOComponent.valueForKeyPath(WOComponent.java:1804)
at
com.webobjects.appserver._private.WOKeyValueAssociation.valueInComponent(WOKeyValueAssociation.java:50)
at
com.webobjects.appserver._private.WOGenericElement.invokeAction(WOGenericElement.java:121)
at
com.webobjects.appserver._private.WODynamicGroup.invokeChildrenAction(WODynamicGroup.java:105)
at
com.webobjects.appserver._private.WOGenericContainer.invokeAction(WOGenericContainer.java:29)
at
com.webobjects.appserver._private.WODynamicGroup.invokeChildrenAction(WODynamicGroup.java:105)
at
com.webobjects.appserver._private.WODynamicGroup.invokeAction(WODynamicGroup.java:115)
at
com.webobjects.appserver._private.WOConditional.invokeAction(WOConditional.java:86)
at
com.webobjects.appserver._private.WODynamicGroup.invokeChildrenAction(WODynamicGroup.java:105)
at
com.webobjects.appserver._private.WODynamicGroup.invokeAction(WODynamicGroup.java:115)
at com.webobjects.appserver.WOComponent.invokeAction(WOComponent.java:1079)
at
com.webobjects.appserver._private.WOComponentReference.invokeAction(WOComponentReference.java:127)
at
com.webobjects.appserver._private.WODynamicGroup.invokeChildrenAction(WODynamicGroup.java:105)
at
com.webobjects.appserver._private.WODynamicGroup.invokeAction(WODynamicGroup.java:115)
at com.webobjects.appserver.WOComponent.invokeAction(WOComponent.java:1079)
at com.webobjects.appserver.WOSession.invokeAction(WOSession.java:1357)
at com.webobjects.appserver.WOApplication.invokeAction(WOApplication.java:1745)
at
er.extensions.appserver.ajax.ERXAjaxApplication.invokeAction(ERXAjaxApplication.java:119)
at er.extensions.appserver.ERXApplication.invokeAction(ERXApplication.java:1988)
at
er.extensions.appserver.ERXComponentRequestHandler._dispatchWithPreparedPage(ERXComponentRequestHandler.java:157)
at
er.extensions.appserver.ERXComponentRequestHandler._dispatchWithPreparedSession(ERXComponentRequestHandler.java:235)
at
er.extensions.appserver.ERXComponentRequestHandler._dispatchWithPreparedApplication(ERXComponentRequestHandler.java:268)
at
er.extensions.appserver.ERXComponentRequestHandler._handleRequest(ERXComponentRequestHandler.java:302)
at
er.extensions.appserver.ERXComponentRequestHandler.handleRequest(ERXComponentRequestHandler.java:378)
at
com.webobjects.appserver.WOApplication.dispatchRequest(WOApplication.java:1687)
at
er.extensions.appserver.ERXApplication.dispatchRequestImmediately(ERXApplication.java:2109)
at
er.extensions.appserver.ERXApplication.dispatchRequest(ERXApplication.java:2074)
at mpServer.Application.dispatchRequest(Application.java:168)
at
com.webobjects.appserver._private.WOWorkerThread.runOnce(WOWorkerThread.java:144)
at com.webobjects.appserver._private.WOWorkerThread.run(WOWorkerThread.java:226)
at java.lang.Thread.run(Thread.java:701)
On 12 Sep 2014, at 09:18, John Pollard
<[email protected]<mailto:[email protected]>> wrote:
Hmm, hairy palms, not sure I want that, but thanks for this anyway. The related
attribute is a to-one relationship, does that mean it is a FK attribute? It is
the to-one relationship that becomes null against my will and I need to find
out where/why.
I have now cobbled some code up in takeStoredValueForKey() which avoids the
recursion when checking the existing value using storedValueForKey() and
ignores the (temp) null value caused by clearProperties() when the EO is
invalidated. Hence I believe I now have the code to scream if my property is
set to null from a pre-existing value and I should get an email + stack trace
to report the exciting news. These intermittents are about once every two
months so will have to wait.
On 11 Sep 2014, at 23:04, Chuck Hill
<[email protected]<mailto:[email protected]>> wrote:
You are going to grow hair on your palms doing this but...
willRead();
Object value = __dictionary().valueForKey("your attribute");
Should, I think, do what you want. Of course, it is package protected so you
will need to use reflection to get access. And the result may be null if the
object is still a fault.
Is this an FK or PK by chance?
Chuck
On 2014-09-11, 12:22 PM, "John Pollard" wrote:
Apologies, I meant takeStoredValueForKey(). Within there, how can I safely see
what the value currently is when when this method is called, before I invoke
super. takeStoredValueForKey() to take on the new value?
John
On 11 Sep 2014, at 18:10, John Huss
<[email protected]<mailto:[email protected]>> wrote:
The order of calls is:
takeValueForKey -> setXXX -> takeStoredValueForKey
All of these maybe skipped except for takeStoredValueForKey, so that is the
only one you should override to see what is getting saved.
On Thu, Sep 11, 2014 at 8:55 AM, John Pollard
<[email protected]<mailto:[email protected]>> wrote:
Hi List,
In some debugging within takeValueForKey() I want to find out if the key
already has a value set. If I call valueForKey() or storedValueForKey() and the
value isn't already set I get infinite recursion as it triggers a fault and
tries to load with takeValueForKey() and so on.
I am trying to debug where a value is being set to null, but apparently not
going via validateXXX() or setXXX() methods, so I want to trap the case where
the takeValueForKey() is passed null when the key value was previously non-null
and log a stack trace.
Thanks
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list
([email protected]<mailto:[email protected]>)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/johnthuss%40gmail.com
This email sent to [email protected]<mailto:[email protected]>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
