[jboss-as7-dev] inconsistent expression support

[Brian Stansberry]

I see 4 levels to this:

1) Convert resources from the coding pattern we had in 7.0 to properly 
use ResourceDefinition/AttributeDefinition. There is only a small bit of 
this left to do, and any addition of expression support we're doing for 
7.2 is being done in the context of this kind of conversion. There can 
still be mistakes made using RD/AD, as AS7-6154 shows, but I believe 
this conversion has decreased the likelihood of bugs a *lot*.

2) The basic subsystem tests that Kabir describes, based on 
AbstractSubsystemBaseTest. Every subsystem should have one of these that 
tests an example config that covers all configuration elements and 
includes expressions for all items where they are supported. I think the 
coverage of these is inadequate, but they are really, really easy to add 
-- just create some xml and add a 1 line test method.

We'll be adding these where missing between now and Jan 8. If you are a 
developer on a subsystem where this coverage is inadequate, please ping 
me, Tomaz Cerar, Kabir Khan, Jeff Mesnil or Emanuel Muckenhuber and 
*volunteer to do this*.

This will cover the round-trip from XML to model and back, which is 
roughly 2/3rds of the problem space.

That leaves the runtime part, ensuring that operation step handlers are 
properly using AttributeDefinition.resolveModelAttribute(context, 
operation). As Kabir noted, it's harder to unit test these because most 
runtime handlers set up services that require complex dependencies.

3) What I'm looking to do for runtime is to start up a host controller 
in admin-only mode using our standard domain.xml. Then iterate through 
all resources, looking for read-write attributes that support 
expressions. Invoke the write-attribute op to set an expression. Then 
reload and confirm that all servers start cleanly. This will cover a big 
chunk.

4) Covering the rest is going to require people updating their 
AbstractSubsystemBaseTest to also cover runtime, as Kabir described. I 
expect this will be a slow process, not something we'll do much on in 
the next few weeks.

But I think the combo of 1, 2 and 3 will leave us in better shape than 
we were in the 7.1 series.

On 12/13/12 10:08 AM, Kabir Khan wrote:
> 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
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat