Dennis,
Thanks for that, I have a better appreciation of the issues now.
In the example I gave below I created some objects in code then marshalled to
see the results. For on object of class A I got
<data><a>24</a></data>
and for class B I got
<data><data><a>24</a></data></data>
although this is not what I was looking for (the nested 'data'), it does make
sense.
In the end instead of using inheritance I included A as a member in B. Without
the inheritance the binding was fine. In fact, using inheritance rather than
inclusion was not really any better from an architectural point of view, even
without the binding issues.
By the way, JiBX is a truly excellent tool. I have previously looked at JAXB
and Castor, but to my mind they fall somewhat short of JiBX.
Paul
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Sosnoski
Sent: Sunday, 18 December 2005 6:46 AM
To: [email protected]
Subject: Re: [jibx-users] Handling inheritance
Hi Paul,
The problem with your binding lies, as you suspected, in trying to use
the same name for both the base class and the subclass. This is a case I
should probably check, since there's no way to handle it for unmarshalling.
The class you pass to the getFactory() method doesn't matter, because
that's only used to find the binding information, and if both these
definitions are in the same binding there's no way to control which one
would actually be used for unmarshalling.
That said, the case you're actually interested in - where a bound class
has subclasses, and you want to handle the subclasses using the base
class binding - should work fine for marshalling. For unmarshalling the
situation is a little trickier, since there's in general no way for JiBX
to know that you actually want to use a subclass rather than the base
class. If you use a factory-method you can control the actual subclass
created for an unmarshalled object, so that's one way to handle this
side of things. Another is for the constructor of the containing object
to just create an instance of the appropriate subclass (or do the same
thing with a preset-method), assuming the containing object knows which
variation of your subclassed type is appropriate - JiBX will use an
already-created object instance for unmarshalling, in preference to
creating a new instance.
- Dennis
Chisholm, Paul wrote:
>Hi,
>
>I have an issue with binding and class inheritance. Take the classes
>
>public class A
>{
> private int a;
>}
>
>public class B extends A
>{
> int b;
>}
>
>and the binding file
>
><binding>
> <mapping name="data" class="A">
> <value name="a" field="a"/>
> </mapping>
> <mapping name="data" class="B" extends="A">
> <structure map-as="A"/>
> </mapping>
></binding>
>
>- The mapping for A isn't abstract because I need to create concrete
>instances of both A and B.
>- Class B adds data when extending A but this data does not play any
>part in marshalling/unmarshalling.
>- The top level element for both A and B is 'data'.
>
>Now I unmarshal the XML
>
><?xml version=\"1.0\" encoding=\"UTF-8\"?><data><a>24</a></data>
>
>when I pass A.class to the getFactory method in preparation for
>unmarshalling, all works as expected. When I pass B.class to the
>getFactory method in preparation for unmarshalling, the unmarshalling
>method returns an object of class A (not class B).
>
>This does not seem correct. I'm not sure if giving two mappings the same
>name is allowed. In the real situation I derived this example from I
>need to use the same top level element. Anyone have any idea what is
>going on, or what I am doing wrong?
>
>The above was my attempt to get round a limitation with inheritance.
>Namely, if class B extends class A, and I have a defined binding for
>class A, then I want to be able to marshal/unmarshal objects of class B
>implicitly. That is, when I marshal B the run-time would look at class
>B, see it doesn't have any binding information, but notice superclass A
>does so just use A. I am not familiar with the inner workings of JiBX so
>that may be a big ask. Is it a feasible extension?
>
>Thanks,
>Paul
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems? Stop! Download the new AJAX search engine that makes
>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_idv37&alloc_id865&opÌk
>_______________________________________________
>jibx-users mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/jibx-users
>
>
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=ick
_______________________________________________
jibx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-users
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
jibx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-users
