On 14 Jul 2004, at 08:44, Henning Schmiedehausen wrote:
On Wed, 2004-07-14 at 00:09, robert burrell donkin wrote:On 13 Jul 2004, at 16:51, Henning P. Schmiedehausen wrote:
<snip>
XMLIntrospectorHelper is very limiting and will hopefully be completely
deprecated sometime soon. the primitives concept needs to be extended
into the more flexible concept of simple type. (the simple type concept
is more often used in the xml-object binding community.) the refactored
code with improved design has been merged into HEAD now and some of
these changes in this direction have been made (but i've lost track a
bit since i'm currently juggling a number of releases at the moment).
just FYI the plan is to cut a 1.6 based on the improved design very
soon.
This sounds nice. I felt that the XMLIntrospectionHelper is not flexible
enough to fit to all needs. Getting it pluggable through a strategy
object would help here.
+1
i took a look into the current state of the code. i've deprecated the isPrimitive method and replaced with a strategy (but more work's need since it needs to support simple types and attributes as well).
just have isLoop to go before XMLIntrospectorHelper can be deprecated...
In the end I came up with the attached patch, which works fine for me (it might not be ideal, because the resulting XML contains the raw sew^Wbinary data if you write the bean out.
i'm not sure i parse this correctly. (it's a little late, so it might be me.) care to expand?
It's simple. With this patch, when you introspect a bean that contains
a byte [] array, you might end up with <foo bytes="random noise right
from the bean"> without any escaping or CDATA encapsulation. Most of the
times, this is not what the developer wants (and it might not be valid
XML).
that's what i thought you meant :)
probably the best way to fix this would be to use a CDATA strategy for the mixed text. should be compatible with the custom object string converter.
In my application I have a custom converter which does
import org.apache.commons.codec.binary.Base64;
public class CustomConverter
extends DefaultObjectStringConverter
{
public String objectToString(Object object, Class type, String flavour, Context context)
{
if (object instanceof byte[]) {
return new String(Base64.encodeBase64Chunked(object), "ISO-8859-1");
} else {
return super.objectToString(object, type, flavour, context);
}
}
public Object stringToObject(String value, Class type, String flavour, Context context)
{
if (type.equals(byte [].class)) {
return Base64.decodeBase64(value.getBytes("ISO-8859-1"));
} else {
return super.stringToObject(value, type, flavour, context);
}
}
}
So I get my byte arrays converted into base64 Strings.
[...]
cool
Anyway, here is the patch, discussions welcome. ;-) This is against CVS HEAD. I would volunteer to write an Unit test for it if has a chance to get applied.
there is every chance that a fix for this would get committed with a unit test :)
i have an idea that the patch is against the 0.5 code base (but i could
be wrong since i haven't looked into this in detail). please set my
suspicious mind at rest by updating before you start getting into this.
Well, it is against CVS HEAD, which identifies itself as 0.6-dev in the project.xml. Is there another version?
nope, that's it :)
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
