Testsuite grouping: Splitting to many modules, or something different?
by Ondřej Žižka
Hi everyone interested,
there are these motivations for grouping the tests:
1) Splitting tests by functional area, e.g. jms, jacorb, cmp.
2) Splitting tests by purpose, e.g. smoke, basic, stress etc.
3) Running tests with different configs.
4) Running various groups of tests.
4) can be done using e.g.
-Dtest=org.jboss.as.test.integration.ejb.*TestCase.java (provided -Dtest
works fine), so I'll drop it from further considerations).
1-3) is currently done by a combination of modules and Surefire
executions.
The problem with the later is that a failure in one execution prevents
the successive from running.
Here are options how that can be solved:
A) Naive solution: Keep status quo, keep tests in the first execution in
a good condition.
Pros: * We already have it.
Cons: * It will fail now and then, and people would need an extra run
for the other group, using various params.
B) Megalomanic solution: Make every combination a maven module.
Pros:
* Avaliable right away.
Cons:
* Will result in many modules - e.g. smoke-web, smoke-full, basic-web,
basic-full, ...
* => much harder to maintain, esp. for the product features (need to
distribute stuff to too many pom.xml's).
* Slower testsuite and AS7 build.
* Would not scale for the cases when each test needs a different
config.
C) Optimistic engineer's solution: Use JUnit's new @Category and
Arquillians ability to restart a server with other config, based on
@ContainerConfig("path-to-config.xml").
Pros:
* Simple, clean approach; no pom.xml hell.
* Easy to maintain.
* Easy to reorganize later.
* Would get 3) and 4) out of maven
Cons:
* Arq's impl of @Category is not tested
* We would need to put @Category to all tests
* @ContainerConfig("path-to-config.xml") is not implemented. We could
(mis)use @TargetsContainer and @OperatesOnDeployment.
Are there others?
Did I miss some pros or cons?
Which one do you like?
Ondra
13 years
TransactionTimeout annotation support
by Alexey Makhmutov
Hi.
I have some questions regarding support for configurable transaction timeouts for CMT beans. The documentation currently describes 'TransactionTimeout' annotation (https://docs.jboss.org/author/display/AS71/EJB+3+Reference+Guide#EJB3Refe...), however my tests shows that specifying this annotation makes no difference in server behavior. I wasn't able to find a JIRA issue for this item and I wasn't also able to find a part of code in jboss-as which supports it. So, I've played with code a little and made a straightforward implementation to support this annotation, mostly copying logic of 'TransactionAttribute' processing code: https://github.com/Lerm/jboss-as/commit/b08acb408d722d3026df25bf54b57d271...
So, my questions are following:
1. Is it true that 'TransactionTimeout' annotation isn't supported as for now or did I missed something?
2. If it's not supported, then is there some JIRA request for it?
3. Is it worth to continue working on this fix to add it to main code stream?
Thanks,
Alexey Makhmutov
13 years
Testsuite -Dtest
by Kabir Khan
It seems the latest commit to the testsuite now breaks the ability to do
cd testsuite/integration/smoke
mvn clean install -Dtest=org.jboss.as.test.smoke.embedded.parse.ParseAndMarshalModelsTestCase
13 years
Update on Pull Request Process
by Jason T. Greene
Hi Everyone,
As I mentioned in an earlier email I have developed some custom testing
automation for pull requests that should result in a faster
request->merge timeline.
As of yesterday, when you submit a pull request, provided that you are
in our whitelist, a full testsuite run of your patch against the current
recent master will automatically be kicked off on a new AS test server.
Note, this means that if you submit an out of date pull (not that you
should), the system will automatically merge it before running the
testsuite. Keep in mind this could lead to different results than your
local run since its a potentially different version (e.g. we merge a
different patch before you merged yours). So the first thing to do when
that happens is to rebase and try and produce the failure locally.
If you do not see this happening, it's probably because you are not in
the whitelist, in which case you will be added after an extra initial
code review.
Once the results are in they will posted as a comment which will send an
email notification to you (and the pull mailing list) with the results
and outcome. Please look these over and correct any issues/regressions
your patch may cause. Unfortunately this server is only visible to Red
Hat associates at this time, so if you are an external contributor and
would like the report just grab someone who is on IRC or make a note in
the pull request and we will send you a copy. In the future we will look
into a way to aggregate the information onto a community site.
At any point in time you update your pull request (add a commit, or
rebase it again) the system will kick off another run. It will not
however kick off additional runs if there are no other changes (would
generate way too much noise and load). When the patch is merged the
person doing the push still needs to do a manual verification due to
this reason.
Finally, we are still working on the intermittent issues in the
environment, so if you get a failure, you may want to compare it to
other runs. The goal of course is to eliminate this problem ASAP.
Thanks
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
13 years
[Sorry!] Pull Request Spam
by Jason T. Greene
You may have noticed a great deal of pull request emails coming in with
links to builds. I am working out the kinks in some pull request testing
automation I recently developed.
Bare with me.
Also note that if you see failures linked to your request. that in this
environment we have a couple intermittent failures. We are looking into
those.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
13 years
Getting on the same page with @Clustered @Singleton
by Radoslav Husar
Hi guys,
I just want to sync up with everyone what's the plan on EE6's @Singleton
running on multiple JVMs in 7.1*.
There is a common misconception that @Singleton is acting at cluster
level. This is nay. The EE spec says:
A Singleton session bean is a session bean component that is
instantiated once per application. In cases where the container is
distributed over many virtual machines, each application will have one
bean instance of the Singleton *for each JVM*.
However the concept of @Clustered @Singleton where there is only 1
failure-resistant bean instance within the cluster replicating state
does make a lot of sense. Having to sync on the persistence level sounds
dreadful. In one sense it is the successor of AS 5's singleton-ha which
was deployment-level mechanism.
Is is possible to have this even though it is kind of violating the EE spec?
David is requesting to fail the deployment of such:
https://issues.jboss.org/browse/AS7-2887
Does it mean that we wont have it in 7.1? Maybe later?
Cheers,
Rado
* EAP 6.0
--
Radoslav Husar
JBoss QE
13 years
