pdfbox-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: PDFBox JPEG2000 and Tomcat - Revisited
Date Fri, 03 Aug 2018 15:15:09 GMT

On 8/2/18 12:10 AM, Joel Hirsh wrote:
> 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
> "java.lang.NoClassDefFoundError:
> Could not initialize class".
> And I have seen that same error with other ClassLoader problems under
> Tomcat.

I understand, but there is a root-cause for "Could not initialize
class". Usually, it's something that fails unexpectedly in a static
initializer or something like that, and it should have its own separate
stack trace.


> 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

View raw message