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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
