• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: EOCustomObject valueForKey avoiding infinite recursion
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EOCustomObject valueForKey avoiding infinite recursion

  • Subject: Re: EOCustomObject valueForKey avoiding infinite recursion
  • From: Chuck Hill <email@hidden>
  • Date: Fri, 10 Oct 2014 16:03:54 +0000
  • Thread-topic: EOCustomObject valueForKey avoiding infinite recursion
Yeah, that would make me nervous.  I have never used this with JavaClient, and it sounds like this hack is not compatible.

Before you go too much further, are these two things even true for your application:

 * 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.
 * 2. An EO is deleted from the editing context by deleteObject().
 * 3. saveChanges() fails due to an NSValidation.ValidationException raised in validateForDelete.

I’d guess that (1) and (2) are, but is (3)?  Do you have rules in the model or the code that could refused a delete?  If not, this is not your problem.

EODistributionContext.responseToClientMessage(EODistributionContext.java:627)
Is done when handling a thrown exception that is normally silently swallowed.  You can set the NSLog debug level to DebugLevelInformational and the enable the NSLog.DebugGroupIO to log this root cause, though that will likely log a lot of other stuff in WO.


The 
Chuck




On 2014-10-10, 3:07 AM, "John Pollard" wrote:

If after clearing the undo stack I open a dummy undo group i.e.
            undoManager().removeAllActions();
            undoManager().beginUndoGrouping();
Then things do seem to run ok, so there is a dummy undoGrouping for the java client server side request handling code to close off, but seems a bit outlandish to do this, asking for more future problems?
John

On 10 Oct 2014, at 10:40, John Pollard <email@hidden> wrote:

I instead used the property er.extensions.ERXEC.editingContextClassName to specify the ForgetfulEC which I had  change to be subclassed from ERXEC

However, with the call to undoManager().removeAllActions() seems to tread on some toes; a later endUndoGrouping() called by some other code is now falling over with this exception...

- <er.extensions.appserver.ERXComponentRequestHandler>: Exception occurred while handling request:
java.lang.IllegalStateException: endUndoGrouping: undo manager is in invalid state, endUndoGrouping called with no matching begin
Oct 10 09:33:25 InraxServer[8888] DEBUG NSLog  - Handle Application Exception
Reporting exception at: 09:33
From: Application.handleException()

Original Request IP: 192.168.0.124 URI: /cgi-bin/WebObjects/InraxServer.woa/-8888/wo/0g6rgMRRb2p4aTaQYIIW7g/0.1.0.1.0 Session: 0g6rgMRRb2p4aTaQYIIW7g

Component: com.webobjects.eodistribution.WOJavaClientApplet

Exception message: endUndoGrouping: undo manager is in invalid state, endUndoGrouping called with no matching begin

Stack Trace...

java.lang.IllegalStateException: endUndoGrouping: undo manager is in invalid state, endUndoGrouping called with no matching begin
at com.webobjects.foundation.NSUndoManager.endUndoGrouping(NSUndoManager.java:565)
at com.webobjects.eodistribution.EODistributionContext.responseToClientMessage(EODistributionContext.java:626)
at com.webobjects.eodistribution.WOJavaClientApplet.handleClientRequest(WOJavaClientApplet.java:978)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
...



On 10 Oct 2014, at 09:50, John Pollard <email@hidden> wrote:

Thanks, I will give this a try.
I am using Java Client, not sure about the "applets" bit.
Currently the client session ec is created using ERXEC.newEditingContext(objStore)
So should I...
Create a sublcass of ERXEC.DefaultFactory and override _createEditingContext() in it, to return a ForgetfulEC
Install my factory using ERXEC.setFactory()
Anything else?
Thanks
John

On 9 Oct 2014, at 17:27, Chuck Hill <email@hidden> wrote:

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@hidden> 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@hidden> 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@hidden> 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@hidden> 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@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden





_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

 
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
References: 
 >Re: EOCustomObject valueForKey avoiding infinite recursion (From: John Pollard <email@hidden>)
 >Re: EOCustomObject valueForKey avoiding infinite recursion (From: John Pollard <email@hidden>)
 >Re: EOCustomObject valueForKey avoiding infinite recursion (From: John Pollard <email@hidden>)

  • Prev by Date: Re: Eclipse 4.2.2 + WOLips 4.2 WOComponent editor crash
  • Next by Date: Re: Data model suggestions...
  • Previous by thread: Re: EOCustomObject valueForKey avoiding infinite recursion
  • Next by thread: Re: ERCaptcha shows all black image
  • Index(es):
    • Date
    • Thread