Hi *, I'm still struggling with the jaxb replacement for the xml signing classes. Apart of spending a lot of time to get namespaces/prefix right (... and it still doesn't work), so that the signatures are valid again, I've realized that jaxb in java6 might be also a problem ...
The reason for changing the implementation is of course testing jaxb in a not so important area of POI, but is jaxb really a good pick? random thoughts: - we get more and more android requests, where jaxb is not supported or only made possible by custom hacks [1] ... should we try to make POI compatible to Android? - specific to the signing, the xmlsec lib also use jaxb itself - if I try to omit jaxb for the sake of android compatibility, I'd likely need to reimplement the relevant parts of xmlsec [2] - having a xml serializer independent of the java version could be handy ... but security issues (e.g. XXE) shouldn't be overlooked - although there are other serializer (e.g. SimpleXml [3]) - we still need to keep the xml-infoset (or unknown native records) ... do we? would there be a way to have a common / format independent model albeit preserving unknown records / xml-data? I think about the performance discussion lately, where we could handle more data when we transform the data to an internal model ... but probably ignore unknown elements. (This applies of course to non-streaming mode ...) Just give me your 2 cents, so I see, if it's worth to get my stuff working ... Andi [1] http://stackoverflow.com/questions/9734921/is-there-a-need-in-jaxb-implementation-for-android http://www.docx4java.org/blog/2012/05/jaxb-can-be-made-to-run-on-android/ [2] http://stackoverflow.com/questions/5991290/xml-soap-signing-on-android [3] http://simple.sourceforge.net/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
