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..
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..
> 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..
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..
> 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..
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
--
The heavier between a cigarette and a lighter is the lighter.
Corollary: The lighter between a cigarette and a lighter is not the lighter.
- AB
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
