@awoods it's not that jena.atlas is not OSGi friendly, but rather that there is a transitive dependency clash:

fcrepo-camel depends on clerezza to do some rdf (de-)serialization, and that in turn depends on a wrapped version of jena (version 2.11), which does not contain that particular o.a.jena.atlas class. So, when fcrepo4 is launched for the integration tests, the class loader can't find the jena.atlas class in question, since it doesn't exist in the wrapped clerezza bundles.

That is to say, this proposed change is fine, but perhaps we should address it with a change in the camel component -- though doing so is a bit more complex.

@acoburn, I will leave it up to you if you would prefer handling this with the current PR or doing something else within fcrepo-camel.

Personally, pushing the exception handling down from FedoraLdp into ContentExposingResource seems like an improvement in any case.

@awoods I'll take a look at how complicated a fix for this in the camel component. Either way, I agree with you that moving the exception handling to ContentExposingResource is a good thing.