Well, I found it.
First, a patch:
Index: main/org/exolab/castor/jdo/engine/SQLEngine.java
===================================================================
RCS file: /cvs/castor/castor/src/main/org/exolab/castor/jdo/engine/ SQLEngine.java,v
retrieving revision 1.17
diff -r1.17 SQLEngine.java
923,924c923,924
<
< if (_fields[i].tableName.compareTo(_mapTo) == 0 && !original[i].equals(currentField)) {
---
>
> if (currentField!=null && _fields[i].tableName.compareTo(_mapTo) == 0 && !original[i].equals(currentField)) {
Note that we weren't checking if currentField was null; don't know *WHY* that creates a problem, but it clearly did. That solved the NPE, leading to the actual problem...
Now, the resulting exception:
org.exolab.castor.jdo.ObjectModifiedException: Transaction aborted: Object of type com.wow.framework.dao.UserSubs
criptionService with identity 16 has been modified by a concurrent transaction (cache entry is different from dat
abase row). The following fields have been changed [actual/expected value]: (com.wow.framework.dao.UserSubscripti
onService).activation_date: [2004-07-27/2004-07-27 13:47:27.0]
at org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:933)
at org.exolab.castor.persist.ClassMolder.store(ClassMolder.java:1613)
at org.exolab.castor.persist.LockEngine.store(LockEngine.java:756)
at org.exolab.castor.persist.TransactionContext.prepare(TransactionContext. java:1546)
at org.exolab.castor.jdo.engine.DatabaseImpl.commit(DatabaseImpl.java:495)
at com.wow.framework.dao.jdo.impl.AbstractJDOLoader.release(AbstractJDOLoad er.java:69)
at com.wow.framework.dao.jdo.impl.DAOFactory.updateUser(DAOFactory.java: 457)
at com.wow.framework.dao.impl.PluggableDAOFactory.updateUser(PluggableDAOFa ctory.java:252)
at com.wow.framework.dao.User.update(User.java:107)
at com.wow.webapp.pageComponents.registration.TermsAndConditionsPageCompone nt.init(TermsAndConditionsPage
Component.java:91)
On 28 Jul 2004, at 15:57, Gregory Block wrote:
java.lang.NullPointerException
at org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:924)
at org.exolab.castor.persist.ClassMolder.store(ClassMolder.java:1613)
at org.exolab.castor.persist.LockEngine.store(LockEngine.java:756)
at org.exolab.castor.persist.TransactionContext.prepare(TransactionContext .java:1545)
at org.exolab.castor.jdo.engine.DatabaseImpl.commit(DatabaseImpl.java: 495)
at com.wow.framework.dao.jdo.impl.AbstractJDOLoader.release(AbstractJDOLoa der.java:69)
at com.wow.framework.dao.jdo.impl.DAOFactory.updateUser(DAOFactory.java: 457)
at com.wow.framework.dao.impl.PluggableDAOFactory.updateUser(PluggableDAOF actory.java:252)
at com.wow.framework.dao.User.update(User.java:107)
at com.wow.webapp.pageComponents.registration.TermsAndConditionsPageCompon ent.init(TermsAndConditionsPage
Component.java:91)
Looking at it, lock.invalidate doesn't get called because it's neither an ObjectModifiedException nor a PersistenceException - thinking that's the culprit...
As for what's causing that NPE? Not a clue. Wish I knew, as it's driving me nuts. However, it gives a stream of completely unrelated errors when it dies, that's for sure. Again, there was a constraints violation (would be nice if I could tell castor, somehow, that when an integer value is 0, it should instead use null...), but this particular instance isn't related to that particular problem. Don't know quite what the problem is yet, of course...
-----------------------------------------------------------If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
