ClassLoader на виртуальной машине - PullRequest
Новая
       7

ClassLoader на виртуальной машине

3 голосов
/ 27 января 2010

У меня есть исходный код: 

private Image getImage(String path, ClassLoader loader) {
    InputStream image = null;
    try {
        image = loader.getResourceAsStream(path);
        return new Image(PlatformUI.getWorkbench().getDisplay(), image);
    } finally {
        if (image != null) {
            try {
                image.close();
            } 
            catch (IOException e) {
                //OK
            }
        }
    }
}

На моем компьютере этот код работает отлично. Но на линии виртуальных машин: 

loader.getResourceAsStream(path);

всегда возвращает ноль. Почему?

EDIT:

Путь - это относительный путь. Например: icons / tools / device.png. Приложение, которое я разрабатываю, содержит более десяти проектов. Я использую Eclipse IDE. Все проекты имеют структуру:

  • com.pkg.name - папка с иконками классов
  • папка с иконками и другими файлами

Jar-файлы тоже имеют такую ​​структуру.

На моем компьютере приложения работают отлично. На виртуальной машине (Windows Server (64-разрядная)) приложение не может загрузить изображения из файла Jar.

Ответы [ 2 ]

1 голос
/ 27 января 2010

Если путь является относительным путем, то он должен работать, если ресурс изображения был скопирован вместе с файлами классов (как уже упоминалось в Itay), а папка или банка, содержащие ресурс изображения, находятся в пути к классам ( используете ли вы CLASSPATH или -cp для указания пути к классу? Если вы полагаетесь на CLASSPATH, убедитесь, что эта переменная среды правильно установлена ​​для пользователя, выполняющего приложение)

Если это абсолютный путь, дважды проверьте, действителен ли он на целевой виртуальной машине.

так в основном, для структуры папок типа 

./classes
./images
./libs

команда java -cp classes;images;libs/* my.app.Application должна работать (java 1.6 - в более старых версиях подстановочный знак не допускается), принимая значение пути, например images/myImage.jpg.

Еще одна мысль, разделитель пути к классам - ; в Windows и : в Unix. Это может быть проблемой, если вы подготовили приложение в среде Unix-типа.

Редактировать

Читаете ли вы изображение из той же библиотеки, что и настоящий файл классов? Тогда, пожалуйста, попробуйте: 

this.getClass().getResourceAsStream(path)

Редактировать

ОК, это OSGi. Таким образом, есть еще несколько причин, по которым приложение работает из среды IDE затмения, но не при развертывании в виде приложения RCP. Я думаю, что это не имеет ничего общего с целевой средой.

В OSGi каждый пакет имеет свой собственный загрузчик классов, и класс из bundle1 не сможет видеть классы из bundle2, если пакеты не экспортированы должным образом. Это верно и для ресурсов. Я думаю, что изображение хранится в другой пачке. Я не знаю, какой загрузчик классов передается методу getImage, но этот загрузчик классов определенно не видит файл ресурсов.

Это может работать внутри затмения, особенно если вы добавляете проекты друг к другу в пути компоновки.

После того, как вы собрали продукт, вы сказали, что он не работает (частично) на виртуальной машине, но показывает ли этот же продукт изображение на локальном компьютере (вне затмения)?

0 голосов
/ 27 января 2010

Вы не предоставили достаточно информации, но вот мое предположение:

Когда вы копируете код в место, где он будет выполняться на другой (виртуальной) машине, вы копируете только файлы * .class. Вам необходимо скопировать другие ресурсы (в частности, файлы изображений) и поместить их вместе с файлами * .class, чтобы загрузчик классов мог их извлечь.

Когда вы разрабатываете код с Eclipse (или другими IDE), Eclipse заботится о копировании ваших ресурсов из каталога src / в каталог bin /.

...