Hibernate isn't a very good OSGi citizen as many of the assumptions Hibernate makes on class visibility are no longer true in an OSGi container.
The usual way of loading JDBC drivers with the Class.forName(<jdbc class name>)
doesn't work inside OSGi because, in this case, Hibernate will try and load the driver but won't find it as Hibernate doesn't (and shouldn't) import the JDBC driver package.
The JDBC driver manager also tries to be smart by working out whether the calling class' class loader should see the driver and this also conflicts with OSGi.
If you use Spring to configure Hibernate then I suggest you use the SimpleDriverDataSource
class as this works in OSGi and Spring allows you to configure Hibernate with a concrete data source rather than passing a class name that Hibernate needs to instantiate.
Once you get past that problem you'll probably run into the issues of Hibernate not seeing your domain classes. I only have experience with the XML mapping approach, with I think is simpler in OSGi as I think the annotations way requires AOP weaving of some sort and that's another current pain-point with OSGi.
At the moment, unless you use something like Spring's dm Server you'll need to become much more familiar with Java's class loading mechanism and how you can use OSGi's approach to services to work around the incompatibilities between vanilla Java and the OSGi world.
Specifically, look into how enterprise libraries use the context class loader and how you can manage this. I am using Spring dm to wrap legacy code in OSGi services as this makes it easy to control the context class loader.