New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replaced OsgiClassLoader by managing TCCL #958
Conversation
The OsgiClassLoader is causing problems in a dynamic environment. By managing the Thread Context ClassLoader instead of creating a shared ClassLoader makes it possible to use Hibernate in a dymanic environment.
Sorry, but you are going to have to start a discussion about this on the dev list. OsgiClassLoader and the rest of OSGi support was developed in conjunction with quite a few OSGi community folks. And I know for a fact after personal discussions with Pax and Karaf developers that the hibernate-osgi code works very very well in OSGi environments. So again, you are going to have to start a discussion about this on the dev list and convince us why these are needed. |
A great starting point for illustrating what exactly you are trying to solve would be to add a test to the Pax Exam + Karaf test set up I moved to on master. |
The main reason for this change is to allow updating bundles containing entities. The current hibernate-osgi implementation is working fine with OSGi until you try to update a bundle that's already added to the OsgiClassLoader (at least this was the case with hibernate 4.3). I'll test things again using the version from master and see how that works out. |
As discussed on the Karaf mailing list, that is not supported at all. And On Sun, May 17, 2015 at 9:08 AM, Bram Pouwelse notifications@github.com
|
I'm aware that it's currently not supported but I wan't to have support for this, maybe this is not "the way to do that" (I'd love to hear why). For me it was kind of a test wether it's possible to apply the approach used in my custom hibernate - OSGi integration in hibernate itself as the custom integration is working fine. I'm not in any way attached to this implementation so if you have a better idea of how to get support for updating persistence bundles and you can point me in a direction I'd be happy to spend some time on that aswel. |
Is there a reason you are against discussing this on the hibernate-dev I do have to admit that I find it hilarious that "OSGi folks" spend so much As far as implementation here, I would expect the ability to remove those On Sun, May 17, 2015 at 3:48 PM, Bram Pouwelse notifications@github.com
|
OsgiClassLoader is still needed for several other reasons, especially considering @sebersole's latest work (Steve, feel free to comment with relevant JIRAs, if you're bored). Sure, this would handle the specific persistence unit bundle's updates, but in a naive way. Further, that Bundle isn't the only one we need to watch for updates/deactivation/reactivation. I'm all for better supporting dynamic contexts, but simple TCCL wrappers aren't the way to do that. As Steve mentioned, would love to continue discussing it on the Hibernate mailing list, if you're up for it. |
The OsgiClassLoader is causing problems in a dynamic environment. By managing the Thread Context ClassLoader instead of creating a shared ClassLoader makes it possible to use Hibernate in a dymanic environment.