Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Improve OSGi integration addressing class loading issues

Description

Please see https://issues.apache.org/jira/browse/CXF-6706.

I, and others, have encountered some problems.

SPI and class loading

As with some other JSRs, javax.validation suffers from classloader problems when used in OSGi. At very least, one must manipulate the thread context classloader. I have never succeeded in making the SPI work; all the examples I have seem end up using a customized provider that references HibernateValidator. If there is a way to get this to work, many would benefit from documentation of it.

However, the problem gets worse. Hibernate goes and calls the API for javax.el _at the time the application calls validate. So, the application has to come up with a classloader that 'sees' com.sun.el (or whatever) when it calls validate, not just when it builds a validator. This is really a pain.

Karaf feature

The Karaf feature provided uses the <wrap> mechanism. This is not desirable, and, in fact, causes Karaf 4 to hang in some cases. It's not needed; see https://github.com/apache/cxf/blob/3.1.x-fixes/osgi/karaf/features/src/main/resources/features.xml#L443 for a working feature that does not use wrap.

However, also note that this depends on the ServiceMix bundle that provides a solution to the SPI classloading problem

Environment

Apache Karaf 4.0,2, etc.

Activity

Show:

Former userDecember 21, 2015 at 12:32 PM
Edited

@Gunnar, the code you are looking at simulated the real world situation. Pax-web runs the whiteboard. it does not import com.sun.el. I can't make it import com.sun.el. It sets the TCCL to its class loader. I can't change that. It calls my service code, and my service code calls HV. That's why the test case sets the TCCL and has the classpath it has.

The idea here was to make a small test case, so I didn't make you one that has an actual servlet with actual pax-web or CXF. I could ...

In any case, think of it from first principles. The ELTermResolver calls ExpressionFactory. ExpressionFactory uses the TCCL to look for the META-INF file or com.sun.el.Ex.... That means that the TCCL has to contain that class or the META-INF file at the time of the call, which can be as late as 'validate'.

This leads to my thought of allowing an ExpressionFactory to be pushed into the configuration class.

Gunnar MorlingDecember 21, 2015 at 10:44 AM

, why is it that you set the TCCL in MockService to begin with? If I remove this, your test passes.

But it also works with the TCCL when adding "com.sun.el" as import package to the "mockwhiteboard" bundle (whose bundle loader you pass in, I suppose by accident, and you meant to pass in the loader of "mockservice" which already has that import?).

So AFAICS don't tinker with the TCCL and all is good We should adapt OsgiIntegrationTest though so it uses @DecimalMin and the test covers the EL usage that way, too.

Former userDecember 20, 2015 at 9:23 PM

This is hard to fix, and I'd appreciate some guidance.

ExpressionFactory.newInstance() lacks any way to pass in a class loader. It always uses the TCCL. Setting the TCCL is a privileged action.

So, can the code HV set the context classloader to the external classloader before creating an expression factory? Or do we need to add an ExpressionFactory to the configuration, and leave it to the caller to fiddle with the TCCL to obtain it?

Former userDecember 20, 2015 at 8:21 PM

I've added a commit that demonstrates the problem. I will now attempt to fix it.

Former userDecember 20, 2015 at 4:21 PM

When my failing test fails, the TCCL is:

ResourceDelegatingBundleClassLoader{bundle=org.apache.cxf.cxf-rt-transports-http [109],parent=BundleClassLoader{bundle=org.ops4j.pax.web.pax-web-jetty [225],parent=null}}

And the reason constraint failing is an @DecimalMin. I think I see how to make a failing small test case.

Fixed

Details

Assignee

Reporter

Labels

Participants

Former user
Gunnar Morling
Hardy Ferentschik

Fix versions

Affects versions

Priority

Created December 15, 2015 at 4:09 AM
Updated October 13, 2016 at 9:13 PM
Resolved December 23, 2015 at 4:15 PM

Flag notifications