Steve,
Did you regenerate your classes + descriptors and recompile both after
making the changes to the properties file?
What does your binding file look like? The binding file takes a higher
precendence than what's in the properties file, so sometimes a
configuration setting in the binding file may be conflicting with that
in the properties file. A good example of this is when using "type" vs
"element" centric binding methods.
Are you using a byte-code modifier like cglib that could possibly be
injecting code into your classes before the marshalling takes place? If
so Castor will have trouble matching the modified class with that
specified in the binding file since the classes won't be equal as
they're loaded with two different class loaders.
If none of the above helps then I don't think I'm going to be able to
guess as to what the problem might be without looking at it first hand.
If you can send me a test case which demonstrates the issue I'll be
happy to take a look at it here.
--Keith
Stephen Winnall wrote:
I've solved the problem of the exception being thrown by setMapping ().
As the discerning
reader will have noticed, I forgot to pass a classloader (e.g.
getClass().getClassLoader())
to the Mapping constructor. 1 down, 2 to go. Maybe marketing isn't for
me after all...
Steve
On 23 Aug 2005, at 16:47, Stephen Winnall wrote:
Keith
Thanks for the feedback.
It sounds like the generated classes have the JDO friendly getters
which return an actual reference to the internal collections instead
of a copy. Which would explain why "AsReference" appears in the
getter names of the generated sources.
I switched off the JDO-friendly getters with
org.exolab.castor.builder.extraCollectionMethods=false
and still get the "AsReference" suffix on the marshalled elements.
There are NO
getters generated with this suffix, even with the above set to "true".
Though I'm not sure why the "AsReference" methods would be showing
up in the XML, it sounds like Castor was not able to find the proper
***Descriptor.class. Make sure you compiled all the descriptor
classes, also you may need to define a mapping file for your
MyOwnStuff class which simply declares that it extends the Mzzz
class so that Castor doesn't try to re-introspect the class.
I'm pretty sure that all the descriptor files have been compiled.
They're in a folder
together with the other SourceGen generated files which I wipe out en
bloc before
generating new sets of files. Eclipse compiles them automatically. Of
course,
MyOwnStuff doesn't have a descriptor file...
I have tried to set up a mapping file. However, I get the following
error from
setMapping:
org.exolab.castor.mapping.MappingException: Nested error:
org.exolab.castor.mapping.MappingException: Could not find the class
a.b.c.d.MyOwnStuff
My mapping file contains entries like the following:
<class name="a.b.c.d.MyOwnStuff"
extends="a.b.c.d.xml.Mzzz"> </class>
<class name="a.b.c.d.xml.Mzzz"> </class>
I have a sneaking suspicion that this may be because MyOwnStuff is in
a different folder
from the SourceGen generated files (a.b.c.d.xml.*), but I'm not sure.
I use the following code in class a.b.c.d.WriteModel to set up the
mapping:
Mapping mapping = new Mapping();
mapping.loadMapping(getClass().getResource("model-
mapping.xml"));
...
marshaller.setMapping(mapping);
where "model-mapping.xml" is also in a.b.c.d.
If you are using 0.9.7 you can put this mapping in a ".castor.xml"
file so that castor will automatically load the mapping without
needing to specify it.
I am indeed using 0.9.7. I didn't know about ".castor.xml", so I
looked in the source to try
to work out how to use it. I could only find the following
declaration in SourceGenerator.java:
private static final String MAPPING_FILE = ".castor.xml";
but it doesn't seem to be referenced anywhere, so I'm none the wiser.
This whole thing is something of a show-stopper for me, so I'd be
greatful for any
assitance anyone could offer. In the meantime I'm contemplating
whether to retrain
for a career in marketing.
Cheers
Steve
Stephen Winnall wrote:
I have generated (in simplified terms) the following structure
with SourceGen:
public abstract class MAbstractRoot {} // written by me
public class MBaseType extends MAbstractRoot {} //
generated by SourceGen, "extends" defined in binding file
public class Mxxx extends MBaseType {} // generated by SoureGen
....
// generated by SourceGen
public class Mzzz extends Myyy {} // generated by
SourceGen
public class MyOwnStuff extends Mzzz {} // written by me
When I marshal an object from the class MyOwnStuff, all of the
fields generated are
duplicated and are identical, except for the fact one of the pairs
has the suffix
"AsReference" on the element name.
I have only been able to find references to the "AsReference"
suffix in conjunction with
getters and setters. Could someone please point me at an
explanation of what is happening
here and how to control (OK - prevent) it?
Regards
Steve
-------------------------------------------------
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]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, pleasesend 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]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
