Yes, I think I have understood your use case ... well, sufficiently. Why not post one or two classes (as simple as possible), a (minimal) mapping file .. and we have a look at this in common.
Other than that, please see inline again. Werner Amit M Bhosle wrote: > thanks for the prompt response.. i'm assuming that u've understood my > use case.. > > >> > 1. can castor help me with this marshalling/unmarshalling without >> > having to use a mapping-file. >> Before trying to answer this, I'd like to understand as to why you do >> *not* want to use a mapping file. Basically, all advanced features are >> exposed through mainly the mapping file. > > > mainly because the requirement is quite trivial.. given an object - > marshall it (preferably into a human-readable fashion - as opposed to > what java serialization provides).. transfer it, and unmarshall at > other end of the wire.. i've done such things using XStream in the > past, but am looking for similar functionality using castor.. Castor provides identical functionality, if not more. > another reason is that i have a whole bunch of subclasses, for which > i'll need to define the mappings.. it's probably a one-time thing and > i'd want to keep that as the last resort.. Yes, it would be an effort, but as you said yourself, it's an one-off thingy. > > >> >> > from what i read about castor, i need >> > to specify the exact subclass for unmarshalling.. and in my case, i >> > don't know the exact subclass at the time of unmarshalling.. >> That's definitely not correct. Castor definitely does support >> polymorphism. Basically, as defined in the XML standrad itself, Castor >> knows how to make use of the xsi:type attribute to express subtype >> relationships. >> > > here, i was talking about using castor *without* the mapping file.. > the tutorials/code-samples that i looked at always needed the concrete > class to be passed as the first parameter to Unmarshaller.unmarshal > method.. Not if you are using a mapping file, as Castor will be intelligent enough to figure the type of the root element to be unmarhalled, given it has been given enough hints. A Class instance is one way of provising such a hint, a mapping file another. > i read through the xsi:type doc at > http://www.castor.org/xml-mapping.html#5.-xsi:type .. but it seems > that it wouldn't be able to support my use case.. as opposed to the > example shown, my "top-level" class the be marshalled should be > determined using the "deriveByClass" approach.. but i've not been able > to write the mapping file this way.. That should be easy with a little help .. ;-) > > >> > 2. can castor help me with a mapping-file? i understand that one >> > solution is to write a mapping file defining the mappings for all >> > concrete classes.. but i was looking at avoiding that.. the >> > auto-naming doesn't seem to work for top-level abstract classes.. >> Inheritance without a mapping file will almost be impossible without a >> mapping file. You are going to need some construct to express the fact >> that a class A is a child of another class. >> > > > i didn't quite follow this.. but at the time of unmarshalling, why > should castor need to know what the super class is? as long as all > classes are "bean-like", shouldn't java reflection be able to help > with whatever is required..? > e.g. > abstract class B: > int b; // with accessors > > class A extends B: > int a; // with accessors.. > > when A is serialized, the serialized version can store the classname, > and all fields (as defined in A and B).. for deserialization, create > A, and set all fields using setter's.. i shouldn't need to know that > some of the getters/setter are inherited.. In theory, yes. But if you are using just the introspector, you won't be able to e.g. derive by name feature, as Castor will not hold enough information at run-time. > > regards, > Amit > > > > > > > > > >> > thanks in advance.. >> > regards, >> > Amit >> > >> > --------------------------------------------------------------------- >> > To unsubscribe from this list please visit: >> > >> > http://xircles.codehaus.org/manage_email >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
