Andrei, More questions than answers, but let's see where this takes us... On Tue, Mar 17, 2009 at 7:45 AM, Andrei Tchijov <[email protected]> wrote:
> > Out of blue, I started to get following exception: > http://n2.nabble.com/file/n2491173/ClassCastException.txt > ClassCastException.txt . > Thanks for the call stacks. These do show that the ClassCastException is coming from one of the inserted methods due to the enhancement process (pcReplaceField). So, at least we know that the enhancement processing is taking place. > To the best of my understanding, problem occur when I am trying to access > @OneToMany field defined as following: > > @OneToMany( mappedBy = "object", cascade = ALL ) > @MapKey(name = "name") > private Map<String,PLSRelationship> relationships; Is your "object" side of the relationship configured with a corresponding @ManyToOne? I can't see how this would manifest itself as a ClassCastException, but just checking. > > What was particularly weird, I have quite a few objects in the data base > and > this exception was happening only when I was trying to access particular 2 > of these objects. It was quite persistent too. It always was happening > when I was trying to access these 2 particular objects. > > I was trying to figure out what was so special about these 2 objects and > the > only thing I could see was that "@Version" field in records representing > one > of PLSRelationship "related" to objects which were giving me an exception > were non null ( it was "1" ). On the wimp, I have reset value of all > "@Version" fields to null and now it works without any problems. Reset these fields via SQL direct to the database? You shouldn't be able to directly set the @Version field via your program. Here again, I'm not seeing the correlation to the ClassCastException... Since you reset this Version field, I would assume that the Version field now has "valid" data in it? That is, each time the Entities get committed, the Version field should be incremented. Have you verified that the Version field seems to working as expected? Is there any chance that the definition of this Version field changed during this exercise? For example, maybe it was changed from a Timestamp to a Long? And, the contents of the database records for these two objects had an invalid value for the corresponding type? Just an idea. I'm stating the obvious here, but ClassCastExceptions normally happen due to incorrect ClassLoaders being used. Either the Class is not available, or a different ClassLoader was used for a given instance of the Class. Since we seem to tripping over the Version field, we're probably attempting to load the instance data for comparison purposes and then hit the ClassCastException. Any of these ideas help with narrowing down the problem? Kevin > > I would greatly appreciate if some one can shade some light on this issue. > Obviously, I am doing something wrong and manage to get my data base into > state which OpenJPA did not like much. The problem is that I have no idea > what exactly I did wrong (and how to prevent it from happening). > > You comments will be highly appreciated, > > Andrei > > P.S. I am running OpenJPA 1.2.0 with mySQL. All classes are enchanted > during build time (using ant task). > -- > View this message in context: > http://n2.nabble.com/Strange-%22ClassCast%22-Exception-%28and-even-stranger-way-it-disappear%29-tp2491173p2491173.html > Sent from the OpenJPA Users mailing list archive at Nabble.com. > >
