Could not run @AfterSuite [tiny reproduction project included] #14
Comments
|
I also tried to force servlet 3.0 for the protocol but it didn't change anything. And the relevant XML in the arquillian.xml and I also tried the annotation on the deployment, to no avail. |
|
After adding @overprotocol("Servlet 3.0") to method createArchive i receive error: So I suppose Tomee is not working over Servlet 3.0. You need tomee or you can use different container? If you need tomee i can try finding solution but arquillian is so messed us so it will not be easy.. |
|
Yes we would need tomee... Otherwise you saw the mention in my comment that I don't get such errors when I add the arquillian-protocol-servlet artifact, but you know best, it probably doesn't really help. Unfortunately we develop our application solely on tomee so I cannot substitute testing on any other container. We used to develop with Glassfish 3.1 and your plugin was working great, now we migrated to tomee and I'm attempting to port our tests with some difficulty (not only because of your plugin). It would be a shame if we must give it up but if there is no choice, that's what it is... I can say that developers on the tomee-users forum are very very responsive and I'm sure they'd answer any questions promptly. |
|
(well of course we'll wait if you manage to make it work because we give up ;-) ) EDIT: we'll wait if you manage to make it work BEFORE we give up |
|
I found place where it throws NPE.. And while everything is working as intended.. except error witch is thrown after everything is done in undeploy.. and solution is quite easy (check for null) then it will probably work after they will apply my patch (I still dont know where to submit it tho). Where did you said I will find tomee forum? |
|
I have rebuilt locally tomee-arquillian-common with your fix and in the test program that I made, it's true, I can not reproduce the crash anymore. However I'm not sure that it is the right fix... Because in the real application I still get the same failure. The symptom being that all the tests in the first file that I run work juste fine but at the first in the second file it fails because I inject a UserTransaction as @resource and the injection fails and the test gets it as null. So I think it's a workaround but the root problem is elsewhere (also I think the tomee developer hinted at that in his answer in the bug). I'll check the output in my real program and try to reproduce the failure in the test program but i'm in holidays abroad this week, I'll still try. |
|
Well, I got lucky... I managed to reproduce the problem in the test program easily... https://www.dropbox.com/s/coqw8r40omo96s3/suite-problem-try2.zip?dl=0 I have just slightly modified my test project. So there are now two test files in the test project: NewEmptyJUnitTestIT (as before) and now also SecondTestIT. They both inherit from BaseITTest. In the base class we inject a UserTransaction and have a @before and @after (that's where we clean up our DB and the environment between tests). That is in fact the root problem. I probably should not have attracted your attention to the NPE that you fixed, I guess it was just a consequence of the problem, not the root problem. |
|
Note I have tried two more things on my try2 test program now:
|
|
Its really creazy stuff witch happens inside tomee.. |
|
Wow, great that you didn't give up! Maybe ask them for tips or guidance.. They say that AQ support is very important to them, too... |
|
https://issues.apache.org/jira/browse/TOMEE-1341 Mayby will be possible to fix it. |
|
They already implemented it in trunk and 1.7.x branches. Could you try in real world if it works? |
|
wow, great news! which artifact should I rebuild from git master? is tomee-arquillian-common enough? |
|
tomee-arquillian-common should be enough.. |
|
I've just spent quite some time on this, but I couldn't make it work, I'm still hitting the problem. However I'm almost certain that it's just picking the other tomee version, with the bug... I'm probably not building it from source correctly, or something like that... I think it's probably safe to close this issue for now, I promess to retry it when tomee 1.7.1 or any other version gets out and to reopen the bug, should the problem appear again. |
|
Well, 1.7.1 is out already for some time, I tried on our big project but the suite integration still breaks the tests. Then I tried on the suite-problem-try2 test program from this bug, just changing tomee version from 1.7.0 to 1.7.1, and the tests are still failing. Maybe the fixes were only really taken in the 2.x branch? Or maybe I must change something else from my pom.xml to make it work... But in any case, that's not your bug, but apparently from tomee so I'm not reopening here. |
|
Could you try one more thing? As far as i remember they didnt repaired one thing in startup.. Could you try add to your deployments testable = false? @deployment(testable = false) Mayby this will work.. |
|
If it will not work could you post your log.. |
|
Well I'm literally testing just "suite-problem-try2" which is the reproduction application that I posted on dropbox: The only thing is that I changed the pom.xml to use tomee 1.7.1 instead of 1.7.0. I did try on our real-world big application but it failed, at that point I tried again on the test app, and was surprised to find that also there it didn't work. Actually I get even the first bug that you fixed, that you get a crash when the test finishes "Could not run @AfterSuite". That said, both tests do pass, while in my real-world app, it wasn't like that, I was getting errors because the SQL connection (to the test in-memory derby DB) wasn't set up. I see literally the same stack as the one I posted at first in this bug, which makes me wonder whether I'm really testing against 1.7.1. I wiped my .m2 just in case, but that's what I see no matter what... |
|
note there I saw a relevant thing: "You can also use one of the arquillian suite extensions but you can get issues with the container adapter (IIRC you need TomEE trunk/1.7.2 at least) " so that might confirm that it's expected NOT to work with 1.7.1. |
|
@ingwarsw I ran into this issue today with Karaf, and it appears to have changed to a different area with the @overprotocol annotation. I am not entirely sure if it is relevant to these issues (forgive me if it is not, please) but why does the suite deployment extension require wars or ears? Is, or will there be, an option for regular bundles/jars? |
|
@Steve973 Mayby I dont understand trully, but as far as i know war or ear is needed to run code on application server.. |
|
@ingwarsw It depends on what kind of application server we are talking about, or at least what kind of container we are dealing with. Arquillian provides the ability to run tests in a variety of containers, as you know, and the container that I am using is Karaf. If you are not familiar with Karaf, it is a platform that runs the equinox or felix (both are OSGi spec implementations) framework as its base, but it extends a good bit beyond those, feature-wise. If you are new to OSGI, a decent introduction is at http://javajee.com/what-is-osgi-and-how-apache-felix-apache-karaf-equinox-knopflerfish-virgo-blueprint-and-pax-exam-are A deployment to Karaf (or any OSGi container) consists of JAR files (called "bundles) that include specific manifest headers that tell the container how to present them to other bundles that are present in the container. So I really need the suite behavior to be able to test my bundles, because some of my projects contain both arquillian tests and also non-arquillian integration tests. If an arquillian test runs first, followed by a non-arquillian integration test, then the arquillian deployment times out, and my tests fail, even if they really passed. Would it be possible to use the suite capability with a jar? |
|
Could you open new issue with suggestion and some kind of project on with I could reproduce your behavior? By the way new Arquillian should not support suites by it self? |
|
Do you mean 1.1.11? I didn't see anything about test suites in that On Tue, Apr 19, 2016 at 5:57 AM, Karol Lassak [email protected]
|
|
Here is discussion: http://discuss.arquillian.org/t/arquillian-core-suite-subsuite-how-to-define-the-suite/163/28 I was almost sure its already done.. but as far as i see its not.. but work is in progress.. |
I have a project where when I don't use the arquillian-suite-extension, things work fine. But when I add it, after a run on a single test class, there is an error in the maven output (see the end of this comment). If I run the test on several classes, then the other tests are broken, even injection doesn't work, I think it's because of that exception already at the end of the first test class.
I reproduced the problem in a small demo project, which is really minimal. There are no prerequisites to run it, since it uses an embedded container (so maven will download everything). Keep in mind to use the tomee-embedded maven profile for the test.
I have an AQ test in NewEmptyJUnitTest. When run as it is in the source now, the problem will show. If I comment in the pom.xml the arquillian-suite-extension dependency, remove the @OperateOnDeployment("derby") and uncomment the createArchive() then the test runs fine.
https://www.dropbox.com/s/nai80xk1x26xetr/suite-problem.zip [7.7kb]
Thank you!
The error after the test run is (giving the output from maven -e which gives more details):
The text was updated successfully, but these errors were encountered: