The exchange attribute parser doesn't handle a string like so:

%{myCustomAttr:%{REQUEST_LINE}}

Let's assume I have a custom attribute builder looking for tokens starting with "%{myCustomAttr:".  instead of being passed the entire string, the parser will call my custom builder with ONLY the text

%{myCustomAttr:%{REQUEST_LINE} 

and then will create a Constant attribute containing the remaining text 

}

which will then get combined into a Composite attribute, which is no good.

This can be fixed quite simply by adjusting the logic in the ExchangeAttributeParser class so it stops assuming that it only needs to look for the NEXT "}" char it comes across, but instead tracks the depth of the curly braces it's inside of such that it iterates until reaching the final MATCHING "}" character.  This will keep the entire top-level attribute together, and more importantly, allows that attribute to accept a string as its input that it can then recursively parse.

I have a couple use cases for this already.  The first is ticket UNDERTOW-2120 to add attributes that can wrap another attribute and apply text transformations such as uppercase or URL decoding.

%{toLower:%{METHOD}}

and a new feature I'm working on to add the equivalent of Apache HTTP's RewriteMap, which would require a new attribute that accepts other attributes.

regex( '^/products/([0-9]*)$' ) -> rewrite( '/products/%{map:productIDs:${1}}' )