jboss as7 inconsistent expression support

Lukas Krejci lkrejci at redhat.com
Fri Dec 14 20:16:40 UTC 2012


>From what I heard on the AS meeting, their new fancy annotation-driven model 
should deal with this by automatically adding such support to all properties.

So it's only going to take another rewrite of all the subsystems (or at least 
their parsing/persistence layer) to get this ;)

On Friday, December 14, 2012 14:35:44 John Mazzitelli wrote:
> forwarding from the jboss-as7-dev mailing list - I've noticed (and wrote
> some JIRAs) on AS7.1.1.Final not supporting expressions where I think they
> should (or where they have in the past with AS 4 config settings).
> 
> Looks like they are trying to open it up so the vast majority of attributes
> accept expressions (at least, that's how I interpret this thread).
> 
> ----- Forwarded Message -----
> From: "Brian Stansberry" <brian.stansberry at redhat.com>
> To: jboss-as7-dev at lists.jboss.org
> Sent: Friday, December 14, 2012 2:20:58 PM
> Subject: Re: [jboss-as7-dev] inconsistent expression support
> 
> 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
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list