On Mon, Mar 25, 2024 at 6:02 PM Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> Rémy,
>
> On 3/25/24 10:21, Rémy Maucherat wrote:
> > On Mon, Mar 25, 2024 at 2:32 PM Christopher Schultz
> > <ch...@christopherschultz.net> wrote:
> >>
> >> Rémy,
> >>
> >> On 3/22/24 11:39, Rémy Maucherat wrote:
> >>> On Fri, Mar 22, 2024 at 2:40 PM <schu...@apache.org> wrote:
> >>>>
> >>>> This is an automated email from the ASF dual-hosted git repository.
> >>>>
> >>>> schultz pushed a commit to branch main
> >>>> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >>>>
> >>>>
> >>>> The following commit(s) were added to refs/heads/main by this push:
> >>>> new 988992ba2e Use server's ClassLoader instead of application's
> >>>> when loading XMLInputFactory.
> >>>> 988992ba2e is described below
> >>>>
> >>>> commit 988992ba2e9a8e2c3db47ac960c2fa6c3fc7a8a4
> >>>> Author: Christopher Schultz <ch...@christopherschultz.net>
> >>>> AuthorDate: Fri Mar 22 09:37:08 2024 -0400
> >>>>
> >>>> Use server's ClassLoader instead of application's when loading
> >>>> XMLInputFactory.
> >>>
> >>> It doesn't work because there's nothing corresponding to the
> >>> XMLInputFactory.class.getName() id. The default newFactory doesn't do
> >>> the same thing at all.
> >>
> >> Ugh, sorry about that. Thanks for fixing it.
> >>
> >> Setting the ContextClassLoader seems like the wrong approach. Isn't
> >> there a ClassLoader parameter to getFactory for a reason?
> >
> > Feel free to revert it if you don't like it.
>
> Well, using the "obvious" solution didn't work, so ...
>
> I didn't realize that the JRE classes would use
> Thread.currentClassLoader for anything. Does this actually achieve the
> goal of preventing an XMLInputFactory leak? I should probably ask the
> reporter...
Yes, it ends up using SecuritySupport.getContextClassLoader(), which
returns either the context CL or the system CL (if null) using a
privileged action wrapper.
That's how it picks up the application class loader.
Rémy
>
> -chris
>
> >>>> java/org/apache/jasper/compiler/EncodingDetector.java | 3 ++-
> >>>> webapps/docs/changelog.xml | 5 +++++
> >>>> 2 files changed, 7 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/java/org/apache/jasper/compiler/EncodingDetector.java
> >>>> b/java/org/apache/jasper/compiler/EncodingDetector.java
> >>>> index bac9ade2ee..cf3b623104 100644
> >>>> --- a/java/org/apache/jasper/compiler/EncodingDetector.java
> >>>> +++ b/java/org/apache/jasper/compiler/EncodingDetector.java
> >>>> @@ -35,7 +35,8 @@ class EncodingDetector {
> >>>>
> >>>> private static final XMLInputFactory XML_INPUT_FACTORY;
> >>>> static {
> >>>> - XML_INPUT_FACTORY = XMLInputFactory.newInstance();
> >>>> + XML_INPUT_FACTORY =
> >>>> XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
> >>>> + EncodingDetector.class.getClassLoader());
> >>>> }
> >>>>
> >>>> private final String encoding;
> >>>> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> >>>> index 341c3a6596..0eca891322 100644
> >>>> --- a/webapps/docs/changelog.xml
> >>>> +++ b/webapps/docs/changelog.xml
> >>>> @@ -179,6 +179,11 @@
> >>>> and the web application is deployed as a WAR file rather than
> >>>> an
> >>>> unpacked directory. (markt)
> >>>> </fix>
> >>>> + <fix>
> >>>> + Prevent the web application's ClassLoader from being pinned by
> >>>> the JSP
> >>>> + compiler if an application uses a custom XMLInputFactory. Based
> >>>> upon a
> >>>> + suggestion from Simon Niederberger. (schultz)
> >>>> + </fix>
> >>>> </changelog>
> >>>> </subsection>
> >>>> <subsection name="Other">
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >>> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
