Как вы отлаживаете методы в стиле getResource, которые дают сбой, возвращая null?
Я уверен, что файл, который он ищет, есть, но он возвращает NULL. Как мне узнать, что он ищет, чтобы попытаться обнаружить несоответствие?




Вы можете использовать Eclipse-debug-mode и установить точку останова для метода, который не работает. Оттуда вы можете шаг за шагом спускаться по дереву вызовов, пока не увидите, что не удается.
Чаще всего этого файла нет, потому что он не был скопирован или не указан в пути к классам и т. д.
да, это наиболее часто, это случалось несколько раз при переходе от IDE к сценарию ant для компиляции ...
Вызов getResource ищет файл относительно файла класса.
Сначала я предполагаю, что когда вы скомпилировали, вы забыли поместить файлы ресурсов в папку компиляции. Это то, над чем я часто работал.
Я обычно испытываю это всякий раз, когда изменяется ClassLoader.
В зависимости от точного контекста, в котором запущено приложение, загрузчики классов имеют разные правила о том, когда существует файл ресурсов. Например, в netbeans getResource нечувствителен к регистру, а в Sun JRE - нет.
Не отвечая напрямую на ваш вопрос, я подумал, что вы должны это знать (если вы еще этого не сделали).
Поскольку getResource() ищет путь к классам (как упоминали другие), может быть полезно сбросить фактический путь к классам, который просматривается, до того, как ваш проблемный getResource() вызовет:
log.debug("classpath is: " + System.getProperty("java.class.path"));
//the line that is returning null
... = Thread.currentThread().getContextClassLoader().getResource("foobar");
Вероятно, происходит то, что файлы / каталоги, которые, по вашему мнению, находятся в пути к классам, на самом деле нет (возможно, где-то по пути установлен неверный путь).
Я думаю, вам следует указать Eclipse или вашей любимой среде IDE, где можно найти исходные файлы JDK (JRE). Затем вы также можете перейти к методам классов Java Runtime.
ACK, вот с чем я тоже столкнулся.