No, it's taking me a while to implement these suggestions. I only just now managed to get the app deployed to webapps-javaee/ successfully (thank you, Mark!), but something else must be wrong because we still have errors. We're going to downgrade to Tomcat 9 just to have something working for the time being, then I'll start investigating more targeted solutions like what you're suggesting.
Thanks, Joel On Tue, Jun 17, 2025 at 8:36 AM Gary Gregory <garydgreg...@gmail.com> wrote: > 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 > > >> > > >> > > >
