• Bug
  • Status: Closed
  • 3 Minor
  • Resolution: Fixed
  • cdennis
  • Reporter: foshea
  • December 19, 2008
  • 0
  • Watchers: 0
  • April 10, 2009
  • February 10, 2009

Description

Taken from CDV-645 and broken out as they are not the same error

Taylor Gautier - 12/Nov/08 02:48 PM - edited Seen again - or at least looks to be the same species of bug: —————————————————————————————- AW::WARNING - could not load class [org/mozilla/javascript/ NativeFunction] as a resource in loader [[email protected]] AW::WARNING - could not load class [org/mozilla/javascript/Script] as a resource in loader [org.mozilla[email protected]]

This does not occur where the terracotta configuration has been commented out. Services still appear to work despite this classloading error.

Is this something which has been seen by anyone already?

We plan to be guinea pigs and phase this into production here at USC in about a week or so, and I’d like to confirm that this message can be fixed or can safely be ignored.

Comments

Fiona OShea 2008-12-19

Rob Beazizo - 18/Dec/08 12:32 PM We are having the “AW::WARNING - could not load class [org/mozilla/javascript/ NativeFunction] as a resource in loader”. Unfortunately the code path is in a very high traveled path so it ends up spamming our logs.

Is there anyway to make it not spam the our logs when this happens?

Fiona OShea 2008-12-19

Linked to CDV-645 as comments were added to that Jira, which were unrelated to the bootjar warnings issue but are a separate issue

Chris Dennis 2009-02-10

The error is caused when a class loader doesn’t follow the convention for a file based class loader that the class bytes for the class “this.is.my.java.Class” can retrieved through the resource “this/is/my/java/Class.class”. In particular this is not true for class loaders loading dynamically loaded classes. I can suppress the logging of the message, but I’d like to investigate further to ensure that this isn’t going to cause a debugging nightmare further down the line.

Chris Dennis 2009-02-10

This has been resolved by commenting the logging in AsmClassInfo. The error is harmless in almost all cases. Ideally this should be logged, but at a more verbose level (like DEBUG), however it appears this is not possible without adding further classes to the boot jar.

nadeem ghani 2009-04-08

A simple fix, and examinator isn’t throwing these errors anymore