In tracing back the castor source, we've noted the following:
The exception is thrown in ClassMolder.load(ClassMolder.java:625)
for ( int i = 0; i < _fhs.length; i++ ) {
fieldType = _fhs[i].getFieldType();
switch (fieldType) {
case FieldMolder.PRIMITIVE:
case FieldMolder.SERIALIZABLE:
case FieldMolder.PERSISTANCECAPABLE:
case FieldMolder.ONE_TO_MANY:
case FieldMolder.MANY_TO_MANY:
-> _resolvers[i].load(tx, oid, proposedObject, accessMode,
fields[i]);
break;
default:
throw new PersistenceException("Unexpected field type!");
}
}
the exact issue is that fields is different to resolvers and _fhs.length,
such that (fields.length != resolvers.length) && (fields.length !=
_fhs.length).
Something happens to _fhs between the proposedObject.setFields being
called, and this function (ClassMolder.load) being called.
This appears to be due to something in the new polymorphism - The object
in question is an extended class.
Has anyone else experienced this issue? we're experiencing issues in
reproducing the problem, as it is quite inconsistent.
--
//chris
<quote who="Chris Hoy Poy">
> Goodmorning all,
>
> We updated to Castor-0.9.9, with java 1.5.0_5.
>
> We're starting to see this exception in ClassMolder.load (which I
> understand was recently heavily modified etc):
>
>
> java.lang.ArrayIndexOutOfBoundsException: 15
> at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:625)
> at org.exolab.castor.persist.LockEngine.load(LockEngine.java:368)
> at
> org.castor.persist.TransactionContext.load(TransactionContext.java:713)
> at org.exolab.castor.persist.QueryResults.fetch(QueryResults.java:232)
> at
> org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.hasMore(OQLQueryImpl.java:584)
> at
> org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.hasMore(OQLQueryImpl.java:567)
> at
> au.com.mpl.xeder.entity.DBObjectFactory.OQLFetchObjectList(DBObjectFactory.java:364)
>
>
> I'm currently putting together a test case for this, but its fairly
> complex so it might take me a while (time constraints and so forth).
>
> The worst bit is that the problem appears to be fairly random, so it might
> something to do with our locking modes.. also the part where it happens
> might sometimes result in us hitting the castor code to load certain
> components (in the same thread) fairly rapidly (but always in the
> read-only mode). (although they will be made using the OQL query, rather
> then db.load).
>
>
> Any ideas? Been through the JIRA, found a couple of older entries that
> might be related, but doubtful if its been rewritten.
>
> then again, it could just be the way we are using castor as well ;) hard
> to say.
>
> Has anyone else seen this issue?
>
>
> Cheers;
>
> --
> //chris
>
>
>
>
> -------------------------------------------------
> If you wish to unsubscribe from this list, please
> send an empty message to the following address:
>
> [EMAIL PROTECTED]
> -------------------------------------------------
>
>
>
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
