Let's clean out the smoke testsuite
by Brian Stansberry
I've touched on this topic before, but now I'd like to propose an action
item for fairly early in AS 8 work.
Let's get most, if not all, of the stuff in testsuite/integration/smoke
out of there and into testsuite/integration/basic.
Why? Because leaving it in smoke just wastes time to little benefit.
When is the last time you did some work, ran ./build.sh install before
submitting a pull request, and a smoke test failure told you you had a
problem? (Let's exclude any brand new smoke test you added as part of
the patch, since presumably a good engineer would run the test whether
or not it was in smoke.)
For me it has probably been at least a year. All the smoke tests are
doing for me is adding time to a standard build.
A separate, limited-in-order-to-run-fast set of smoke tests was
important in the AS < 7 days when devs would often only run the smoke
tests and then commit directly to SVN. Now the full testsuite always
gets run for any patch at least once and normally 3 times before it gets
merged.
To be clear -- the suggestion is to move these tests, not to drop them.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
11 years, 11 months
as7-master-testsuite-ip6 - Build # 6928 - Failure!
by ci-builds＠redhat.com
as7-master-testsuite-ip6 - Build # 6928 - Failure:
Check console output at to view the results.
Public: http://hudson.jboss.org/hudson/job/as7-master-testsuite-ip6/6928
Internal: http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...
Test summary:
4 tests failed.
REGRESSION: org.jboss.as.test.manualmode.web.valve.WebDescriptorValveTestCase.testWebDescriptor
Error Message:
There was one valve defined - it's missing now expected:<1> but was:<2>
REGRESSION: org.jboss.as.test.manualmode.web.valve.WebDescriptorValveTestCase.testValveOne
Error Message:
There were two valves defined expected:<2> but was:<3>
FAILED: org.jboss.as.test.manualmode.web.valve.authenticator.GlobalAuthenticatorTestCase.authWithStandardValve
Error Message:
java.util.concurrent.ExecutionException: Operation failed
FAILED: org.jboss.as.test.manualmode.web.valve.authenticator.GlobalAuthenticatorTestCase.cleanUp
Error Message:
java.io.IOException: JBAS012175: Channel closed
11 years, 11 months
Attribute meta-data: max-length
by Heiko Braun
We have the case within the UI that the client needs to distinguish text input types. I most cases a simple text inout is sufficient, but in some cases a text area is more appropriate (i.e. datasource>new connection sql). I am wondering, if the max-length attribute could be used for it.
It's currently tight to ModelType.STRING, which is fine.
In order to show the expected results, we would need to decrease the default value for max-length, to something smaller (245, 1024). This way we could provide text input for for anything below that size and text area for anything else.
Some implications I would like to hear your thoughts about:
a) lowering the default max-length might break your subsystem and/or specific clients
b) keeping the current default and doing it case-by-case will result in text input (opposed to text area) for all String attributes once we switch to a dynamic UI (usability drawback).
Regards, Heiko
11 years, 11 months
