[castor-dev] Re: [castor-user] Project Update, Need your vote!
I'd prefer to be automatically resubscribed. --- Keith Visco [EMAIL PROTECTED] wrote: Hi all, We're currently in the process of moving the project over to codehaus.org. Please be patient with us during the move process. As part of this process we need to create new mailing lists. We'd like to get your vote on whether we should re-subscribe everyone automatically to the new lists or would you all prefer to re-subscribe yourselves (an opt-in approach)? Please voice your opinion on this, as well go with the majority. If we do it automatically you'll have to make sure you update any personal mail filters you currently have. Thanks, --Keith --- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-user --- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
Re: [castor-dev] Castor 0.9.6-RC3 lazy loading net.sf.cglib.core.CodeGenerationException
Done...It's http://bugzilla.exolab.org/show_bug.cgi?id=1855 --- Werner Guttmann [EMAIL PROTECTED] wrote: Jon, can you please file a bug report at http://bugzilla.exolab.org, and I'll look into this issue tomorrow. Actually, I have not changed lazy loading for collections, but only introduced support for lazy loading for 1:1 relations. But it looks to me like Castor is getting confused a bug about where to apply which method. Thanks Werner On Sat, 15 Jan 2005 18:23:40 -0800 (PST), Jon Wilmoth wrote: It looks like the lazy loading has changed in 0.9.6 from 0.9.5.3. I'm getting an reflection based exception trying to load a class that has a property who in turn has a lazy loaded collection. The lazy loaded property on the Project class has the following mapping/java declaration: //marked transient since the castor persistent collection is not serializeable protected transient Collection phases = new ArrayList(); field name=phases type=com.apex.chronos.app.project.Phase lazy=true collection=collection sql many-key=PROJECT_ID/ bind-xml name=phases node=element transient=false/ /field What do I need to do to get lazy loading working in this release? Thanks, Jon Jan-15-2005 5:56:56:020 PM, PST [ERROR] (org.exolab.castor.persist.SingleProxy:?) -- error on enhance class com.apex.chronos.app.project.Project net.sf.cglib.core.CodeGenerationException: java.lang.IllegalAccessException--Class org.exolab.castor.persist.SingleProxy can not access a member of class com.apex.chronos.app.project.BasicProject with modifiers protected at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:235) at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:220) at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:216) at net.sf.cglib.proxy.Enhancer.createUsingReflection(Enhancer.java:566) at net.sf.cglib.proxy.Enhancer.firstInstance(Enhancer.java:493) at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:220) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:368) at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:280) at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:597) at org.exolab.castor.persist.SingleProxy.getProxy(ClassMolder.java:3243) at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:776) at org.exolab.castor.persist.LockEngine.load(LockEngine.java:361) at org.exolab.castor.persist.TransactionContext.load(TransactionContext.java:698) at org.exolab.castor.persist.QueryResults.fetch(QueryResults.java:229) at org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.hasMore(OQLQueryImpl.java:602) at org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.hasMore(OQLQueryImpl.java:585) at com.apex.chronos.app.AbstractBusinessObject.executeFind(AbstractBusinessObject.java:841) at com.apex.chronos.app.AbstractBusinessObject.executeFind(AbstractBusinessObject.java:817) at com.apex.chronos.app.AbstractBusinessObject.executeFind(AbstractBusinessObject.java:809) at com.apex.chronos.app.authorization.ProjectRoleAssignment.findByPersonIdAndProjectId(ProjectRoleAssignment.java:121) at com.apex.chronos.app.authorization.AuthorizationGuard.getProjectRoleAssignments(AuthorizationGuard.java:332) at com.apex.chronos.app.authorization.AuthorizationGuard.getActiveProjectRoleAssignments(AuthorizationGuard.java:347) at com.apex.chronos.app.authorization.AuthorizationGuard.hasProjectAuthorization(AuthorizationGuard.java:701) at com.apex.chronos.app.authorization.AuthorizationGuard.isAuthorized(AuthorizationGuard.java:125) at com.apex.chronos.app.authorization.AuthorizationGuard.isAuthorizedToView(AuthorizationGuard.java:74) at com.apex.chronos.app.AbstractBusinessObject.internalFindByPrimaryKey(AbstractBusinessObject.java:900) at com.apex.chronos.app.AbstractBusinessObject.internalFindByPrimaryKey(AbstractBusinessObject.java:880) at com.apex.chronos.app.project.BasicProject.findByPrimaryKey(BasicProject.java:216) at com.apex.chronos.ui.integration.ExportTimeSheetAction.constructExportableTimeSheet(ExportTimeSheetAction.java:281) at com.apex.chronos.ui.integration.ExportTimeSheetAction.exportToQBOE(ExportTimeSheetAction.java:158) at com.apex.chronos.ui.integration.ExportTimeSheetAction.doPerform(ExportTimeSheetAction.java:78) at com.apex.chronos.ui.AbstractAction.execute(AbstractAction.java:161) --- 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
[castor-dev] Castor 0.9.6-RC3 lazy loading net.sf.cglib.core.CodeGenerationException
It looks like the lazy loading has changed in 0.9.6 from 0.9.5.3. I'm getting an reflection based exception trying to load a class that has a property who in turn has a lazy loaded collection. The lazy loaded property on the Project class has the following mapping/java declaration: //marked transient since the castor persistent collection is not serializeable protected transient Collection phases = new ArrayList(); field name=phases type=com.apex.chronos.app.project.Phase lazy=true collection=collection sql many-key=PROJECT_ID/ bind-xml name=phases node=element transient=false/ /field What do I need to do to get lazy loading working in this release? Thanks, Jon Jan-15-2005 5:56:56:020 PM, PST [ERROR] (org.exolab.castor.persist.SingleProxy:?) -- error on enhance class com.apex.chronos.app.project.Project net.sf.cglib.core.CodeGenerationException: java.lang.IllegalAccessException--Class org.exolab.castor.persist.SingleProxy can not access a member of class com.apex.chronos.app.project.BasicProject with modifiers protected at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:235) at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:220) at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:216) at net.sf.cglib.proxy.Enhancer.createUsingReflection(Enhancer.java:566) at net.sf.cglib.proxy.Enhancer.firstInstance(Enhancer.java:493) at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:220) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:368) at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:280) at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:597) at org.exolab.castor.persist.SingleProxy.getProxy(ClassMolder.java:3243) at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:776) at org.exolab.castor.persist.LockEngine.load(LockEngine.java:361) at org.exolab.castor.persist.TransactionContext.load(TransactionContext.java:698) at org.exolab.castor.persist.QueryResults.fetch(QueryResults.java:229) at org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.hasMore(OQLQueryImpl.java:602) at org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.hasMore(OQLQueryImpl.java:585) at com.apex.chronos.app.AbstractBusinessObject.executeFind(AbstractBusinessObject.java:841) at com.apex.chronos.app.AbstractBusinessObject.executeFind(AbstractBusinessObject.java:817) at com.apex.chronos.app.AbstractBusinessObject.executeFind(AbstractBusinessObject.java:809) at com.apex.chronos.app.authorization.ProjectRoleAssignment.findByPersonIdAndProjectId(ProjectRoleAssignment.java:121) at com.apex.chronos.app.authorization.AuthorizationGuard.getProjectRoleAssignments(AuthorizationGuard.java:332) at com.apex.chronos.app.authorization.AuthorizationGuard.getActiveProjectRoleAssignments(AuthorizationGuard.java:347) at com.apex.chronos.app.authorization.AuthorizationGuard.hasProjectAuthorization(AuthorizationGuard.java:701) at com.apex.chronos.app.authorization.AuthorizationGuard.isAuthorized(AuthorizationGuard.java:125) at com.apex.chronos.app.authorization.AuthorizationGuard.isAuthorizedToView(AuthorizationGuard.java:74) at com.apex.chronos.app.AbstractBusinessObject.internalFindByPrimaryKey(AbstractBusinessObject.java:900) at com.apex.chronos.app.AbstractBusinessObject.internalFindByPrimaryKey(AbstractBusinessObject.java:880) at com.apex.chronos.app.project.BasicProject.findByPrimaryKey(BasicProject.java:216) at com.apex.chronos.ui.integration.ExportTimeSheetAction.constructExportableTimeSheet(ExportTimeSheetAction.java:281) at com.apex.chronos.ui.integration.ExportTimeSheetAction.exportToQBOE(ExportTimeSheetAction.java:158) at com.apex.chronos.ui.integration.ExportTimeSheetAction.doPerform(ExportTimeSheetAction.java:78) at com.apex.chronos.ui.AbstractAction.execute(AbstractAction.java:161) --- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
[castor-dev] Castor 0.9.6-RC3 database loading issues
I know time went into fixing the loading of mapping
relative paths within a database.xml file, but I
wasn't able to get this working with the new release.
Trying to work around the problem, I switched to a
fully qualified file url for each mapping element in
my database xml file. This fixes the
FileNotFoundExceptions, but now I'm getting an
org.exolab.castor.jdo.DatabaseNotFoundException:
Nested error: unable to find FieldDescriptor for
'jndi' in ClassDescriptor of jdo-conf{file:
file:///C:/dev/java/jakarta/tomcat-5.0.28/webapps/chronos/WEB-INF/CastorDatabaseConfig.xml;
line: 4; column: 47}: Nested error: unable to find
FieldDescriptor for 'jndi' in ClassDescriptor of
jdo-conf{file:
file:///C:/dev/java/jakarta/tomcat-5.0.28/webapps/chronos/WEB-INF/CastorDatabaseConfig.xml;
line: 4; column: 47}
I searched the list archives and saw a single
(seemingly un-resolved) email with the same problem
reported in 0.9.5.4. Is the relative path bug fix
supposed to be included in this release candidate? Is
there a workaround/permanent solution to the later problem?
---
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
Re: [castor-dev] Castor 0.9.6-RC3 database loading issues
Sure. Let me know what I can do.
--- Keith Visco [EMAIL PROTECTED] wrote:
Hi Jon,
This may be a similar issue to the one reported
here:
http://bugzilla.exolab.org/show_bug.cgi?id=1834
That bug was fixed for RC3, but there may be another
jdo descriptor file
which needs the same fix that I applied to the
CategoryDescriptor.java.
I guess this means that the JDO test cases didn't
catch this problem, if
you're willing to use the CVS version to help us
test, I can try and
hunt down the descriptor for jdo-conf and make the
same change I made to
the CategoryDescriptor.java as described in the
above bug.
Thanks,
--Keith
Jon Wilmoth wrote:
I know time went into fixing the loading of
mapping
relative paths within a database.xml file, but I
wasn't able to get this working with the new
release.
Trying to work around the problem, I switched to a
fully qualified file url for each mapping
element in
my database xml file. This fixes the
FileNotFoundExceptions, but now I'm getting an
org.exolab.castor.jdo.DatabaseNotFoundException:
Nested error: unable to find FieldDescriptor for
'jndi' in ClassDescriptor of jdo-conf{file:
file:///C:/dev/java/jakarta/tomcat-5.0.28/webapps/chronos/WEB-INF/CastorDatabaseConfig.xml;
line: 4; column: 47}: Nested error: unable to find
FieldDescriptor for 'jndi' in ClassDescriptor of
jdo-conf{file:
file:///C:/dev/java/jakarta/tomcat-5.0.28/webapps/chronos/WEB-INF/CastorDatabaseConfig.xml;
line: 4; column: 47}
I searched the list archives and saw a single
(seemingly un-resolved) email with the same
problem
reported in 0.9.5.4. Is the relative path bug fix
supposed to be included in this release candidate?
Is
there a workaround/permanent solution to the later
problem?
---
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
---
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
Re: [castor-dev] switch from CVS to Subversion
Having used Castor for over 2 years and monitored the mailing lists for almost as long I've never heard anyone state a problem with CVS. I realize it's probably not a big effort to change, but I'd prefer to see any effort of the Castor team geared toward actually improve the Castor product itself (i.e. closing bugs, getting releases out). --- Werner Guttmann [EMAIL PROTECTED] wrote: Good evening everybody, trying to keep things short at this point in time, so please excuse my briefness. Werner On Mon, 3 Jan 2005 18:14:13 -0600 (CST), Keith Visco wrote: Hey Martin, et al., I hope you had a wonderful holiday. As for Subversion, I think I'm in the Why fix it if it isn't broke camp that Nick mentioned in his previous reponse. I really don't think we have any resources to put on this, and I'm very happy with CVS and my WinCVS client that I don't really see any need to switch. If we were experiencing problems with CVS or we desperately needed some feature in Subversion that doesn't exist in CVS I think this would be more of an issue. +1. Iow, exactly my thoughts. Is there anything that does not work properly (or at all) with CVS. Or does subversion offer features that we lack right now ? Having said that, please note that I am not on the resisting side, but just like to be convinced. Just my $0.02. Of course with the U.S. Dollar being at an all time low verse the Euro, I guess my 2 cents doesn't go as far as it used to! :-) Being on the Euro side of things, my 0.02 cents make me go further and further these days ... , Werner --Keith Hello, is there already any plan to switch from CVS as source code repository to the successor Subversion? I think Subversion has now become quite stable, and we could take advantage of reworked new tool. Here you can read about all the new features compared to CVS: http://subversion.tigris.org/ There exists a python script cvs2svn, which makes the conversion of the CVS repository quite easy. I shortly did this transition with two CVS repos, and found now problems. The complete history is preserved, and even tags and branches are available after. On the client side there are available several different SVN clients. First of all there is the standard command line client. For integrated Java development there is Eclipse plugin called Subclipse. And there is also a Explorer interface for MS Windows named TortoiseSVN. If there is interest, I could help in setting up the SVN server. Regards, Martin --- 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 --- 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
Re: [castor-dev] Castor 0.9.6 - 2nd release candidate
I'm getting a FileNotFoundException using mapping href's that are relative to my tomcat home (i.e. mapping href=./WEB-INF/castor/CASTOR-MAPPING-AccountPromotion.xml/). Since the path prefixing the file name is prepended to the original path in the href attribute (example below) I believe this is the same problem captured in http://bugzilla.exolab.org/show_bug.cgi?id=1798. Was 1798 supposed to be included in this candidate? Is there a workaround this problem in this candidate? FileNotFoundException path: ./WEB-INF/castor/./WEB-INF/castor/CASTOR-MAPPING-AccountPromotion.xml Thanks, Jon --- Werner Guttmann [EMAIL PROTECTED] wrote: Hi, I've placed a copy of the second release candidate for Castor 0.9.6 on the FTP server. This is mainly a bug fix release, but includes a couple of new features as well. For details about the bugs fixed and features provided, please have a look at (an interim version of) the release notes (link provided below). The release notes have been updated to include any regression issues found since the first release candidate has been made available. The release candidate will be replaced by the official version within the next week, so please try this version and report any regression issues (where applicable). A regression for this release is something that was working in 0.9.5.3/0.9.5.4 but no longer is working in this 0.9.6 release candidate. Only regression issues will be considered for fixing before the final 0.9.6 release. All other bugs will be moved out to 0.9.7, or a 0.9.6.x sub-release if necessary. Pleased make sure that you read the release notes carefully before trying to use this new release candidate, as we have made some changes on the JDO side of things that require you to e.g. change the structure of your JDO configuration file. All issues should initially be reported to the castor-dev list only. For serious problems, please don't hesitate to create a bug report at http://bugzilla.exolab.org. Download: ftp://ftp.exolab.org/pub/castor/castor_0.9.6/ Release notes: http://brainopolis.dnsalias.com/castorwiki/Wiki.jsp?page=ReleaseNotes096 Regards Werner --- 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
Re: [castor-dev] MappingException: Field element, java.sql.Time not found!
Bruce, I take it you were able to reproduce the MappingException? Jon --- Bruce Snyder [EMAIL PROTECTED] wrote: Jon Wilmoth wrote: With a field defined like the one below I get a mapping exception. What is the correct mapping type values for Time SQL field? Is java.sql.Time supported for the java field type? Thanks, Jon p.s. I realize this is a cross-post, but if it's not a supported feature I need it and would be willing to submit a patch. field name=defaultEntryStartTime type=java.sql.Time required=true sql name=DEFAULT_ENTRY_START_TIME type=time/ /field org.exolab.castor.mapping.MappingException: Field element, java.sql.Time not found! at org.exolab.castor.persist.DatingService.close(DatingService.java:134) at org.exolab.castor.persist.ClassMolder.resolve(ClassMolder.java:525) Jon, I'm currently debugging this problem. I'll let you know what I find. Bruce -- perl -e 'print unpack(u30,0G)[EMAIL PROTECTED]5R\\F9EG)E=\\$\\!FFEI+F-O;0\\`\\`);' The Castor Project http://www.castor.org/ Apache Geronimo http://incubator.apache.org/projects/geronimo.html --- 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
Re: [castor-dev] JDO object creation performance flaw
I for one, think it's a very acceptable compromise. (lazy loading performance gains for a 1.3 runtime.Werner Guttmann [EMAIL PROTECTED] wrote: Stephen,Not so sure here, as some committers are very keen to keep things 100% compatible with JRE/JDK 1.2. Well, I think I am going to ask our users here to get a full picture of the status quo.WernerOn Fri, 2 Jul 2004 06:23:56 -0400, Stephen Ince wrote:Werner, The proxy interface approach looks clean and sound. I think 99% areusing jdk 1.3 and up?Steve- Original Message - From: "Werner Guttmann" <[EMAIL PROTECTED]>To: <[EMAIL PROTECTED]>Sent: Thursday, July 01, 2004 5:41 PMSubject: Re: [castor-dev] JDO object creation performance flaw Stephen, I am still in the process of readying a first patch for this feature. Inthe meantime, I'd like to bounce the following iss! ue with you and everybodyelse interested. It looks like the only way to go about a solution for this isvia dynamic proxies. This implies that ... a) support for 1:1 lazy loading will only be available for people usingJDK 1.3 and up. b) I'll need to introduce a new requirement to get this working. For anyclass that you want to lazy load as part of a simple 1:1 relation, you'llneed to have an interface. I checked with other tools like OJB, as it looks likethey have taken the same approach. Which comes as no surprise as dynamic proxies depend on interfaces. FWIW Werner On Thu, 1 Jul 2004 12:48:31 -0400, Stephen Ince wrote: No problem about testing lazy-loading 1:1. This would of course helploading of large about objects. I w! ill work on a performance patch for top-level objects with largenumber of dependent children. - Original Message - From: "Werner Guttmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 30, 2004 4:47 AM Subject: Re: [castor-dev] JDO object creation performance flaw Well, if that's the case .. ;-), what would you think about helping us with testing new code, whether it's a feature such as support for lazy-loading 1:1 relations or support for the transient attribute at the level.Right now, I've got a patch posted for the transient support, and I'd be very interested to get some hands-on comments. Interested ?! Werner On Tue, 29 Jun 2004 21:10:17 +0100, Gregory Block wrote: On 29 Jun 2004, at 15:18, Stephen Ince wrote: Steve -- I think it is an issue for 1:m relations and not for 1:1 relations.At this point, anything which can be done to offer the capability to fragment and delay queries is good; more importantly, if that partial loading then uses the cache, anything with 1:1 mappings where theother half of the 1 in question is shared by many should instantly see an improvement.So thumbs up on that lazy-load of 1:1, it's still good to see. :) --- 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 --- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of:&! gt; unsubscribe castor-dev --- 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--- 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
Re: [castor-dev] [JDO?] ClassMolder.create FieldMolder.PERSISTANCECAPABLE type field bug?
I've created a bugzilla bug report (http://bugzilla.exolab.org/show_bug.cgi?id=1653) and attached 6 files: Book/Author classes (w/MySQL ddl included), mapping docs, a db file and a JUnit test case demonstrating the issue. Because I've defined my fk column as not-null, the test case fails due to a SQL exception, but I added another assertion to demonstrate the problem if the FK column wasn't not-null constrained. --- Werner Guttmann [EMAIL PROTECTED] wrote: Jon, you are right that we (aka developers) are quite busy, but that does not excuse us from replying to your questions. Having said that, and having read below findings, can I please ask you to a) create a bug report at http://bugzilla.exolab.org with a detailed description. b) attach the following information.: - a (JUnit) test case that I can use to see and experience the problem myself. - a mapping file. - some Java (entity) classes. - information about the RDBMS you are using. - DDL for the tables used. And above all, please try to be as minimal as possible when submitting your code. Iow, throw out everything that is not required to run the tests and show the problem. Regards Werner On Fri, 4 Jun 2004 09:24:35 -0700 (PDT), Jon Wilmoth wrote: I changed a local copy of ClassMolder.getIdentity(TransactionContext tx, Object o) to always return the value of getActualIdentity(TransactionContext tx, Object o) to try and see what the comment about a dummy identity being returned the case where key generator is used, was about and I don't see any fake values being returned. What I do see is my original problem is fixed! Original Problem: Unable to create objects (in a long trxn context) that have existing mapped object(s) as properties because the ClassMolder.getIdentity(TransactionContext tx, Object o) method returns null for objects that are key generated and either not read-only or persistent. For example: One txn retrieves an existing object Long existingId = ...; MyObject existing = Database.load(MyObject.class, existingId); A subsequent txn uses the previously loaded, non-persistent object to create a new object MyComplexObject newComplex = new MyComplexObject(); newComplex.setMyObject(existing); Database.create(newComplex); I realize the project developers are busy, but this seems like a core issue and I'm hoping someone has some feedback to help debunk/resolve this issue. Jon --- Jon Wilmoth [EMAIL PROTECTED] wrote: I've been working around the area effected by this issue, but thought I'd try to get some more info/spawn some more thought on this topic. There's a comment in the ClassMolder.getIdentity(TransactionContext, Object) method code that says: In the case where key generator is used, the value of identity is dummy, set it to null. Wouldn't this statement be limited to objects being newly created? The problem that I see is that it doesn't allow for accessing the identity of an existing object in a long transaction (i.e. where the existing object hasn't been marked persistent. The workaround I'm considering is to load the castor mapped objects prior to calling Database.create on the object that has these objects as field members in order to have the create method correctly get their identities. This seeems like a terribly inefficient solution (I'm introducing 3 unnecessary db queries) for one save operation. Are there other alternatives? Thanks, Jon --- 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 --- 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
Re: [castor-dev] [JDO?] ClassMolder.create FieldMolder.PERSISTANCECAPABLE type field bug?
I changed a local copy of ClassMolder.getIdentity(TransactionContext tx, Object o) to always return the value of getActualIdentity(TransactionContext tx, Object o) to try and see what the comment about a dummy identity being returned the case where key generator is used, was about and I don't see any fake values being returned. What I do see is my original problem is fixed! Original Problem: Unable to create objects (in a long trxn context) that have existing mapped object(s) as properties because the ClassMolder.getIdentity(TransactionContext tx, Object o) method returns null for objects that are key generated and either not read-only or persistent. For example: One txn retrieves an existing object Long existingId = ...; MyObject existing = Database.load(MyObject.class, existingId); A subsequent txn uses the previously loaded, non-persistent object to create a new object MyComplexObject newComplex = new MyComplexObject(); newComplex.setMyObject(existing); Database.create(newComplex); I realize the project developers are busy, but this seems like a core issue and I'm hoping someone has some feedback to help debunk/resolve this issue. Jon --- Jon Wilmoth [EMAIL PROTECTED] wrote: I've been working around the area effected by this issue, but thought I'd try to get some more info/spawn some more thought on this topic. There's a comment in the ClassMolder.getIdentity(TransactionContext, Object) method code that says: In the case where key generator is used, the value of identity is dummy, set it to null. Wouldn't this statement be limited to objects being newly created? The problem that I see is that it doesn't allow for accessing the identity of an existing object in a long transaction (i.e. where the existing object hasn't been marked persistent. The workaround I'm considering is to load the castor mapped objects prior to calling Database.create on the object that has these objects as field members in order to have the create method correctly get their identities. This seeems like a terribly inefficient solution (I'm introducing 3 unnecessary db queries) for one save operation. Are there other alternatives? Thanks, Jon --- 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
Re: [castor-dev] [JDO?] ClassMolder.create FieldMolder.PERSISTANCECAPABLE type field bug?
I've been working around the area effected by this issue, but thought I'd try to get some more info/spawn some more thought on this topic. There's a comment in the ClassMolder.getIdentity(TransactionContext, Object) method code that says: In the case where key generator is used, the value of identity is dummy, set it to null. Wouldn't this statement be limited to objects being newly created? The problem that I see is that it doesn't allow for accessing the identity of an existing object in a long transaction (i.e. where the existing object hasn't been marked persistent. The workaround I'm considering is to load the castor mapped objects prior to calling Database.create on the object that has these objects as field members in order to have the create method correctly get their identities. This seeems like a terribly inefficient solution (I'm introducing 3 unnecessary db queries) for one save operation. Are there other alternatives? Thanks, Jon --- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
Re: [castor-dev] [JDO?] ClassMolder.create FieldMolder.PERSISTANCECAPABLE type field bug?
Should I create a bugzilla bug to track the resolution
of this issue?
--- Jon Wilmoth [EMAIL PROTECTED] wrote:
1) Before creating a BookContract instance, how have
you loaded the other entities? Using Database,
load()
I assume. And when you are about to create the
BookContract instance?
In order to populate the drop-downs of Books,
Authors,
and Publishers, I do use Database.load, but the
objects become transient (in the Castor sense) as
Database.commit() is called after querying the DB.
The Struts form that wraps the BookContract
initializes new/empty instances of Book, Author, and
Publisher (i.e. bookContract.setPublisher(new
Publisher()) ) if the fields are null (as is the
case
for a new BookContract) so the reflection mechanism
struts uses to populate the bean properties work.
Thus struts is populating the BookContract and it's
complex fields all while they are transient. I then
use Database.create() on that transient object.
Because the complex fields in the BookContract are
not
persisent the ClassMolder.getIdentity method returns
null even through the transient field has a not-null
identity.
2) Is there a particular reason why you are using
capacity 0 here ?
I've been using castor for almost 2 yrs and at some
point I was having caching issues with my usage. I
honestly don't recall the particulars, but I will
most
likely revisit how I generate the cache mapping
values. First I have to get C.R.U.D. functionality
working ;)
3) Specifying lazy=true in this context will
(unfortunately) not bring the desired results. At
the
moment, lazy loading works with collections only.
I am aware of this as I have seen the warning log
messages (very helpful!). I figured since it
doesn't
cause any problems with my current usage, I'd leave
my
current xsl stylesheet that generates the mappings
alone for now.
--- Werner Guttmann [EMAIL PROTECTED] wrote:
Jon,
please see below ...
Werner
On Tue, 18 May 2004 20:10:21 -0700 (PDT), Jon
Wilmoth wrote:
I'm using a number of long transactions in a
webapp,
so I'll abreviate the sequence of events. The
classes
mapping involved are below.
The basic premise is the user selects a Book,
Author,
and Publisher from dropdowns (dropdowns contain
id
property of each existing object).
Now the flow involving castor...
1) Struts populates BookContract.book.id,
BookContract.author.id and
BookContract.publisher.id
values. Logging in the setters shows this is
happening without error.
2) Struts action calls BookContract.save().
Logging
in this method shows all required fields have
values.
3) ClassMolder getIdentity returns null for
BookContract.book, BookContract.author,
BookContract.publisher field values.
Before creating a BookContract instance, how have
you loaded the other entities ? Using
Database,load() I assume. And when you are about
to
create
the BookContract instance,
Logging in the
ClassMolder.create method shows BookContract with
author, publisher, and book fields all with
non-null
id properties.
4) SQLEngine executes prepared statement with
nulls
bound to the A1_BOOK_CONTRACT.BOOK_ID,
A1_BOOK_CONTRACT.AUTHOR_ID, and
A1_BOOK_CONTRACT.PUBLISHER_ID columns which have
db
not null constraints.
package castor.sample;
public abstract class CastorClass implements
Persistent, TimeStampable, Serializable {
public void save() {
//...
Database db = getDatabase();
if (getId() == null) {
log.debug( Insert );
db.create(this);
} else {
log.debug( Update + getId() +
);
db.update(this);
}
//..
}
}
package castor.sample;
public class Author extends CastorClass {
protected Long id;
protected String firstName;
protected String lastName;
//Marked as transient because the castor
persistent
collection is not serializeable
protected transient Collection bookContracts =
new
ArrayList();
//getters setters ...
}
class name=castor.sample.Author
key-generator=Author_SEQUENCE
verify-constructable=true auto-complete=true
identity=id
cache-type type=unlimited capacity=0/
Is there a particular reason why you are using
capacity 0 here ?
map-to table=A1_AUTHOR/
field name=id type=long
sql name=ID type=bigint/
/field
field name=firstName type=string
sql name=FIRST_NAME type=char/
/field
field name=lastName type=string
sql name=LAST_NAME type=char/
/field
field name=bookContracts
type=castor.sample.BookContract required=true
lazy=true collection=collection
sql many-key=AUTHOR_ID/
/field
/class
key-generator name=IDENTITY
alias=Author_SEQUENCE
Re: [castor-dev] [JDO] many-to-many as two one-to-manys?
I agree it is a pretty complex object, but it allows for nice reuse of existing objects to form a new assignment relationship. While I look for a way to simplify, I think I've found a bug or undocumented feature ;) I posted a message a couple of days ago about a getting an org.exolab.castor.jdo.DataObjectAccessException: Type conversion error: could not set value of FieldMolder of com.apex.chronos.app.authorization.OrganizationRoleAssignment.setorganization(com.apex.chronos.app.party.Organization organization) with value of type java.lang.Long I thought the issue had resolved itself and was merely a problem with my browser caching my error page. Unfortunately, the same error popped up a couple of builds later. After spending a couple of days trying to hunt down my mapping error (including creating another, pure relationship mapping of Author, Book, and Publisher in a BookContract), I noticed that I was getting the same type of error but with the setPublisher method on the BookContract. Commenting out the Publisher object on the BookContract fixed the problem...the Author and Book objects came back just fine when doing a query on BookContract. Comparing the mappings, the Author, Book And Publisher field definitions were all the same (with different column names obviously), so I thought I was back at the same dead end. Then I realized that the Publisher mapping element in the database xml came after the BookContract mapping element, while the Author and Book (both of which worked) were positioned before the BookContract mapping element. The same situation existed with my original mapping of OrganizationRoleAssignment (Person and Role were positioned below, while Organization was positioned above). I moved the BookContract and OrganizationRoleAssignment mapping element in the database xml doc to the bottom and the Type conversion error: could not set value of FieldMolder problem went away. I'm just happy I've seemingly fixed a problem that's stalled me for 4 days and can make sure I position mapping documents correctly in the database file, but is this the way it should work? BROKEN: database mapping href=CASTOR-MAPPING-Author.xml/ mapping href=CASTOR-MAPPING-Book.xml/ mapping href=CASTOR-MAPPING-BookContract.xml/ mapping href=CASTOR-MAPPING-Publisher.xml/ /database FIXED: database mapping href=CASTOR-MAPPING-Author.xml/ mapping href=CASTOR-MAPPING-Book.xml/ mapping href=CASTOR-MAPPING-Publisher.xml/ !-- Must be below reference objects to resolve setXXX -- mapping href=CASTOR-MAPPING-BookContract.xml/ /database --- Bruce Snyder [EMAIL PROTECTED] wrote: Jon Wilmoth wrote: I have a Role object that can be combined with a Person object and a third object (i.e. Organization)to represent an individual being assigned to an particular Role. I'm planning on setting this up as 4 object mappings (3 seperate one-to-many relationships) per role assignment. Below is what I have outlined for an Org role assignment: 1) Role - has collection of OrganizationRoleAssignment objects 2) Person - has collection of OrganizationRoleAssignment objects 3) Organization - has collection of OrganizationRoleAssignment objects 4) OrganizationRoleAssignment - has reference to a Person, Role, Organization I've had problems trying to explicitely manage object relationships before, and realize that there are actually serveral many-to-many relationships (i.e. Organization - Role) here, so I wanted to know if this sort of mapping is supported by Castor JDO. Jon, Castor can certainly support this set of relationships. But whenever I see complex models like this I always ask myself if it can be simplified for many reaons. I'm wondering if there's really a reason to have this three way many-to-many set of relationships? Is there no way in which this can be simplified? Bruce -- perl -e 'print unpack(u30,0G)[EMAIL PROTECTED]5R\\F9EG)E=\\$\\!FFEI+F-O;0\\`\\`);' The Castor Project http://www.castor.org/ Apache Geronimo http://incubator.apache.org/projects/geronimo.html --- 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
[castor-dev] [JDO] many-to-many as two one-to-manys?
I have a Role object that can be combined with a Person object and a third object (i.e. Organization)to represent an individual being assigned to an particular Role. I'm planning on setting this up as 4 object mappings (3 seperate one-to-many relationships) per role assignment. Below is what I have outlined for an Org role assignment: 1) Role - has collection of OrganizationRoleAssignment objects 2) Person - has collection of OrganizationRoleAssignment objects 3) Organization - has collection of OrganizationRoleAssignment objects 4) OrganizationRoleAssignment - has reference to a Person, Role, Organization I've had problems trying to explicitely manage object relationships before, and realize that there are actually serveral many-to-many relationships (i.e. Organization - Role) here, so I wanted to know if this sort of mapping is supported by Castor JDO. --- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
Re: [castor-dev] [JDO] - Are explicit object relationships supported in Castor OQL?
It turns out it was a browser caching issue with rendering the query results. The change to mapping did work. Now that I have the relationships working it brings up a question related to performance and lazy load, which I'll start in a new email to make topical searches easier. --- Bruce Snyder [EMAIL PROTECTED] wrote: Jon Wilmoth wrote: That makes complete sense! What doesn't is why, after changing the parent's sql mapping to the FK column in the child table, why I still get the same org.exolab.castor.jdo.DataObjectAccessException: Type conversion error: could not set value of FieldMolder of Product.setproductGroup(ProductGroup productGroup) with value of type java.lang.Long error. Thanks for posting the mapping descriptor, but we still need to see the relevant client code. The exception makes no sense to me either. Maybe seeing the client code will help. Bruce -- perl -e 'print unpack(u30,0G)[EMAIL PROTECTED]5R\\F9EG)E=\\$\\!FFEI+F-O;0\\`\\`);' The Castor Project http://www.castor.org/ Apache Geronimo http://incubator.apache.org/projects/geronimo.html --- 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
[castor-dev] [JDO] lazy loaded collections
After turning on logging on my JDBC driver, I noticed that a seperate query statement was issued for each child object in a parent child relationship (i.e. ProductGroup -- Product). Query SELECT AA_PRODUCT_GROUP.PROD_GROUP_ID,AA_PRODUCT.PRODUCT_ID,AA_PRODUCT_GROUP.CATEGORY FROM AA_PRODUCT_GROUP LEFT OUTER JOIN AA_PRODUCT ON AA_PRODUCT_GROUP.PROD_GROUP_ID=AA_PRODUCT.PRODUCT_GROUP_ID execution time: 0 result set fetch time: 0 Followed by... Query SELECT AA_PRODUCT.NAME,AA_PRODUCT.PRODUCT_GROUP_ID FROM AA_PRODUCT WHERE AA_PRODUCT.PRODUCT_ID=1 execution time: 70 result set fetch time: 0 Query SELECT AA_PRODUCT.NAME,AA_PRODUCT.PRODUCT_GROUP_ID FROM AA_PRODUCT WHERE AA_PRODUCT.PRODUCT_ID=2 execution time: 0 result set fetch time: 0 Query SELECT AA_PRODUCT.NAME,AA_PRODUCT.PRODUCT_GROUP_ID FROM AA_PRODUCT WHERE AA_PRODUCT.PRODUCT_ID=3 execution time: 70 result set fetch time: 0 Query SELECT AA_PRODUCT.NAME,AA_PRODUCT.PRODUCT_GROUP_ID FROM AA_PRODUCT WHERE AA_PRODUCT.PRODUCT_ID=4 execution time: 10 result set fetch time: 0 In some instances I would want to load the children (i.e. a ProductGroup detail page) and other cases I wouldn't want to spend time loading the children (i.e. a ProductGroup search results page that didn't display any Product info). So...my first question, is there a way to specify lazy loading of a field at runtime? In an effort to optimize, I turned the field lazy attribute value from false to true in the ProductGroup mapping, which resulted in just the first sql query being issued...so far so good. However, after closing the query via a database.close() call, and returning the ProductGroup object to the presentation tier, I got the following exception when trying to access the ProductGroup's Products: java.lang.RuntimeException: Transaction is closed! org.exolab.castor.persist.RelationCollection$IteratorImp.lazyLoad(RelationCollection.java:282) org.exolab.castor.persist.RelationCollection$IteratorImp.next(RelationCollection.java:266) Which leads me to my second question: How are lazy loaded collections properly used in a web app environment? Am I supposed to leave the database object open until the presentation tier is done with the query. Am I supposed to loop through the search results (effectively loading them) before returning them to the presentation tier? Thanks, Jon --- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
Re: [castor-dev] [JDO] lazy loaded collections
Thanks for the responses! I think I'm going to try the pre-iterate approach as it will allow me to handle exceptions in the controller tier instead of in the presentation tier. I think that sort of flexibility would be greatly appreciated by people trying to tune their castor-based applications. Speaking of tuning...it would obviously be faster to execute one SQL statement that brought back the parent and all the children when a relationship field is NOT lazily loaded instead of issuing what appears to be one query for the parent and n queries for the children. Has anyone raised this topic as a potential change already? It seems like a significant performance issue if you have any number of child objects in a relationship at all... --- Werner Guttmann [EMAIL PROTECTED] wrote: Jon, just picking up on one of your questions below, as Patrick has provided answers to everything else. Werner On Thu, 6 May 2004 17:22:43 +0100, Patrick van Kann wrote: Hello Jon, Unfortunately, lazy loading can only be used in short transactions. The underlying RelationCollection holds a relationship to the transaction context in which the parent object is loaded, which it calls upon to load objects when iterator.next is called. If you have closed the transaction that loaded the parent object, it can't lazily load when you call iterator.next(). One strategy is to pre-iterate in the transaction, which could work in a situation where you are providing pages of results from a database query. In other words, iterate the first 10 items in the lazy loaded collection before closing the transaction and returning the object. Otherwise, you need to load the object from within your JSP page/presentation tier. If it is jsp, you could use the castor taglibrary to do this quite easily: http://castor-taglib.sourceforge.ne Hope this helps, Patrick -Original Message- From: Jon Wilmoth [mailto:[EMAIL PROTECTED] Sent: Thu 5/6/2004 4:59 PM To: [EMAIL PROTECTED] Subject: [castor-dev] [JDO] lazy loaded collections After turning on logging on my JDBC driver, I noticed that a seperate query statement was issued for each child object in a parent child relationship (i.e. ProductGroup -- Product). Query SELECT AA_PRODUCT_GROUP.PROD_GROUP_ID,AA_PRODUCT.PRODUCT_ID,AA_PRODUCT_GROUP.CATEGORY FROM AA_PRODUCT_GROUP LEFT OUTER JOIN AA_PRODUCT ON AA_PRODUCT_GROUP.PROD_GROUP_ID=AA_PRODUCT.PRODUCT_GROUP_ID execution time: 0 result set fetch time: 0 Followed by... Query SELECT AA_PRODUCT.NAME,AA_PRODUCT.PRODUCT_GROUP_ID FROM AA_PRODUCT WHERE AA_PRODUCT.PRODUCT_ID=1 execution time: 70 result set fetch time: 0 Query SELECT AA_PRODUCT.NAME,AA_PRODUCT.PRODUCT_GROUP_ID FROM AA_PRODUCT WHERE AA_PRODUCT.PRODUCT_ID=2 execution time: 0 result set fetch time: 0 Query SELECT AA_PRODUCT.NAME,AA_PRODUCT.PRODUCT_GROUP_ID FROM AA_PRODUCT WHERE AA_PRODUCT.PRODUCT_ID=3 execution time: 70 result set fetch time: 0 Query SELECT AA_PRODUCT.NAME,AA_PRODUCT.PRODUCT_GROUP_ID FROM AA_PRODUCT WHERE AA_PRODUCT.PRODUCT_ID=4 execution time: 10 result set fetch time: 0 In some instances I would want to load the children (i.e. a ProductGroup detail page) and other cases I wouldn't want to spend time loading the children (i.e. a ProductGroup search results page that didn't display any Product info). So...my first question, is there a way to specify lazy loading of a field at runtime? No, there isn't. Imho, it would be an interesting exercise to add such a feature, but I personally believe that the calling semantics of such a feature would be quite hard to specify. In an effort to optimize, I turned the field lazy attribute value from false to true in the ProductGroup mapping, which resulted in just the first sql query being issued...so far so good. However, after closing the query via a database.close() call, and returning the ProductGroup object to the presentation tier, I got the following exception when trying to access the ProductGroup's Products: java.lang.RuntimeException: Transaction is closed! org.exolab.castor.persist.RelationCollection$IteratorImp.lazyLoad(RelationCollection.java:282) org.exolab.castor.persist.RelationCollection$IteratorImp.next(RelationCollection.java:266) Which leads me to my second question: How are lazy loaded collections properly used in a web app environment? Am I supposed to leave the database object open until the presentation tier is done with the query. Am I supposed to loop through the search results (effectively loading them) before returning them to the presentation tier? Thanks, Jon --- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
Re: [castor-dev] [JDO] - Are explicit object relationships supported in Castor OQL?
No Message Collected
Re: [castor-dev] [JDO] - Are explicit object relationships supported in Castor OQL?
No Message Collected
[castor-dev] 1:many relationships
No Message Collected
[castor-dev] [JDO] - Are explicit object relationships supported in Castor OQL?
No Message Collected
[castor-dev] QueryException: Could not find mapping for class
I managed to battle through the ClassMolder nullpointer exception I was facing few weeks back to get all the config files loaded without problem...so I thought. I'm now getting the following error trying to do a select all on a class that has a mapping present in the database file and the xml file is a valid structure. I noticed another email on this same thread with reference to the example. Is this a regression in 0.9.5.2 or (more likely) another misconfiguration on my part? Nov-02-2003 7:28:30:459 PM, PST [ERROR] (apex.common.SystemException:?) -- Failed to execute query executeFind: ooqlStatement='SELECT object FROM com.apex.chronos.app.domains.GeneratedBillingType object' bindValues=[] org.exolab.castor.jdo.QueryException: Could not find mapping for class com.apex.chronos.app.domains.GeneratedBillingType at org.exolab.castor.jdo.oql.ParseTreeWalker.checkFromPart(ParseTreeWalker.java:305) at org.exolab.castor.jdo.oql.ParseTreeWalker.checkErrors(ParseTreeWalker.java:222) at org.exolab.castor.jdo.oql.ParseTreeWalker.init(ParseTreeWalker.java:137) at org.exolab.castor.jdo.engine.OQLQueryImpl.create(OQLQueryImpl.java:278) at org.exolab.castor.jdo.engine.DatabaseImpl.getOQLQuery(DatabaseImpl.java:467) !DOCTYPE database PUBLIC -//EXOLAB/Castor JDO Configuration DTD Version 1.0//EN http://castor.exolab.org/jdo-conf.dtd; database name=chronos engine=oracle jndi name=java:comp/env/jdbc/ChronosPool/ mapping href=./GeneratedAddressMapping.xml/ mapping href=./GeneratedBillingTypeMapping.xml/ !-- rest of mappings excluded for brevity -- /database p.s. IMHO...a warning should be logged in ClassMolder after the following line if the relatedType doesn't exist. This was the problem with my mapping which led to a null pointer trying to compare the number of many fields mapped in the current file with those in the source object (second line of code below). //NEEDS WARNING IF relDesc is null ClassDescriptor relDesc = loader.getDescriptor( ds.resolve( relatedType ) ); //Causes null pointer without helpful logging if //relDesc above was null if ( manyName.length != relatedIdSQL.length ) --- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
Re: [castor-dev] ClassMolder NullPointerException
Awesome! Is this targeted for a particular release? Is there anyway for me to track this? --- Bruce Snyder [EMAIL PROTECTED] wrote: This one time, at band camp, Jon Wilmoth said: JWThanks! I'll go through the mapping files with that JWin mind. JW JWCan some exception handling and useful root JWcause/recourse logging be added to the mapping JWclasses? Class being mapped, field, mapping error JWwould be nice. I'm in the process of changing from using Exolab logging over to using the Jakarta Commons Logging framework with Log4J as the default logger. In time, I plan to add this sort of debug level logging. Thanks for the suggestion. Bruce -- perl -e 'print unpack(u30,0G)[EMAIL PROTECTED]5R\F9EG)E=\$\!FFEI+F-O;0\`\`);' The Castor Project http://www.castor.org/ Apache Geronimo http://incubator.apache.org/projects/geronimo.html --- 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
[castor-dev] Long Transaction Dependant Objects..still
I searched the mail archives and found a couple of people had posted problems with persisting JDO relationships. Since I didn't see any answers, and I'm having the same problem others have had I thought I'd post this again in hopes of an answer from exolab or a work around from someone who has face this problem before. Although I have a number of relationships, I've included the log/stack trace for a *simple* one. I've registered a log4j callbackinterceptor to log all messages in the CallbackInterceptor interface. A TimeEntry has a Comment both extend generated classes which in turn extend a single superclass (AbstractBusinessObject). Thoughts? Please! May-30-2002 11:30:08:634 PM, PDT [DEBUG] (GeneratedTimeEntry:) -- Searching for GeneratedTimeEntry :-20 May-30-2002 11:30:08:634 PM, PDT [INFO ] (GeneratedTimeEntry:) -- query SELECT object FROM GeneratedTimeEntry object WHERE id = $1 May-30-2002 11:30:08:764 PM, PDT [INFO ] (Log4jCallbackInterceptor:) -- JDO using: object 'GeneratedComment: id=-20 linkId=-20 text=Test time Entry date=2002-05-05 commenterPersonId=-1' has been made persistent using Database 'org.exolab.castor.jdo.engine.DatabaseImpl@5ab859:chronos' May-30-2002 11:30:08:764 PM, PDT [INFO ] (Log4jCallbackInterceptor:) -- JDO loaded: 'GeneratedComment: id=-20 linkId=-20 text=Test time Entry date=2002-05-05 commenterPersonId=-1' has been loaded from persistent storage with accessMode '1' May-30-2002 11:30:08:764 PM, PDT [INFO ] (Log4jCallbackInterceptor:) -- JDO using: object 'GeneratedTimeEntry: id=-20 timesheetId=-1 projectId=-1 personId=-1 startDate=Sat May 25 14:00:00 PDT 2002 endDate=Sat May 25 16:00:00 PDT 2002 linkId=-20 billingTypeId=1 durationInMinutes=null description=GeneratedComment: id=-20 linkId=-20 text=Test time Entry date=2002-05-05 commenterPersonId=-1' has been made persistent using Database 'org.exolab.castor.jdo.engine.DatabaseImpl@5ab859:chronos' May-30-2002 11:30:08:764 PM, PDT [INFO ] (Log4jCallbackInterceptor:) -- JDO loaded: 'GeneratedTimeEntry: id=-20 timesheetId=-1 projectId=-1 personId=-1 startDate=Sat May 25 14:00:00 PDT 2002 endDate=Sat May 25 16:00:00 PDT 2002 linkId=-20 billingTypeId=1 durationInMinutes=null description=GeneratedComment: id=-20 linkId=-20 text=Test time Entry date=2002-05-05 commenterPersonId=-1' has been loaded from persistent storage with accessMode '1' May-30-2002 11:30:08:764 PM, PDT [INFO ] (com.apex.tools.castor.Log4jCallbackInterceptor:) -- JDO storing: object 'GeneratedTimeEntry: id=-20 timesheetId=-1 projectId=-1 personId=-1 startDate=Sat May 25 14:00:00 PDT 2002 endDate=Sat May 25 16:00:00 PDT 2002 linkId=-20 billingTypeId=1 durationInMinutes=null description=GeneratedComment: id=-20 linkId=-20 text=Test time Entry date=2002-05-05 commenterPersonId=-1' is to be stored in persistent storage (modified 'false') May-30-2002 11:30:08:764 PM, PDT [INFO ] (Log4jCallbackInterceptor:) -- JDO storing: object 'GeneratedComment: id=-20 linkId=-20 text=Test time Entry date=2002-05-05 commenterPersonId=-1' is to be stored in persistent storage (modified 'false') May-30-2002 11:30:08:764 PM, PDT [INFO ] (Log4jCallbackInterceptor:) -- JDO releasing: object 'GeneratedTimeEntry: id=-20 timesheetId=-1 projectId=-1 personId=-1 startDate=Sat May 25 14:00:00 PDT 2002 endDate=Sat May 25 16:00:00 PDT 2002 linkId=-20 billingTypeId=1 durationInMinutes=null description=GeneratedComment: id=-20 linkId=-20 text=Test time Entry date=2002-05-05 commenterPersonId=-1' has been made transient (committed 'true') May-30-2002 11:30:08:774 PM, PDT [INFO ] (Log4jCallbackInterceptor:) -- JDO releasing: object 'GeneratedComment: id=-20 linkId=-20 text=Test time Entry date=2002-05-05 commenterPersonId=-1' has been made transient (committed 'true') May-30-2002 11:30:08:794 PM, PDT [DEBUG] (GeneratedComment:) -- Searching for GeneratedComment :-20 May-30-2002 11:30:08:794 PM, PDT [INFO ] (GeneratedComment:) -- query SELECT object FROM GeneratedComment object WHERE id = $1 May-30-2002 11:30:08:834 PM, PDT [INFO ] (Log4jCallbackInterceptor:) -- JDO using: object 'GeneratedComment: id=-20 linkId=-20 text=Test time Entry date=2002-05-05 commenterPersonId=-1' has been made persistent using Database 'org.exolab.castor.jdo.engine.DatabaseImpl@33278a:chronos' May-30-2002 11:30:08:834 PM, PDT [INFO ] (Log4jCallbackInterceptor:) -- JDO loaded: 'GeneratedComment: id=-20 linkId=-20 text=Test time Entry date=2002-05-05 commenterPersonId=-1' has been loaded from persistent storage with accessMode '1' May-30-2002 11:30:08:834 PM, PDT [INFO ] (Log4jCallbackInterceptor:) -- JDO storing: object 'GeneratedComment: id=-20 linkId=-20 text=Test time Entry date=2002-05-05 commenterPersonId=-1' is to be stored in persistent storage (modified 'false') May-30-2002 11:30:08:834 PM, PDT [INFO ] (Log4jCallbackInterceptor:) -- JDO releasing: object 'GeneratedComment: id=-20 linkId=-20 text=Test time Entry date=2002-05-05 commenterPersonId=-1' has been made transient (committed 'true') May-30-2002
