Hibernate не очень хороший гражданин OSGi, поскольку многие предположения, которые Hibernate делает в отношении видимости классов, больше не соответствуют действительности в контейнере OSGi.
Обычный способ загрузки драйверов JDBC с Class.forName(<jdbc class name>)
не работает внутри OSGi, потому что в этом случае Hibernate попытается загрузить драйвер, но не найдет его, как Hibernate (и не должен ) импортировать пакет драйвера JDBC.
Диспетчер драйверов JDBC также пытается проявить смекалку, выясняя, должен ли загрузчик класса вызывающего класса видеть драйвер, и это также конфликтует с OSGi.
Если вы используете Spring для настройки Hibernate, то я предлагаю вам использовать класс SimpleDriverDataSource
, так как это работает в OSGi, и Spring позволяет вам настраивать Hibernate с конкретным источником данных, а не передавать имя класса, которое Hibernate необходимо создать.
Как только вы преодолеете эту проблему, вы, вероятно, столкнетесь с проблемами Hibernate, не видя классов вашего домена. У меня есть только опыт работы с подходом сопоставления XML, с которым я думаю, что в OSGi проще, так как я думаю, что способ аннотаций требует некоторого вида AOP-ткачества, и это еще одна проблема в OSGi.
В настоящий момент, если вы не используете что-то вроде dm-сервера Spring, вам нужно будет гораздо ближе познакомиться с механизмом загрузки классов Java и с тем, как вы можете использовать подход OSGi к сервисам, чтобы обойти несовместимости между vanilla Java и миром OSGi. .
В частности, посмотрите, как корпоративные библиотеки используют загрузчик классов контекста, и как вы можете управлять этим. Я использую Spring dm для переноса унаследованного кода в сервисы OSGi, поскольку это облегчает управление загрузчиком классов контекста.