How to fix ClassNotFoundExceptions for exceptions thrown in pax exam test?

[Steinar Bang]

Platform: debian 11.7 "bullseye", amd64
openjdk-17-jdk:amd64 17.0.6+10-1~deb11u1 (ie. java 17)
karaf 4.4.3
pax-exam 4.13.5
eclipse 2023-03 (4.27.0)

I am trying to run a pax exam test that runs a liquibase changelist to
set up a schema and then add a row to a table in that schema and reads
it back out.

What I'm trying to do is add more asserting to this test to verify that
the database schema was actually created and is working:
https://github.com/steinarb/liquibase-karaf-feature/blob/master/liquibase-integration-test/karaf.liquibase.tests/src/test/java/no/priv/bang/karaf/liquibase/tests/LiquibaseKarafFeatureIntegrationTest.java#L55

When the tests fails in the database I get a classnotfoundexception on org.apache.derby.shared.common.error.DerbySQLIntegrityConstraintViolationException
and the following stack trace:
https://gist.github.com/steinarb/e80ec79aa66bf48e58e441d172931989

Is it possible to get a stack trace for the actual failure, instead of a
stack trace for not finding the exception class (which this seems to
be...?).

Thanks!


- Steinar

[Grzegorz Grzybek]

Hello

`RemoteBundleContextClientImpl` in the stack trace means that it (the stack trace) comes from client side of the test.

Pax Exam is not difficult if it comes about writing @Test-annotated methods, but it is very difficult when trying to set everything up correctly, so jars not conflict with actual bundles and client/server side of things behaves as expected.

In your stack trace you obviously miss the exception class on client-side classpath (when running from Eclipse). To be honest I never run such tests from Eclipse/IDEA, I always run from Maven (surefire/failsafe) and do a remote debugging. You can debug Maven, surefire itself or Karaf container started from surefire (3 separate JVMs involved...).

In your case I'd first look at the server side logs - you're running pax-exam-container-karaf, so you should have logs in the Karaf instance started by Pax Exam - don't forget to call org.ops4j.pax.exam.karaf.options.KarafDistributionOption#keepRuntimeFolder() in your Pax Exam configuration method.

And to really get org.apache.derby.shared.common.error.DerbySQLIntegrityConstraintViolationException at client side, be sure to have Derby driver on the classpath.

regards

Grzegorz Grzybek

--
--
------------------
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/87a5xglcvd.fsf%40dod.no.

[Steinar Bang]

>>>>> Grzegorz Grzybek <gr.grzybek-Re5JQ...@public.gmane.org>:

> `RemoteBundleContextClientImpl` in the stack trace means that it (the stack
> trace) comes from client side of the test.

> Pax Exam is not difficult if it comes about writing @Test-annotated
> methods, but it is very difficult when trying to set everything up
> correctly, so jars not conflict with actual bundles and client/server side
> of things behaves as expected.

> In your stack trace you obviously miss the exception class on client-side
> classpath (when running from Eclipse).

Thanks! When posting this message I thought I had tried adding a maven
dependency to the project (which should be the client side) and it
didn't work.

But maybe I added the wrong dependency, because when I later tried
adding a dependency, the classNotFound exception went away and I got the
underlying database constraint violation instead.
https://github.com/steinarb/liquibase-karaf-feature/commit/fff4b1a0ff88cc2270fe4934e5ec50cc9347e094

And when I fixed it in this way, I forgot about this message to the
mailing list.

On a side note: the constraint violation here is related to the "wrong
assert triggered".

Like you said, this may be caused by database rollback in some way, but
I don't see how this could be caused by the asserts, since the asserts
happens outside of the try-with-resource clauses determining the life
cycle of the JDBC Connection instances interacting with the database.

If I get a constraint violation here there is really only one thing that
could cause it, and that would be me trying to add the same account
username twice.

And my integration test only add the account once.

One thing that would cause this would be if the test itself is run more
than once against the same database.

Could a failing assert cause the test to be re-run somehow?

> To be honest I never run such tests from Eclipse/IDEA, I always run
> from Maven (surefire/failsafe) and do a remote debugging. You can
> debug Maven, surefire itself or Karaf container started from surefire
> (3 separate JVMs involved...).

The test here was originally a minimal karaf application I used to test
my liquibase feature. But testing the feature manually was boring, so I
decided to automate it and put the automated test into the maven build
of the fature.

If I want to test the application in a regular karaf instance, where I
can easily debug, I can still load the feature from the integration
test:
https://github.com/steinarb/liquibase-karaf-feature#testing-and-debugging-in-karaf

See the neighbouring thread for a description of the integration test.

> In your case I'd first look at the server side logs - you're running
> pax-exam-container-karaf, so you should have logs in the Karaf instance
> started by Pax Exam - don't forget to call
> org.ops4j.pax.exam.karaf.options.KarafDistributionOption#keepRuntimeFolder()
> in your Pax Exam configuration method.

The karaf.log of the pax exam test had the
org.apache.derby.shared.common.error.DerbySQLIntegrityConstraintViolationException
with the actual constraints message.

> And to really get
> org.apache.derby.shared.common.error.DerbySQLIntegrityConstraintViolationException
> at client side, be sure to have Derby driver on the classpath.

Yep. Just had to add the right derby dependency...

Thanks!