[jboss-as7-dev] inconsistent expression support

[Kabir Khan]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

---------------------------------------
Kabir Khan
Prinicipal Software Engineer
JBoss by Red Hat