HHH-7996 OSGi integration/unit test using Arquillian & Felix

[brmeyer]

No description provided.

[brmeyer]

@sebersole and @gunnarmorling, can you look through this if you get a chance? If there's anything confusing or not clear after reading the comments, please say so -- there's probably a lot of gaps I need to fill in.

[brmeyer]

@timothyjward, you've already gone way above and beyond with helping us, but I'm really curious to get your opinion on this as well if you have a moment sometime.

The "requestingBundle" concept in the OsgiClassLoader (and other CL issues) determined the architecture and kept the actual tests in an isolated bundle, rather than attempting to roll it up dynamically with ShrinkWrap or Tinybundles. I'm sure it's not the first time a test like this has come up. If I'm way off base, please be blunt ;)

[gunnarmorling]

Indentation of the OSGi dep's seems odd.

[gunnarmorling]

@brmeyer Brett, I've added some minor remarks inline.

What was the issue with PAX exam you ran into? I also remember you once sent me a link to a page documenting the Hibernate/OSGi integration. Could you send me that link again?

[brmeyer]

@gunnarmorling, thanks much for the review!

The PAX issue was essentially the same I eventually hit with Arquillian as well: CL issues when using Tinybundles, ShrinkWrap, or other alternate solutions to try and stay away from having to use a separate bundle. If the persistence unit "bundle" is on the same classpath as the unit test (and implicitly the entire Felix framework), lots of issues come up. I'm more than happy to document specifics elsewhere, if needed.

But, I stuck with Arquillian because ORM already depended on it and because I'd like to eventually test against JBOSGi.

[timothyjward]

Hi @brmeyer

I've had a look through, and the solution you've ended up with is actually very similar to the JPA integration tests in Apache Aries :)

As you've mentioned in the documentation, these tests are a bit higher level than normal, but I agree that it's the only sensible way to do in-situ testing without a lot of confusing ClassLoader hacks.

[brmeyer]

@timothyjward , thanks much! I should have asked about the Aries tests prior to taking the long road of landing on the solution myself...

[brmeyer]

@timothyjward , one question that came up:

This PR included re-ordering of hibernate-core's CL list, but I'm realizing it may need to be switched back -- there's other issues to worry about, outside of OSGi.

So, hibernate-core's aggregated CL needs to check the following CLs, in order, when attempting to load a class or resource:

1.) "providedClassLoaders" (ie, OsgiClassLoader)
2.) hibernate-core's CL (this.class.getClassLoader())
3.) TCCL
4.) SystemClassLoader

When doing so, I hit an issue when loading a class by name. As an example, H2Dialect extends Dialect, and both are within the same package in hibernate-core. If H2Dialect is loaded by name (using OsgiClassLoader), then returned as a Dialect within hibernate-core, you get a ClassCastException. I'm guessing loading H2Dialect through OsgiClassLoader, then casting within hibernate-core's CL causes that.

However, that's confusing me. Our original OsgiClassLoader work included "osgiClassLoader.addBundle( FrameworkUtil.getBundle( Session.class ) );" (hibernate-orm CL). Is that not the same CL as used within hibernate-core itself? Am I missing something else trivial?

Or, should 2.) really be 1.) in that list?

Thanks!

[brmeyer]

Tim, this was overcome by forcing OsgiClassLoader to completely ignore ClassLoader#parent (which is set to the SystemCL, I believe, at least within the unit test framework) on #loadClass. And I think that makes sense. It allows the OsgiClassLoader to check only the bundles and persistence unit, then implicitly punt back to the hibernate-core aggregated CL if needed. Am I off base?

[brmeyer]

Squashed and pushed. To ensure it'll work on CI, out of the box, completely rm'd my Gradle caches -- runs with no issue. If you guys see any issues, I'll open new tickets. Thanks again, Tim!