On Mar 21, 2013, at 12:35 AM, Konstantin Kolinko wrote: > Hi! > > Recent Mark's commits in Tomcat 7, 8 replaced custom > implementations(*) of base64 > with use of the following class from JAXB: > > javax.xml.bind.DatatypeConverter > > This affects base64 processing in our own classes and in our copy of > Commons FileUpload. > The original fileupload library in commons was not changed (I do not > see [1] change in [2] @1459121). > > [1] http://svn.apache.org/r1458726 > [2] > http://svn.apache.org/viewvc/commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/util/mime/Base64Decoder.java?view=markup > > First, it seems wrong, as this JAXB API was not designed as a general > purpose base64 codec. > > I hereby -1 on this change, on the following ground: > > 1. JAXB Javadoc say [3] that a proper way to initialize > DatatypeConverter is to call JAXBContext.newInstance) which allows > provider to initialize this class. > Looking at JDK 7u17, if Tomcat directly calls the > parseBase64Binary(..) etc, APIs, the class silently initializes itself > with default implementation, which prevents its proper initialization > later via setDatatypeConverter(..) whenever someone later calls proper > JAXB APIs. > > [3] > http://docs.oracle.com/javase/7/docs/api/javax/xml/bind/DatatypeConverter.html > > [quote] from [3] > JAXB Providers are required to call the setDatatypeConverter api at > some point before the first marshal or unmarshal operation (perhaps > during the call to JAXBContext.newInstance). This step is necessary to > configure the converter that should be used to perform the print and > parse functionality. > [/quote] > > > BTW, here is some discussion. It mentions that there exist some effort > to introduce general purpose base64 support in JDK, "JEP 135". > http://stackoverflow.com/questions/469695/decode-base64-data-in-java > > Best regards, > Konstantin Kolinko
I'm going to +1 Konstantin's -1, which I suppose just means another (non-binding) -1 to the change. To add to K's quote: [quote]The javaType binding declaration can be used to customize the binding of an XML schema datatype to a Java datatype.[/quote] I think it's pretty clear that DatatypeConverter is not supposed to be used in the manner we are using it, and doing so could have negative consequences for web applications that are using JAXB. To add some more information to all of this, I believe I have seen more implementations of Base64 encoding/decoding in Java in my lifetime than I have computer languages. There's Commons FileUpload, Commons Codec, Spring Security, DatatypeConverter, and FOUR internal Sun classes that accomplish Base64 encoding/decoding in some form, just to name a few. (In an application I work on at $work, the original developer actually implemented his own.) Nobody seems to really like or want to depend on anyone else's implementation, and it's high time the JDK included an official Base64 encoder/decoder. Now it does. K mentioned JEP 135 but didn't link to it [1]. I can confirm and have personally compiled and tested that this is implemented in and working in Java 8 (java.util.Base64 [2]), though we'll have to wait for Tomcat 9 to take advantage of it (unless someone will join me in +1-ing using Java 8 for Tomcat 8 =D ;-)). For now, I'm going to have to agree with K and say we need to put it back the way it was. [1] http://openjdk.java.net/jeps/135 [2] http://download.java.net/jdk8/docs/api/java/util/Base64.html --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
