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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
