What is the error to which you refer?

The error occurs when a user operates on a resource in the context of a transaction, where that transaction ID that does not exist. For example:

curl -i localhost:8080/fcrepo/rest/tx:fake/foo

(here, tx:fake is a non-existent transaction id; foo is a resource that may exist)

The exception is wrapped in a ClientErrorException, so the REST API simply responds with a 410 Gone, but if you tail the container log (e.g. tomcat's catalina.out file), you will see a nice long stacktrace like this: https://gist.github.com/acoburn/86d46e4d4322cfa08160. I get that error with verson 4.3.0, 4.4.0 and the current snapshot. I am certain that it exists in earlier versions, too.

That same stacktrace had been appearing in the integration tests and was reported in pivotal. This was addressed with 58bdaa2 at which point the errors were no longer displayed during integration tests. However, that did not actually fix the error; it only covers it up so that it is not visible during integration tests.

The underlying issue is that Jersey is configured to Inject a session into some type of fedora AbstractResource, but if an exception is thrown before that session can be injected into the class, you get the "Unknown HK2 failure detected".

By removing the jul-to-slf4j dependency, you not only get OSGi support for fcrepo-http-commons, but you reveal an error in the implementation that currently exists, but which is masked. By revealing the error, it can be fixed.

The errors can also be revealed by removing these lines from the fcrepo-http-api module: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-api/src/test/resources/logback-test.xml#L22-L24