Hi,
I've tried some ways how to force writing (marshalling) a value.
Under some circumstances we need to force the writing of an optional value,
even if this value is the Java initial value, i.e. '0' for an int.
1.
Adding an test method returning always true:
<value name="statusCode" field="statusCode" usage="optional"
test-method="myTest"/>
Result: the test method is called (I've supervised this with an additional log
statement.)
but the XML document still not contains the element.
2.
Adding the test method and using an default value out of business scope:
<value name="statusCode" field="statusCode" usage="optional"
test-method="myTest" default="-99999"/>
Result: the test method is called, the XML document now contains the element
(with value 0)
but unmarshalling an document without element returns the default.
Now marshalling/unmarshalling works.
So I have a business problem, as the default is now the -9999 which does not
match our business specification.
3.
Extending test 2. by providing extra serialization and deserialization method
to map the XML default value -99999 to our business value 0:
<value name="statusCode" field="statusCode" usage="optional"
test-method="myTest" default="-99999"
serializer="com.macd.trend.message.xml.Conversion.printInt"
deserializer="com.macd.trend.message.xml.Conversion.parseInt"/>
public static String printInt( int value ) { return
Integer.toString( value ); }
public static int parseInt( String value ) {
if ( null == value ) { return 0; }
int myValue = Integer.parseInt( value );
if ( -99999 == myValue ) {
return 0;
} else {
return myValue;
}
}
Result: unmarshalling works fine, even on supplying <statusCode>0<statusCode/>
as well as omitting the XML element. My log says that the deserializer
method is called as expected. So the problem of case 2 above is solved.
But, marshalling fails: The java field has value 0, the test method is called
returning true. The serializer method is not called. It seems that the JLS
default value 0 makes the marshalling step skipping to write the XML element.
This is somewhat unexpected as explicitly a default value was given.
4.
My work around up to now is to use two separate bindings.
The binding used for marshalling forces writing the value with
usage="required" and the binding used for unmarshalling still has
usage="optional". Of course, this work around works without any problem other
than doubling the whole binding definition.
My conclusion and wishlist:
a)
Checking for defaults is done multiple times with different values:
using the explicitly defined default in the binding definition
and initial value defined in JLS.
For me, this is somewhat unexpected and may be an error?
My expectation was that if the explicit default was specified, then only
this value would be checked for and not the JLS initial value as well.
b)
The test method only provides a way to skip marshalling a value (if it returns
false)
but not to force marshalling a value (if it returns true).
My expectation includes also the case to force marshalling a value.
c)
Basing the marshalling algorith on the initial value defined in JLS is
somewhat questionable: of course it works very well when playing in the Java
world but when interfacing with the non-Java world the JLS should not force
any assumptions which need to be regarded elsewhere.
My expectation is to ignore the initial value. Using a test method seems to be
adequate if an element should be suppressed on marshalling otherwise it
shouldn't be always marshalled.
d)
Still open is the influence of the default value when marshalling.
I like following expectation: don't use any default for a primitive value as
this is always a legal value so no default is required. This may be an issue
on non-primitive values like on String objects.
Here, a null value isn't a legal value, so a priori no XML document can be
printed.
So, for me it might be "correct" if the element is skipped and the default is
a don't care on marshalling.
(When any ouput is still required an appropriate serializer method and/or get
method can be used, surely?)
e)
Returning to a question from Dennis:
I think improvements on marshalling can be done without extra input and output
sections
if they will differ as discussed here.
f)
Some issues besides this:
1)
I would to get Java source code generated by the binding compiler.
So regular dependency checking for make/ant will approriate recognize
the changes either in Java classes or the XML binding specification.
2)
I would to get the output of the binding compiler placed in another package
than the Java classes. For me, the Java classes are the very basic part of my
application but the binding is part of one interface. So the facilitating the
separation of the binding from the classes will improve maintaining my
sources a lot!
3)
It would be good, if more methods can be called from other classes.
E.g. the serialize and deserialize methods are called not neccessarily from
the class which has the field. But the the test method is still a member
method. This approach is still fine for some methods when they follow a
general design idea of the class (e.g. myClass.hasVeryComplexStructure).
If the test method is "only" used to control the marshalling and not of other
business interest, it would be good if it can be placed in an extra class
beeing in my favorite XML package.
Please don't get the impression that I'm complaining in this detailed mail,
I really like the direct way how JiBX binds Java and XML.
Many thanks,
Reiner Nix
>on marshalling an integer variable 'statusCode' with value 0 the written
> XML document does not contain a line '<statusCode>0</statusCode>'.
>Instead this the line is completely omitted.
>The same is on boolean value 'false' and string value 'null'.
>
>My question: how can I still force writing those value elements?
>
>
>Below a snippet of the binding definition.
>
> <mapping name="XmlApplicationMessage" class="ApplicationMessage">
> <value name="statusCode" field="statusCode" usage="optional"/>
> </mapping>
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
jibx-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jibx-users
