Hi Joel, Did you get a chance to try to change the final modifier to see if anything else would be needed to complete a port?
Ty Gary On Fri, Jun 13, 2025, 16:18 Joel Griffith <jgrif...@nd.edu.invalid> wrote: > To add to my last post, I ran `crimson.jar` through the migration tool by > itself, calling the output `crimson-jakarta.jar`. > > After replacing `crimson.jar` with it and deploying (to webapps-javaee/ > still), I get the same error as my last message: > ``` > 13-Jun-2025 15:54:34.030 SEVERE [ajp-nio-0.0.0.0-8009-exec-1] > org.apache.tomcat.util.digester.Digester.getParser Error creating SAX > parser > javax.xml.parsers.ParserConfigurationException: Feature: > http://apache.org/xml/features/allow-java-encodings > at > > org.apache.crimson.jaxp.SAXParserFactoryImpl.newSAXParser(SAXParserFactoryImpl.java:119) > at > org.apache.tomcat.util.digester.Digester.getParser(Digester.java:695) > at > org.apache.tomcat.util.digester.Digester.getXMLReader(Digester.java:867) > at > org.apache.tomcat.util.digester.Digester.parse(Digester.java:1539) > ... > ``` > including the `javax.xml.parsers.ParserConfigurationException` part. > > If I examine the migrated JAR, it still uses the 'javax' namespace > internally: > ``` > $ jar -tf crimson-jakarta.jar | grep "javax" > META-INF/services/javax.xml.parsers.DocumentBuilderFactory > META-INF/services/javax.xml.parsers.SAXParserFactory > > $ jar -tf crimson-jakarta.jar | grep "jakarta" > {no output} > ``` > > I might not understand the nature of the migration tools you've suggested. > Are they not intended to perform this conversion, or am I misusing them? > > Joel > > > On Fri, Jun 13, 2025 at 3:10 PM Joel Griffith <jgrif...@nd.edu> wrote: > > > Thanks for that tip, Mark. > > > > I've managed to get the webapp deployed to the webapps-javaee/ directory. > > During operation, the webapp throws an error > > ``` > > 13-Jun-2025 14:28:58.830 SEVERE [ajp-nio-0.0.0.0-8009-exec-1] > > org.apache.tomcat.util.digester.Digester.getParser Error creating SAX > parser > > javax.xml.parsers.ParserConfigurationException: Feature: > > http://apache.org/xml/features/allow-java-encodings > > at > > > org.apache.crimson.jaxp.SAXParserFactoryImpl.newSAXParser(SAXParserFactoryImpl.java:119) > > at > > org.apache.tomcat.util.digester.Digester.getParser(Digester.java:695) > > at > > org.apache.tomcat.util.digester.Digester.getXMLReader(Digester.java:867) > > at > > org.apache.tomcat.util.digester.Digester.parse(Digester.java:1539) > > ... > > ``` > > (full stack trace available on request). > > > > This originates in the package `crimson.jar`, an (admittedly old) XML > > parser that's included in our code. The > > `javax.xml.parsers.ParserConfigurationException` portion of the error > > suggests that it's still recognized as 'javax' instead of 'jakarta'. > > > > Am I doing something wrong? Should this be covered by the migration tool > > as well? > > > > Thanks, > > Joel > > > > > > On Fri, Jun 6, 2025 at 9:48 AM Mark Thomas <ma...@apache.org> wrote: > > > >> Joel, > >> > >> An alternative fix would be for you to use Tomcat Migration Tool for > >> Jakarta EE on commons-fileupload-1.x which will give you the > >> commons-fileupload-1.x API but using the Jakarta EE namespace. > >> > >> Or even more simply, leave the web application exactly as-is and deploy > >> it to webapps-javaee and Tomcat will automatically migrate it from Java > >> EE to Jakarta EE and then deploy it. > >> > >> Mark > >> > >> > >> On 06/06/2025 14:06, Joel Griffith wrote: > >> > I can't say I know why there's a need for a subclass, unfortunately. > >> The > >> > people who wrote this code are long gone, I just have to maintain it. > >> > > >> > Joel > >> > > >> > On Thu, Jun 5, 2025 at 6:25 PM Gary Gregory <garydgreg...@gmail.com> > >> wrote: > >> > > >> >> Hello Joel, > >> >> > >> >> 2.x is not a drop in replacement for 1.x. Why is there a need for a > >> >> subclass? Perhaps there is a feature we can add to 2.x before we > >> finalize > >> >> the API. > >> >> > >> >> Gary > >> >> > >> >> On Thu, Jun 5, 2025, 14:01 Joel Griffith <jgrif...@nd.edu.invalid> > >> wrote: > >> >> > >> >>> I manage a Tomcat/JSP webapp. We are updating our source code to > >> conform > >> >>> to the recent `javax` -> `jakarta` namespace change in the Servlet > >> >> package. > >> >>> > >> >>> The app uses the Apache Commons FileUpload package, which must be > >> >> upgraded > >> >>> from v1 to v2 as part of this change. > >> >>> > >> >>> FileUpload v1 contains a `DiskFileItem` class: > >> >>> ``` > >> >>> org.apache.commons.fileupload.disk.DiskFileItem > >> >>> ``` > >> >>> > >> >>> FileUpload v2 contains the corresponding class > >> >>> ``` > >> >>> org.apache.commons.fileupload2.core.DiskFileItem > >> >>> ``` > >> >>> > >> >>> Our webapp code, written for v1, extends `DiskFileItem`: > >> >>> ``` > >> >>> public class MonitoredDiskFileItem extends DiskFileItem > >> >>> { > >> >>> private MonitoredOutputStream mos = null; > >> >>> private OutputStreamListener listener; > >> >>> > >> >>> public MonitoredDiskFileItem(String fieldName, String > >> contentType, > >> >>> boolean isFormField, String fileName, int sizeThreshold, File > >> repository, > >> >>> OutputStreamListener listener) > >> >>> { > >> >>> super(fieldName, contentType, isFormField, fileName, > >> >> sizeThreshold, > >> >>> repository); > >> >>> this.listener = listener; > >> >>> } > >> >>> > >> >>> public OutputStream getOutputStream() throws IOException > >> >>> { > >> >>> if (mos == null) > >> >>> { > >> >>> mos = new > MonitoredOutputStream(super.getOutputStream(), > >> >>> listener); > >> >>> } > >> >>> return mos; > >> >>> } > >> >>> } > >> >>> ``` > >> >>> > >> >>> This breaks with the update to v2 with `error: cannot inherit from > >> final > >> >>> DiskFileItem` because the `DiskFileItem` class was changed to > `final` > >> >>> across versions. > >> >>> > >> >>> The migration guide at > >> >>> https://commons.apache.org/proper/commons-fileupload/migration.html > >> >>> doesn't > >> >>> give guidance at this level of detail. > >> >>> > >> >>> Is there anything I can do to salvage this code? I know that I > could > >> >>> compile my own version of the source code without the `final` > keyword > >> in > >> >>> `DiskFileItem.class`, but I have to assume there's a reason for it > and > >> >> that > >> >>> it would break other aspects of the code. I hope very much that > >> there's > >> >> a > >> >>> simpler solution. I'm a system administrator, not a programmer, so > I > >> >>> cannot rewrite the package from scratch. > >> >>> > >> >>> Thanks, > >> >>> Joel > >> >>> > >> >> > >> > > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > >> For additional commands, e-mail: user-h...@commons.apache.org > >> > >> >
