Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

brampouwelse
Copy link

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.

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.
@sebersole
Copy link
Member

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.

@sebersole sebersole self-assigned this May 15, 2015
@sebersole
Copy link
Member

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.

@brampouwelse
Copy link
Author

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.

@sebersole
Copy link
Member

As discussed on the Karaf mailing list, that is not supported at all. And
this is not the way to do that.

On Sun, May 17, 2015 at 9:08 AM, Bram Pouwelse notifications@github.com
wrote:

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.


Reply to this email directly or view it on GitHub
#958 (comment)
.

@brampouwelse
Copy link
Author

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.

@sebersole
Copy link
Member

Is there a reason you are against discussing this on the hibernate-dev
mailing list like I asked?

I do have to admit that I find it hilarious that "OSGi folks" spend so much
time bashing libraries for using TCCL (pretty sure I have seen Peter
himself poking fun at Hibernate for its old classloading behavior) and now
here we are having "OSGi folks" suggesting a solution that involves, yep,
using TCCL.

As far as implementation here, I would expect the ability to remove those
bundles from the OsgiClassLoader. But I would need a better understanding
overall of what you are trying to accomplish here. What kind of bundle?

On Sun, May 17, 2015 at 3:48 PM, Bram Pouwelse notifications@github.com
wrote:

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.


Reply to this email directly or view it on GitHub
#958 (comment)
.

@brmeyer
Copy link
Member

brmeyer commented Jun 5, 2015

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.

@brmeyer brmeyer closed this Jun 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants