Sorry, cannot contribute much thoughts here, XML Serialization is very much not my neck of the woods. I only think that the generated layer of getters/setters is quite useful as it allows people to work around missing features in POI, the spec is huge and so having the low-level API is a big plus in my point of view.
On changing XML-serialization, I'd probably first build some nightly performance benchmarking support so we get a good baseline of various things before starting on such bigger changes. I lately read up on how Lucene and Elasticsearch are doing it and it looked quite useful. Mostly run the exact same set of tests each day on the same hardware and record it's runtime and other parameters, e.g. memory usage, ... See e.g. http://home.apache.org/~mikemccand/lucenebench/ and https://benchmarks.elastic.co/index.html Dominik On Thu, Apr 21, 2016 at 2:11 AM, Jason Harrop <jhar...@gmail.com> wrote: > JAXB for XML signing. Been there, done that ;-) > > Yes, it is a PITA, especially to support both the reference and MOXy > implementations, but it is do-able. (Docx4j 3.3.0 Enterprise features > this, and uses some POI code to do it, for which I am grateful) > > If POI does decide to adopt JAXB, then it would make sense to explore > merging the POI and docx4j projects. There doesn't seem to be much point > having these as alternatives from a dev or user perspective if they both > sit on top of JAXB? > > cheers .. Jason > > > > > On Thu, Apr 21, 2016 at 9:45 AM, Andreas Beeker <kiwiwi...@apache.org> > wrote: > > > 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 > > > > >
