See below: On Mar 17, 2009, at 11:07 , Kevin Sutter (via Nabble) wrote:
> Andrei, > More questions than answers, but let's see where this takes us... > > On Tue, Mar 17, 2009 at 7:45 AM, Andrei Tchijov <and...@...> 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. > Yes. There is corresponding "@ManyToOne" @ManyToOne private PLSObject object; > > > > > 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... I did reset it via SQL. > > 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? It seems to be working (numbers in this field do grow). I will need to do some additional testing to see if it is really "+1" per-commit. > > 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. No. This is how it looks from mySQL point of view +--------------+--------------+------+-----+------------------- +-----------------------------+ | Field | Type | Null | Key | Default | Extra | +--------------+--------------+------+-----+------------------- +-----------------------------+ | ID | int(11) | NO | PRI | NULL | | | version | int(11) | YES | | NULL | | | created | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP | | owner_ID | int(11) | NO | | NULL | | | DTYPE | int(11) | NO | | NULL | | | name | varchar(256) | NO | | NULL | | | className | varchar(256) | YES | | NULL | | | container_ID | int(11) | YES | | NULL | | | object_ID | int(11) | YES | MUL | NULL | | | flags | int(11) | YES | | 0 | | +--------------+--------------+------+-----+------------------- +-----------------------------+ and this is how it is defined in Java @SuppressWarnings("unused") @Version private int version; I do not know if it is relevant, but I have 2 classes mapped into the same table ( they both subclasses of the same class ). PLSRelationship is one of these classes and another class ( PLSObject ) is the one which contains "@ManyToOne" field which seems to be a problem. I have attached to this e-mail snippet of code which combines extracts from all relevant classes > > 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. The problem is that the very same code used to deal with many objects of the same class. And exception only gets thrown on very few (and once it start happening, always the same) of them I do have copy of DB with "bad" versions. If you can think of any additional tests, I can try to run them. > > 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. > > > > > > > This email is a reply to your post @ > http://n2.nabble.com/Strange-%22ClassCast%22-Exception-%28and-even-stranger-way-it-disappear%29-tp2491173p2491894.html > You can reply by email or by visting the link above. > -- View this message in context: http://n2.nabble.com/Strange-%22ClassCast%22-Exception-%28and-even-stranger-way-it-disappear%29-tp2491173p2492065.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
