Re: [jboss-as7-dev] inconsistent expression support
One problem is that AbstractSubsystemBaseTest, out of the box, just tests the MODEL part,
and not the RUNTIME part of the operation handlers, and quite often these problems only
appear in RUNTIME. It is little used but subsystem-test allows you to test the RUNTIME
part as well, an example is in ModelControllerMBeanTestCase which installs the other parts
of the model, extra services and other bits and pieces required for the subsystem's
runtime to work in its ModelControllerMBeanTestCase.BaseAdditionalInitialization. There
are also some examples in subsystem-test itself, and might be others in other subsystems.
Of course, for some subsystems there might be quite a lot to set up which is why I've
not been stricter about this.
To 'improve' the affected tests using AbstractSubsystemBaseTest to also cover
runtime, one can override AbstractSubsystemBaseTest.createAdditionalInitialization() to
return a proper setup for services to run. Although since that starts three controllers,
which might cause port conflicts, it might be better to use something more similar to what
ModelControllerMBeanTestCase does, which extends AbstractSubsystemTest directly.
On 13 Dec 2012, at 15:46, Jeff Mesnil wrote:
On 12/13/2012 09:56 AM, Heiko Braun wrote:
>
>
> opening up the configuration to support expressions all over the place is desirable,
but I wonder how far away we are from actually supporting it. We've been very
restrictive in the console with using expressions, now we support it by default on all
attributes. This is what happens:
>
> https://issues.jboss.org/browse/AS7-6154
>
> I wonder how we can actually verify full expression support, apart from simply
declaring support in the meta data. IMO it would require to iterate over the current stock
config and replace all occurrences of attributes that declare support for it with a
default expression.
That's what I did for the messaging subsystem. I used expressions in the subsystem
XML tests for every attributes that are now
allowing them.
I found a few bugs like yours doing that but that was not enough.
Another thing was to check during XML parsing for STRING attributes. Some have their
value set and not parsed using
AttributeDefinition.parseAndSetParameter() or ParseUtils functions. This results in a
STRING ModelType (a literal
"${exp:default}") while it must be an EXPRESSION instead.
I had also to fix a few calls at runtime where the attribute value was not fetched using
AttributeDefinition.resolveModelAttribute() and the expression was not resolved.
These errors occurs at runtime and were easy to miss (I may not have found all of them).
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
---------------------------------------
Kabir Khan
Prinicipal Software Engineer
JBoss by Red Hat