Проблема здесь, скорее всего, не в том, что OSGi не имеет понятия файловой системы, а в том, что файл больше не находится на пути к классам.
Я предполагаю, что когда война идет в обычном режиме, рабочий файл workflow.xml, на который вы ссылаетесь, находится в файловой системе и доступен через путь к классу tomcat. Загрузчик классов для WAR делегирует родительский загрузчик классов, который может получить доступ к файлу workflow.xml.
В OSGi ваш classpath определяется Bundle-Classpath и любым импортом пакета или требованиями к пакету. Этот файл workflow.xml, очевидно, недоступен с помощью любого из этих механизмов.
Есть несколько вариантов:
- Поместите файл workflow.xml в комплект и поместите его в Bundle-Classpath. Это не очень хорошо, если вы хотите, чтобы файл был редактируемым без перестройки WAB.
- При запуске платформы OSGi добавьте файл workflow.xml в путь к классам. Затем в качестве опции запуска фреймворка установите org.osgi.framework.bootdelegation как com.xyz.abc.resource. Обратите внимание, что если вы сделаете это, вы больше не сможете загружать com.xyz.abc.resource из среды OSGi, он всегда будет загружать их из родительского загрузчика классов инфраструктуры
- Если вы используете равноденствие, вы можете поместить внешние файлы в путь к классам комплекта, добавив external: в начало пути к файлу в Bundle-Classpath. Это несколько искусственно, так как ваш пакет вряд ли будет работать в другом месте.
Все это немного (очень) странно, так что вы можете посмотреть другой способ загрузки этого файла. Я не знаком с OsgiBundleResource.
Если вы работаете в OSGi, возможно, вы захотите взглянуть на спецификацию Blueprint Container, основанную на Spring DM. Мне известны две реализации: Apache Aries и Eclipse Gemini.