Amit M Bhosle wrote:
> very simplistic use case -- made up for testing castor for the
> intended use case..
>
> public abstract class A {
> private int a;
> public int getA() { return a; }
> public void setA(int a) { this.a = a; }
> public String toString() {
> return "a[" + a + "]";
> }
> }
>
> public class B extends A {
> private int b;
> public int getB() { return b; }
> public void setB(int b) { this.b = b; }
> public String toString() {
> return super.toString() + "b[" + b + "]";
> }
> }
>
> public class C extends A {
> private int c;
> public int getC() { return c; }
> public void setC(int c) { this.c = c; }
> public String toString() {
> return super.toString() + "c[" + c + "]";
> }
> }
>
>
> would be a really HUGE help if you could tell me the structure for the
> mapping file i'll need.. what all i'll need to define, etc.. also, for
> this discussion let's assume that the java code deals with only class
> A (and not the concrete subclasses)..
That's what I assumed anyhow. Let me have a look at this later on today.
> i need help only with the auto-naming approach (not the one where the
> mapping file will need to contain info about all concrete classes)..
> it would be awesome if the mapping file doesn't contain info about the
> concrete classes - i'm not sure that would be possible..
I am afraid that this won't be an option, as you state yourself that
you'd like to use the deriveByName feature rather than having xsi:type
attributes being injected into your XML.
>
> thanks a ton..
> regards,
> Amit
>
>
> On 4/20/07, Werner Guttmann <[EMAIL PROTECTED]> wrote:
>> 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
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
