1) The idea was to work on OSGi support for hibernate-entitymanager first and add in support for hibernate-core later. The difficulty here is the vastly different config mechanisms between hem and core.

2) An incomplete list would be: Service, Type, UserType, Integrator. As we transition to 5.0 that would expand to include stuff like TypeContributor, MetadataSourceContributor, etc.

3) Not sure what the point is. IIUC the activator API accounts for both activation and deactivation. If something is deactivated and causes the app as a whole to break... oh well, thats not our concern IMHO.

4) This is something I cannot really answer. Ideally we'd just handle classloaders for bundles that we actually care about. How that works out in OSGi specifics is uncertain to me as I am not an OSGi expert. However, there is another option here. Everyone focuses on classloaders. However, the assumption there is that Hibernate will need to be able to load classes by name. If instead the other bundle registered actual Class instances or instantiations of those Classes then we would not actually need access to the classloader. Just something to consider.

5) For the most part, that would be a function of "start-up", so if there were any performance hit, I cannot see how it would be a running system. There are edge-cases where that could happen, yes. Easy enough to gauge; find all usages of the pertinent ClassLoaderService methods.

6) I am inclined to call this an error condition. Perhaps ultimately we can offer a "resolution strategy", but for the initial iteration I'd prefer to keep things simple and let the actual requirements here grow from community use.