pdfbox-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joel Hirsh <joelehi...@gmail.com>
Subject Re: PDFBox JPEG2000 and Tomcat - Revisited
Date Thu, 02 Aug 2018 04:10:16 GMT
Thanks for the explanation. I will look towards the tomcat mailing list.

Per your request about the entire stack trace - there is more above the
first call to PDFBox, but the root cause in both cases is indeed
Could not initialize class".
And I have seen that same error with other ClassLoader problems under

On Wed, Aug 1, 2018 at 1:39 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> Joel,
> On 8/1/18 3:54 PM, Joel Hirsh wrote:
> > However, your comment that "Tomcat doesn't unload libraries" is not
> > entirely true. There is an explanation of such symptions at
> > https://haraldk.github.io/TwelveMonkeys/, under the section "Deploying
> the
> > plugins in a web app".
> Thanks for posting that. Lemmie 'splain.
> In a servlet container, web applications (aka "contexts") each have
> their own ClassLoader and if the application is undeployed or
> re-deployed, then that ClassLoader will be freed for GC. If a class
> loaded by that webapp's ClassLoader is still in use, you have a memory
> leak situation knows as a "pinned ClassLoader".
> It happens all the time when you use a system-global cache such as
> ImageIO does. This can happen with JDBC DriverManger and a handful of
> other common APIs and it can be a serious problem for servers where
> there are lots of redeployments. You can also start to see errors like
> "ClassCastException: Cannot cast foo.bar.Class to foo.bar.Class" because
> instanceof-ness is defined not just by Class but also by ClassLoader.
> The IIOProviderContextListener mentioned in that documentation is one
> strategy to handle the unfortunate way ImageIO caches classes. Another
> strategy is to put the library into a place where it is accessible to
> all web applications instead of just one.
> > Just putting jars in a shared folder did not help.
> Here is where asking on the Tomcat mailing list *will* be a good idea.
> Make sure to give your exact Tomcat version and explain where you put
> the library.
> Can you post the *entire* stack trace from the failure? It looks like
> it's incomplete -- it doesn't seem to have a "true root cause". It just
> says "Could not initialize class" because "Could not initialize class".
> Somewhere there should be a real root cause like NullPointerException or
> something that can actually be debugged. Def post that to the Tomcat
> mailing list as well if you post.
> -chris

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message