We aren't actually generating anything from our Castor setup yet. Right now we are only trying to get Castor to load pre-existing database rows. So the key generation "shouldn't" be an issue, but thanks for the heads-up; I'll definitely keep a close eye on that when we start trying to persist.
Another strange thing I just noticed: I have been using the jar marked as castor.0.9.3.jar I just tried to replace that with castor.0.9.3.9.jar to see if it would correct any of these issues. However, the new jar complains about these collection joins saying it cannot find the appropriate set/add methods. I was using collection="collection" in the mapping for these joins, and then coding the object's get/set attribute as java.util.List. It seems like that is what the new jar does not like. Attached are the three classes directly invloved; please let me know if you need to see others. Also, I am using interfaces in front of the classes for the UI to use. These aren't attached. Let me know if it would be beneficial to have them also. ******************************************** Steve Ebersole IT Integration Engineer Vignette Corporation 512.741.4195 Visit http://www.vignette.com ******************************************** -----Original Message----- From: Bruce Snyder [mailto:[EMAIL PROTECTED]] Sent: Saturday, March 02, 2002 11:59 AM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Date: Fri, 1 Mar 2002 18:54:41 -0600 This one time, at band camp, Ebersole, Steven said: ES>I have done some further research into this issue and have found the ES>following : ES>1) By placing print statements in the Company's addEmployee() method, I have ES>verified that Castor is really calling addEmployee with employees whose ES>company attribute does not match the company upon which the method is being ES>called. An example is "Adding companyPerson [id=2101, emp.comp.id=1] for ES>this company [id=6]" ES> ES>2) Removing the add methods and allowing access to only set methods had ES>interesting results. Castor called setEmployees, for example, 3 times for ES>each company, one time with the correct number "sandwiched" between two ES>calls with the incorrect counts. Steve, This sounds like some very odd behavior. Can we see some of your objects to see the implementation of the setters as well as a other objects using these setters? The reason I asked if you were using a key generator is because people have reported some problems with them and I'm just curious to know if you get the same results in a test without the key generators. Bruce -- perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");' ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
CompanyImpl.java
Description: Binary data
CompanyPersonImpl.java
Description: Binary data
LocationImpl.java
Description: Binary data
