Is it dead?

[marwin1991]

Is it dead ?

[bartoszmajsak]

Hi, the creator here. I am not actively involved in it, but I can help with PRs if needed.

[abregar]

Hi, @bartoszmajsak, hijacking this last issue opened under your project and kind-a-fits the question of mine.

I see that this wonderful project is now not maintained anymore, but .. it is still very useful, even 5yrs later. Or, it was useful until a project of mine was decided to upgrade to latest frameworks (wildfly27, jakarta10, java17, arquillian1.7, junit5).

Then things started to behave as started in discussion here wildfly/wildfly-arquillian#278 (comment)

I am posting a follow-up under this ticket as you have written that you might help with PR if needed. It is needed now :).
I am particularly interested in there mentioned

<groupId>org.arquillian.ape</groupId>
<artifactId>arquillian-ape-sql-container-dbunit</artifactId>
<version>2.0.0-alpha.7</version>

dependency, but probably there would be some adjustments required in core ape project. I am willing to put some effort into solving this, for starter at least this sql-dbunit part. But would be really glad if you are able to give some debug runs and hint me some guidance in this broad problem space.

Meantime - side-question -> is dbunit project used now tracked here https://sourceforge.net/p/dbunit/ or is there any other fork around? This particular one still seems kind'a alive, at least this ticket is promising https://sourceforge.net/p/dbunit/feature-requests/222/ (junit5 compatibility)

Thank you in advance, a lot!

[bartoszmajsak]

Hi @abregar. Thanks for your interest in the project. I'm more than happy to help you with anything needed, so by all means open PR (even as a draft) and I will make sure to find some time so we can work on this together.

I don't think there's any superior fork for DBUnit that is actively maintained, but I wouldn't have a lot of hopes for this feature to arrive if we don't help (see comments from maintainers). @rmpestano (apologies for calling you out of the blue) perhaps you have some more insights about JUnit5/DBUnit combo considering that it works with https://github.com/database-rider/database-rider

[abregar]

Glad to hear from you, dear Sir. Did put some effort today into this project, and truly have some draft with upgraded deps to desired ones. It builds, is usable to run, but tests are failing many places <- will try some more, and prepare some better 'draft' PR.

Meantime, while I was able to put together all updated artifacts (long story short), my IT test started to execute (probably over with the issue noted here wildfly-arquillian/discussions/278). But it seems I hit some variation of this issue arquillian/arquillian-extension-transaction#31, meaning that simple test as bellow:

    @Test
    @UsingDataSet("arquillianTest.xml")
    @Transactional(TransactionMode.ROLLBACK)
    public void test() {
        System.out.println("nothing, just initialize the db and rollback");
    }

does not do the rollback under junit5. (Meantime2, I have also some small updates on arquillian-extension-transaction project to make it compatible with jakarta 10 and wildfly 27, maybe a PR there too - really draft again ?)

May I ask if you are willing to put some small amount of time and try to give some hints on the transaction issue #31 and how to properly debug it?

[bartoszmajsak]

@abregar could share a little reproducer project?

[abregar]

@bartoszmajsak here, the two reproducible cases
https://github.com/abregar/arquillian-ape-wf26-case195
https://github.com/abregar/arquillian-ape-wf27-case195
please see the readme for details, and let me know if I need to update something to clarify more.

Sub-note - for the wf27 case, there are two explicit dependency requirements (ape-transaction and ape-persistence). I have forked both and committed the fixes in specific branches. Please take a look, as ape-persistence is really huge project and as written in commit log, I have commented out some modules where I was unable to fix the source and make the tests run. As far as I got, issues are when upgrading some deps versions to latest (supporting jakarta) there are significant changes in their code (i.e. flyway 6 removed callbacks ..). And it seems that sql-*ftest modules are failing on dependent project https://github.com/arquillian/arquillian-cube. I did demystify some concepts on all those mentioned projects, seems interesting .. but it will take some time (and help from you) to complete as whole.

So, by knowing this, can we please keep focus only in this particular case with dbunit for start, and then eventually bring complete project back to life?

[abregar]

Just dropping some findings, after some deep dive in debug. Not finished yet, but would appreciate any hints, if rings any bells already. So, two things with latest combination (wf27).

One, seems that 'Observes' precedence is not taken into account somehow. I think the PersistenceTestTrigger observes

 public void afterTest(@Observes(precedence = -2) After afterTestEvent) {
      if (persistenceExtensionEnabler.get().shouldPersistenceExtensionBeActivated()) {
          afterPersistenceTestEvent.fire(new AfterPersistenceTest(afterTestEvent));
      }
  }

prior TransactionHandler observers the After context

  public void endTransactionAfterTest(@Observes(precedence = -1) EventContext<After> afterTestContext) {
      try {
          afterTestContext.proceed();
      } finally {
          endTransaction(afterTestContext.getEvent());
      }
  }

Consequently the database cleanup is triggered not after test but prior test ending.

Two, the check for required-rollback-due-to-failure in TransactionHandler, as in

private boolean testRequiresRollbackDueToFailure() {
    if (testResultInstance.get() != null) {
    ...

always return true due injected testResultInstance.get() returns null for unknown reason. This check returning true then messes up with previous point, and db cleanup (seems properly prepared) statement batch execution gets rollbacked.

Just side note, none of the above points can be seen in the combination with wf26 test case.

@bartoszmajsak can you please give opinion on those findings and what do you think to do, to correct them?

[abregar]

Discussing to myself here :), but still maybe someone may join .. did some digging around arquillian-* related github code and discussions, I see now that there is a longer story on junit5<->arquillian integration. Kudos to all involved, and for general public, please see the know-how around the issue arquillian/arquillian-core#137

Initial great work in the core arquillian is done, .. but seems that there is actually none of the current arquillian-extension-* with even a try to adopt that integration. So in the context of this issue ( #195), maybe it is not arquillian-extension-transaction issue but more arquillian-extension-persistence, but this is to be decided later by project owner(s).

How I see things now - there is new api in junit5 who manages test Lifecycle - and that is https://junit.org/junit5/docs/current/api/org.junit.jupiter.api/org/junit/jupiter/api/extension/package-summary.html. Consequently no more events/observers as in junit4, but Invocation Interceptor(s) instead.

The idea I see above, is really drafted in commit abregar@9d8da17

But there seems I have some more missing pieces as this jupiter extension is not registered somehow. Did try the following pattern, as suggested in junit5 docs https://junit.org/junit5/docs/current/user-guide/#extensions-registration-automatic and patched the runner class in arquillian-core:

public class JUnitJupiterTestRunner implements TestRunner {

    @Override
    public TestResult execute(Class<?> testClass, String methodName) {
        TestResult testResult;
        ArquillianTestMethodExecutionListener listener = new ArquillianTestMethodExecutionListener();
        try {
            final AtomicInteger matchCounter = new AtomicInteger(0);
            Launcher launcher = LauncherFactory.create();
            launcher.registerTestExecutionListeners(listener);
            LauncherDiscoveryRequest request = LauncherDiscoveryRequestBuilder.request()
                    .selectors(DiscoverySelectors.selectClass(testClass))
                    .configurationParameter(ArquillianExtension.RUNNING_INSIDE_ARQUILLIAN, "true")
                    .configurationParameter("junit.jupiter.extensions.autodetection.enabled", "true")
            ...

but .. does not work .. so far.

The idea behind is - when test lifecycle is under control, Arquillian-core.JUnitJupiterTestRunner.execute will also properly return TestResult (already does actually, but no observer sees it currently ..)

So the question, dear important project owner/member @bartoszmajsak, how do you see this mentioned pattern above - is it right or wrong direction? If right, pretty please, give some opinions how to continue. Thank you.

[aminchegeni]

Hi every one
I'm happy to announce that after 2 days of debugging I finally found the problem.

The problem lies in 'insideArquillian' property when set to true in JUnitJupiterTestRunner class and it's execute method.

When I change this value manually in debug mode, the junit5 test cases pass.

Mr. @bartoszmajsak can you tell us how to change this property value and which side effect after change may be occurred?

[aminchegeni]

Result of running transactional-junit5.zip attached.

[lemano]

Hello.

Specially @abregar, I saw that you did an extensive investigation effort on this topic. I'm also facing the exact same problem and not being able to run my tests on the arquillian deployment.
From what I read there was no conclusion reported from you.
Did you or anyone had been able to run it successfully, with dbUnit as well? if so can you provide some more insights on how to?

Thanks

[abregar]

Well, long story short, at the time - reverting above mentioned commit in arquillian transaction extension and keeping the JUnit4 tests instead of Junit5 did the trick for me and no further effort was put into this topic after.

[TheOnlyAl]

Hi there.

since i really believe this is a problem in arquillian-core i opened another ticket: arquillian/arquillian-core#539

I also created a small project which provides a workaround for this problem: https://github.com/TheOnlyAl/arquillian-junit5-container-testresultfix

Maybe this helps with a fix in the future. :)

[mann-ed]

I'm working on the junit 5 update to dbunit i need to clean up a few more things before the pull request is accepted. I was just checking in here to see if APE is going to be updated to junit 5 and also Jakarta. I had started the work on my local and ran into issues with tests that rely on other parts of arquillian. It's been a few weeks since i last ran the tests, but it has something to do with jakarta and arquillian dependency projects still having old version of things. I can get more details if needed.

Anyway. I wanted to know if it would be preferred to have all the projects that needed jakarta specific updates to be separated out into their own projects with jakarta in the name?

I had planned on update flyway as well, but will roll that back and just focus on jakarta and dbunit. Will do it after this stuff is done.

Feedback on the jakarta package name welcomed.

[mann-ed]

@bartoszmajsak Not sure if you are still up for working and assisting with this project?

I have updated the code to work with Jakarta and junit 5 -> https://github.com/mann-ed/arquillian-extension-persistence/tree/2.0.0.Jakarta

I have a wildfly/galleon/eclipselink/postgresql/postGis application working with this fork of mine. It now seeds the database and all tests are working as expected. I can make a small demo app for anyone that would want to try it out. However right now it will take some effort to be used. Keep reading.

Please see commit message for things i know are not working. (mann-ed@c8af243)

I am finalizing the dbunit update i have been working on. I have the build passing (https://gitlab.com/dbUnit/dbunit-extension/-/pipelines), just need to investigate why tests that passed before started failing with my changes. I say that because this branch right now is using the SNAPSHOT of dbunit 3.0.0. You will need to build and deploy local if you want to try this out.

I hope this gets people interested again in updating APE. I will continue to work on it as i have time.

[guilhermestella]

@mann-ed as you said, your latest commit has broken tests, but it gracefully compiled and fixed my projects problem. One thing that I have to point out is that I didn't change the dbunit dependency version. I kept it 2.8.0 (current stable).

To give more context, my problem was that when I added the persistence extension, the tests were being ignored (with false positive).

Again, thanks for the commit @mann-ed. Btw, when do you plan to release it?

<dependency>
  <groupId>org.jboss.arquillian.junit5</groupId>
  <artifactId>arquillian-junit5-container</artifactId>
  <version>1.8.0.Final</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.jboss.arquillian.protocol</groupId>
  <artifactId>arquillian-protocol-servlet-jakarta</artifactId>
  <version>1.8.0.Final</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.wildfly.arquillian</groupId>
  <artifactId>wildfly-arquillian-container-managed</artifactId>
  <version>5.0.1.Final</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.arquillian.ape</groupId>
  <artifactId>arquillian-ape-sql-container-dbunit</artifactId>
  <version>2.0.0-SNAPSHOT</version> <<<< with ur commit
</dependency>

[mann-ed]

@guilhermestella I'm glad this worked for you, sorry it took me a while to reply. I'm not in charge of releases. I tagged @bartoszmajsak and have not heard anything back. I would like a release as well so i don't need to build and deploy to my own maven repo. I'm thinking a new major version and Alpha1 release.

My hope is by the end of next month the DBUnit updates i did are pushed, there should be a new 3.0.0 release of it soon.
I'll update to that. I also was looking at updating flyway, however i don't want to push to much into my fork so it drifts further from master repo.

Thanks.