Remi, The simplest solution is to add get/setBVector methods to A, then reference these as the get-method and set-method in the mapping file. If you are going to be generating a lot of code, you can extend CollectionInfo to automatically do this.
Hope this helps... Margaret -----Original Message----- From: Remi Catherinot [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 12, 2002 1:10 PM To: [EMAIL PROTECTED] Subject: [castor-dev] mapping to arrays of any type Hi, I've got a 1:n dependency with a master class A that contains lots of slaves (of class B). From A, I can access all the linked B instances through the getB() method which return a B[] object. My problem comes from the mapping file, it seems that jdo does not understand that I'm dealing with a B[] object and not an Object[] one. Attached is my mapping file and also the exception raised by castor. I've read the documentation and seems to me arrays can only be of a few types. What I do not understand is the fact that even though a B[] object can be casted to an Object[] object, castor throws an exception anyway. Is it not supported to have arrays of arbitrary types or am i doing something wrong in my mapping file and/or schema file. Also, since the castor source generator, if not using direct fields, only build get/set methods that deals with arrays, I wonder why the jdo part of castor is not able to deal with such generated code. Plus the fact that if dealing with direct fields the generated code clearly gives access to JDK1.1 or JDK1.2 collection types. schema, mapping and java source code are attached exception ----------------------- Exception in thread "main" org.exolab.castor.mapping.MappingException: The return type for method public B[] A.getB() does not match the declared field type [Ljava.lang.Object; at org.exolab.castor.persist.FieldMolder.findAccessor(FieldMolder.java:778) at org.exolab.castor.persist.FieldMolder.<init>(FieldMolder.java:562) at org.exolab.castor.persist.ClassMolder.<init>(ClassMolder.java:367) at org.exolab.castor.persist.ClassMolder.resolve(ClassMolder.java:519) at org.exolab.castor.persist.LockEngine.<init>(LockEngine.java:168) at org.exolab.castor.persist.PersistenceEngineFactory.createEngine(PersistenceE ngineFactory.java:83) at org.exolab.castor.jdo.engine.DatabaseRegistry.<init>(DatabaseRegistry.java:2 04) at org.exolab.castor.jdo.engine.DatabaseRegistry.<init>(DatabaseRegistry.java:1 63) at org.exolab.castor.jdo.engine.DatabaseRegistry.loadDatabase(DatabaseRegistry. java:289) at org.exolab.castor.jdo.JDO.getDatabase(JDO.java:559) at Test1.getDatabase(Test1.java:16) at Test1.main(Test1.java:20) I've seen in the list that someone proposed a patch to have those get/set methods use Vector and the like but that such a patch will not be moved to castor itself because of sponsor issues so I prefer to not rely on it. I cannot use the workaround of having my field declared has being "direct" because I'm also relying on 2 other API that are not open source and only query objects through get/set methods. Thx in advance. PS: you may recieve this email twice since my email client just crashed :) ----------------------------------------------------------- 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
