Re: [jboss-as7-dev] AS config path only as a relative path?
by Brian Stansberry
I didn't see the JIRA, so I'm copying the dev list.
It was removed because the semantic was unclear. Users were expecting to
pass in an absolute file and then have the AS write back to that file.
We're not going to support writing outside the configuration/ dir and
never intended to.
I agree though that completely eliminating this was not the best
solution, as there's a good use case for it. Besides the testing issue,
some folks don't like the AS overwriting the config file in the first
place, so passing in a config file in a non-writable location is a
workaround solution for them.
My thoughts on this were to allow an --initial-server-config (for
standalone) and --initial-domain-config and --initial-host-config (for
domain). They would allow absolute paths. Their names and documentation
would indicate their contents are read when the process is first started
and thereafter are ignored.
On 2/13/12 4:28 AM, Ondřej Žižka wrote:
> I've created a jira for this task,
> let's discuss there.
>
> Thx,
> Ondra
>
>
> Ondřej Žižka píše v Po 13. 02. 2012 v 11:15 +0100:
>> Hi Brian,
>>
>> what was the reason to restrict AS config in sys prop to a relative path?
>>
>> In the testsuite, we would make use of absolute paths.
>> The reason is that we reuse the configs from docs/examples, and they
>> change quite often, so having them in resources would be hardly
>> maintainable.
>> However, docs/examples is not guaranteed to be always in the same
>> place: E.g. for EAP, or for RPM-based installation of EAP it might end
>> up in /var/docs or such.
>>
>> I would like to pass some property from maven to the tests, but that
>> results in absolute path.
>>
>> Thanks,
>> Ondra
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
14 years, 1 month
JBoss code format standard?
by Ondřej Žižka
Hi,
I'd like to enforce some code standards in the testsuite;
however I can't enable checkstyle because most tests would need to be
fixed.
So I want to remind people to follow JBoss standard.
Is it described somewhere?
Thanks,
Ondra
14 years, 1 month
Before adding a new module to AS testsuite...
by Ondřej Žižka
Hi all,
please,
before adding a new module to AS testsuite,
consult with me.
Too many people just copy & paste instead of doing the homework of
finding greatest common denominator with existing modules, and the
testsuite is getting messy.
Consider adding only a surefire execution.
With Surefire 2.12, it won't cause the problems as it did earlier.
Thanks for cooperation.
Ondra
14 years, 1 month
Who was maintaining AS testsuite in previous releases?
by Ondřej Žižka
Hi all,
who (which group of people) were maintaining the AS tetsuite?
All developers? Or few dedicated? Support guys? Or random
passers-by? :)
I'd like to discuss their experience with that, and ideas about how to
make that as easy as possible and how to prevent problems they had.
Thx,
Ondra
14 years, 1 month
FYI - (SUREFIRE-806) Make ignoring of <includes> and <excludes> on -Dtest=... optional (for multiple Surefire executions)
by Ondřej Žižka
Hi all,
Thanks to John Casey, the unwanted behavior of -Dtest=... with multiple
surefire executions in one module is now fixed.
Now it will work as expected: The test will run only in the execution
where it runs in the whole batch.
Also note that besides SUREFIRE-806, Surefire 2.12 (which is now
available in central) also fixes
SUREFIRE-803 - Multiple Failsafe executions - FAILURE in an execution
prevents successive from running.
We have been discussing this earlier.
SUREFIRE-809 - Implement boolean expression to define test group to be
run.
This is great improvement in possibilities of implementing
large test suites in maven.
I haven't found docs yet though.
Regards,
Ondra
-------- Přeposlaná zpráva --------
> Od: John Casey (JIRA) <jira(a)codehaus.org>
> Reply-to: John Casey (JIRA) <jira(a)codehaus.org>
> Komu: zizka(a)seznam.cz
> Předmět: [jira] (SUREFIRE-806) Make ignoring of <includes> and
> <excludes> on -Dtest=... optional (for multiple Surefire executions)
> Datum: Wed, 18 Jan 2012 19:00:03 +0100 (CET)
>
>
> [ https://jira.codehaus.org/browse/SUREFIRE-806?page=com.atlassian.jira.plu... ]
>
> John Casey closed SUREFIRE-806.
> -------------------------------
>
> Resolution: Fixed
> Fix Version/s: 2.12
>
> Created failIfNoSpecifiedTests parameter (-Dsurefire.failIfNoSpecifiedTests and -Dit.failIfNoSpecifiedTests when used from the CLI), which will determine whether test-execution blocks that don't contain one of the tests specified on the command line should fail the build or not. Default is to fail the build.
>
> Also, in cases where there are multiple test execution blocks, to avoid running a specified test in the wrong block, the existing includes/excludes are now honored...the specified tests now act as a refining filter on these includes/excludes. This means that in cases where there are multiple test-execution blocks, you cannot run a test that wouldn't ordinarily be run by just using -Dtest=... any more.
>
> In cases where there is only a single test-execution block, the specified tests should override the includes as before.
>
> I also added three new integration tests to verify all of this behavior.
>
> > Make ignoring of <includes> and <excludes> on -Dtest=... optional (for multiple Surefire executions)
> > ----------------------------------------------------------------------------------------------------
> >
> > Key: SUREFIRE-806
> > URL: https://jira.codehaus.org/browse/SUREFIRE-806
> > Project: Maven Surefire
> > Issue Type: Improvement
> > Components: Maven Surefire Plugin
> > Affects Versions: 2.11
> > Reporter: Ondrej Zizka
> > Assignee: John Casey
> > Fix For: 2.12
> >
> > Attachments: surefire-806-testParam-hits-all-executions.zip
> >
> >
> > Let's have a single module with multiple Surefire executions (e.g. with different Arquillian configs)
> > Tests are divided to run in either one, using <includes> and <excludes>.
> > Then, if you use -Dtest=..., the specified test(s) is run twice - once for each execution (and usually fails in one of them in our scenario).
> > My suggestion is to introduce a Surefire config property which would make this behavior optional:
> > {code}
> > <configuration>
> > <ignoreIncludesOnSingleTest>false</ignoreIncludesOnSingleTest>
> > </configuration>
> > {code}
> > This would cause Surefire to run the intersection of the two sets -
> > one created by the mask from -Dtest=...,
> > second created by the includes and excludes of the respective execution.
> > Current description from http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html :
> > {quote}
> > Specify this parameter to run individual tests by file name, overriding the includes/excludes parameters. Each pattern you specify here will be used to create an include pattern formatted like **/${test}.java, so you can just type "-Dtest=MyTest" to run a single test called "foo/MyTest.java".
> > This parameter overrides the includes/excludes parameters, and the TestNG suiteXmlFiles parameter.
> > {quote}
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
14 years, 1 month
Testsuite simplification - 2nd try to get it merged
by Ondřej Žižka
Hi,
due to 7.1.0 release, the testsuite facelifting merge was postponed.
I'm almost in sync with upstream/master again.
I'd like to get this merged right after the release.
I'd be grateful if someone found few minutes to peek at the changes
(just by sight at the diffs)
https://github.com/OndraZizka/jboss-as/tree/TS-refactor
so I can explain what's going on and prevent misunderstanding.
In a nutshell:
* The changes are not significant - no structure changes.
* What has changed is only the way to build the AS instances, plus few
cosmetic changes.
* The "API" of the testsuite will remain the same.
* The way to write new tests will remain the same.
* The way to add new modules and change AS instances and their config
will be simpler.
Thanks,
Ondra
14 years, 1 month
ACTION REQUIRED: Replace hardcoded URLs and adresses with arquillian resources.
by Ondřej Žižka
Hi,
I'd like to ask everyone to fix "their" tests regarding $SUBJ.
E.g. this is not acceptable:
ModelControllerClient client =
ModelControllerClient.Factory.create(InetAddress.getByName("127.0.0.1"),
9999, getCallbackHandler());
or
MBeanServerConnection mbeanServer = JMXConnectorFactory.connect(new
JMXServiceURL("service:jmx:remoting-jmx://127.0.0.1:9999")).getMBeanServerConnection();
Such like these MUST be rewritten to fetch the addresses and ports from
an injected @ArquillianResource.
Here's a tracking jira: https://issues.jboss.org/browse/AS7-3696
Empty so far. Next week, I'll start going through the tests looking for
such cases, and fixing them. Or, creating jiras and assigning them to
the test authors.
That's why I hope this call to action will relieve me from most of that
tedious work :)
Thanks for cooperation.
Ondra
14 years, 1 month
Fwd: Re: [jbossas-pull-requests] [jboss-as] JBQA-5902 - EJB client reconnection tests for AS7-3215 (#1477)
by Jaikiran Pai
Hi Aslak,
Does Arquillian allow individual tests to use a different
arquillian-config.xml if necessary? We are trying to reduce the number
of Maven modules, each using its own arquillian-config.xml in AS7
testsuite. It's related to this pull request
https://github.com/jbossas/jboss-as/pull/1477
-Jaikiran
-------- Original Message --------
Subject: Re: [jbossas-pull-requests] [jboss-as] JBQA-5902 - EJB client
reconnection tests for AS7-3215 (#1477)
Date: Thu, 9 Feb 2012 21:03:46 -0800
From: Jaikiran
<reply+i-3155949-75ad493488d00c4d1d72fea8559468b5bfdbd343-939955(a)reply.github.com>
Reply-To: jbossas-pull-requests List
<jbossas-pull-requests(a)lists.jboss.org>
To: jboss-as-pull-request <jbossas.github.pullrequest(a)gmail.com>
>> This test needs a manual mode of Arquillian container, hence it introduces a new maven module 'manualmode' under>> the testsuite/integration module.
Let me check with Aslak if there's a way for individual tests to specify a different arquillian-config.xml. That way we won't require a new maven module for this.
>>The new maven module can be used by everyone for other tests that need to manually control the server.
I'm not so sure. Because we currently already have a module for clustering where servers are started manually. However that cannot be reused for this test or other tests because of the specific configurations it starts the servers with. I believe we are going to run into similar cases where the tests would need to start the server manually but with different configurations for the server. So I guess the easier way to do this would be to allow the tests to specify the arquillian-config.xml that they want to use (if at all that's possible).
---
Reply to this email directly or view it on GitHub:
https://github.com/jbossas/jboss-as/pull/1477#issuecomment-3901289
_______________________________________________
jbossas-pull-requests mailing list
jbossas-pull-requests(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests
14 years, 1 month