Re: Class cast exception thrown in in EODistributionContext
Re: Class cast exception thrown in in EODistributionContext
- Subject: Re: Class cast exception thrown in in EODistributionContext
- From: Florijan Stamenkovic <email@hidden>
- Date: Fri, 27 Jun 2008 14:12:04 -0400
Daryl,
Thanks for the reply.
Is the code snippet you have sent iterating over newly created
objects? Or perhaps all modified objects? It looks like that really
is the bad cast location. As to why that happens, no clue yet, but
here are some more observations that I've made on how to cause this
exception to happen...
1. I can create and save the StructureItems on the server side, no
problem. This makes me think that the model is essentially OK.
2. On the client side, in certain ways I can create and save the EOs,
the problem only occurs if I do it this way:
Relate the newly created EO to a Project (through either "project",
or "projectDirect" relationships) by using "addObjectToBothSides...".
It does not seem to matter if I only set one relationship, or both,
or whatever. I get an error. BUT, if I use the generated setter,
which in turn uses "takeStoredValueForKey...", and the inverse side
is ignored, the error does not happen, and my save is successful.
Another interesting thing is that if I use the "addToBothSides..."
with a relationship to the same entity (the "parent" relationship),
and I relate to the Project with "takeStoredValue...", I can save, no
error. Also, it is super bizarre that I use "addObjectToBoth..." all
the time in other places (when creating EOs of various different
types), and have not had any problems with those.
In short, this seems to be the recipe for disaster: Java Client +
StructureItem entity + either relationship to Project +
addObjectToBothSides...
So, how to proceed? The only "outstanding" thing I can observe in
this setup is that I relate the StructureItem entity to the Project
entity twice. Two foreign keys, two relationships. I can not be sure
that this is the cause of trouble, and since this is one of my
production apps, I am only willing to fuss with it so much. But, if
you think this could be the issue, I can set a test case up in which
we would be much more free to kick relationships around to see which
setup exactly causes this.
F
- or could it be that the inverse side of the relationship is causing
this trouble, that it is the Project EO that is being evaluated when
the class cast exception is thrown?
On Jun 27, 2008, at 12:47, Daryl Lee wrote:
Well, it's at the point of the stack trace you're iterating over
toMany attributes. In 5.3.3, it looks like we're trying to cast to
an NSMutableArray if the line number is correct.
<Picture 2.png>
On Jun 27, 2008, at 6:26 AM, Florijan Stamenkovic wrote:
Daryl, perhaps you could point out what might be causing this
class cast exception from the WO source? What is WO's type
assumption that I am somehow violating? Or maybe it is a bug?
_______________________________________________
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