https://bz.apache.org/bugzilla/show_bug.cgi?id=65273

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Mark Thomas <ma...@apache.org> ---
I can confirm that this isn't a Tomcat issue so I will be closing this as
invalid.

To reproduce the issue I used the following:
- Ubuntu 20.04 fully patched
- Installed Jira latest (8.16.1)
- Installed R4J
- Created a simple project (TEST)
- Created a single issue
- Activated the TEST project in R4J
- Selected TEST from the Requirements menu
- Clicked Export -> Word

You only see the ClassCastException the first time you click export. To see it
again you need to restart Jira.

I have done some digging via remote debugging and I can confirm that this is a
class loading issue.

When R4J calls POI the XMLEventFactory class is loaded by an instance of
BundleWiringImpl$BundleClassLoader. The parent of that class loader is Tomcat's
web application class loader.

When POI calls XMLEventFactory.newInstance() that triggers the standard search
using the Thread's context class loader (TCCL). Interestingly, the TCCL at this
point is not the class loader that loaded XMLEventFactory above. The result is
an instance of org.apache.xerces.stax.XMLEventFactoryImpl which is loaded by
Tomcat's web application class loader. Its super class is XMLEventFactory BUT
that class is loaded by the system class loader.

Hence when the assignment is attempted, you get the ClassCastException because
you have two versions of XMLEventFactory loaded by different class loaders.

I don't know Jira's class loader structure well enough to provide a specific
solution but I can say what a possible general solution might look like.

Option 1. Don't ship stax-api with R4J. Let it use the version provided by the
JRE.

Option 2. Provide a stax implementation with R4J *and* ensure that the search
mechanism finds it. (Maybe set TCCL to XMLEventFactory.class.getClassLoader()
before the call. Remember to use a finally block to restore the old value
afterwards.)

Option 3. Newer versions of POI don't use STAX - at least not at the point
where the error is occurring. Updating to a newer version of POI may avoid the
issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to