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
>>
>>
