[wildfly-dev] Logging Model Changes and Questions

[James R. Perkins]

On 07/01/2013 02:58 PM, Brian Stansberry wrote:
>
> I don't see much benefit in B vs having 2 attributes,
> "pattern-formatter" and "custom-formatter", with the current "formatter"
> just an alias for "pattern-formatter.format-pattern".
>
> With a single "formatter" in B the attribute description is going to
> have to describe how in the complex attribute there are two possible
> keys "pattern" and "custom", only one of which is valid at a time. A
> client is then going to have to figure out which of the two a given
> response includes and parse accordingly.
>
> Your option B really looks more like you have a child resource type
> "formatter" instead of an attribute, with two legal values for the
> resource name -- "pattern" and "custom".
Excellent points. I think that does make the most sense. The only 
problem I have with it is that there are 3 formatter options, but really 
only one can be uses. Well 2 I guess with the 
formatter/pattern-formatter. I'm probably just be picky and whiny at 
that point though :)
>
>> A model change
>> like this would also require some transformers for backwards
>> compatibility. Though that doesn't really bother me all that much.
>>
> It also breaks any existing clients who are expecting the "formatter"
> attribute to be ModelType.STRING.
Again, good point. I hadn't thought about that part. I'm glad I asked.
>
>
Thanks for the input Brian. It really makes a lot of sense.

-- 
James R. Perkins
Red Hat JBoss Middleware