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

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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > -- Brian Stansberry Principal Software Engineer JBoss by Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev