[wildfly-dev] Management Parser Versioning

Tue Apr 28 12:33:17 EDT 2015

On 28/04/15 17:18, Brian Stansberry wrote:
> Thanks. That test is specifically checking that the standard configs are
> using the latest xsd, so yeah, it will fail whenever a core snapshot
> bumps the xsd versions. I was hoping it was some static thing we could
> make smarter, but it seems not.
>
> A hack would be to make the test more lenient if system prop
> version.org.wildfly.core ends with "-SNAPSHOT". The PR to update core
> would still need to fix the full configs, but that's less of a problem.

I think this is going to be a rare issue, an early tag of core should be 
sufficient to cover this.

> On 4/28/15 10:44 AM, Darran Lofthouse wrote:
>> StandardConfigsXMLValidationUnitTestCase - I have not dug into why it is
>> failing but when I update all configs to use version 4 it is back to
>> passing.
>>
>> On 28/04/15 16:23, Brian Stansberry wrote:
>>> On 4/28/15 10:04 AM, Darran Lofthouse wrote:
>>>> The following commit covers the WildFly side: -
>>>>
>>>> https://github.com/darranl/wildfly/commit/8fc073eb11b71904d6235381ad2d3903ce3241aa
>>>>
>>>> One problem with the current split is that as soon as you add a new
>>>> management schema to core the integration with wildfly is broken
>>>> immediately as some tests verify we write as version 3 when now we write
>>>> as version 4.
>>>>
>>>
>>> What tests?
>>>
>>> If full tests are validating core concerns, we need to move that
>>> validation to core, or drop it if it is redundant.
>>>
>>>> I would suggest that as soon as we start development on WildFly 10 we
>>>> create a very fast tag or core with just a few changes, probably just: -
>>>>       - Bump to Java 8
>>>>       - This schema version bump in this thread.
>>>>       - Any other build tweaks needed for Java 8.
>>>>
>>>> WildFly can then use the new tag and have the same treatment.
>>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>>
>>>>
>>>> On 27/04/15 17:14, Darran Lofthouse wrote:
>>>>> The following commits are now the end result of the re-factoring to
>>>>> allow a fork on new major versions and also to add version 4.0 of the
>>>>> schema: -
>>>>>
>>>>> https://github.com/wildfly/wildfly-core/compare/f4a07f4e9b41dc59823fea1813f947c67965525a...58faefb1fa830d0193f862da9958b2541aea7dad
>>>>>
>>>>> The changes look extensive but TBH the bulk is just moving of existing
>>>>> code and some duplicate for the fork for 4.
>>>>>
>>>>> I have distinct commits to show the steps taken but the key points are: -
>>>>>
>>>>> # Split out the model specific parsing from CommonXml into smaller
>>>>> implementations, this was to allow CommonXml to remain the common base
>>>>> without still containing version specific parsing.
>>>>>
>>>>> # Rework of ManagementXml to be version based and rework the delegate,
>>>>> the big problem we had was we were looping back on ourselves with static
>>>>> calls which did not cleanly map to versioned implementations.
>>>>>
>>>>> # Moved existing StandalonXml, HostXml, DomainXml, ManagementXml into
>>>>> 'Legacy' parsers and used existing class to load these on-demand.
>>>>>
>>>>> # Forked the legacy parsers to create the version 4 parsers, removed all
>>>>> version handling so a clean start for 4.
>>>>>
>>>>> At this point there is still plenty of parsing code not forked for 4 but
>>>>> TBH those are all relatively stable and rarely change, StandaloneXml,
>>>>> HostXml, DomainXml, and ManagementXml on the other hand have changed for
>>>>> every major version so far.
>>>>>
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>>
>>>>> On 23/04/15 16:37, Darran Lofthouse wrote:
>>>>>> On 23/04/15 16:32, Brian Stansberry wrote:
>>>>>>> I don't think I've ever rejected or even questioned a PR because it made
>>>>>>> a parser tolerant in the way you describe, so I'm fine with being tolerant.
>>>>>>
>>>>>> +1 I think the first two rules are what we need to advertise we support,
>>>>>> after all that is why we have schemas.  The third point is more about
>>>>>> the requirements being placed on the maintainer of the parser so if your
>>>>>> XML does not match the schema the best we say is "It may work, it may
>>>>>> not work and that can change without warning".
>>>>>>
>>>>>>> My only caveat is in no way do we have any commitment to be tolerant. If
>>>>>>> a change is implemented in such a way that the legacy schema parsing is
>>>>>>> tolerant, then it's tolerant for that change. Some other change may not
>>>>>>> be implemented that way and the parsing won't be tolerant. So we'll be
>>>>>>> inconsistent.
>>>>>>>
>>>>>>> I'm sure we're already inconsistent in this regard, so that doesn't
>>>>>>> worry me. The schema defines the rules. If you follow them, you know
>>>>>>> what you'll get. If you break them, maybe it will work anyway, maybe
>>>>>>> not. Our only guarantee if you break the rules is you'll either end up
>>>>>>> with a valid running configuration or we'll fail.
>>>>>>>
>>>>>>> On 4/23/15 10:17 AM, Darran Lofthouse wrote:
>>>>>>>> Thinking about future XML changes, once the parser is forked I think we
>>>>>>>> can also relax how we add new optional attributes and elements to the
>>>>>>>> schema.
>>>>>>>>
>>>>>>>> As I see it our main commitment is: -
>>>>>>>>
>>>>>>>> * XML that is valid according to the schema should parse without error. *
>>>>>>>>
>>>>>>>> I say 'should' as I believe in some cases documentation is relied upon
>>>>>>>> to describe valid combinations.
>>>>>>>>
>>>>>>>> * The XML we write must be valid according to the schema. *
>>>>>>>>
>>>>>>>> Don't see any justification for not following that one.
>>>>>>>>
>>>>>>>> * Parsers can be tolerant to XML that is technically invalid. *
>>>>>>>>
>>>>>>>> e.g. we are not big on enforcing sequence ordering.
>>>>>>>>
>>>>>>>> So lets say we have a release that contains a 4.0 version of the schema
>>>>>>>> I think if in version 4.1 of the schema we add an optional attribute or
>>>>>>>> element we can just add support for that attribute or element to the
>>>>>>>> existing parse method.
>>>>>>>>
>>>>>>>> Of course if the new attribute or element is required then we will need
>>>>>>>> to switch to something version specific to avoid rejecting previously
>>>>>>>> valid configuration.
>>>>>>>>
>>>>>>>> I know this is a long way off but I only raise this now as I realise
>>>>>>>> this has already happened where a new optional element has been added to
>>>>>>>> the schema.  Technically if we were strict about it the code is wrong
>>>>>>>> but the scenarios where it is going to break for someone are quite
>>>>>>>> contrived and I think this fits with tolerant parsing and we will
>>>>>>>> automatically fix on the next write.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Darran Lofthouse.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 22/04/15 13:30, Brian Stansberry wrote:
>>>>>>>>> That's fine with me.
>>>>>>>>>
>>>>>>>>> On 4/22/15 6:20 AM, Darran Lofthouse wrote:
>>>>>>>>>> Working with the parsers for the core config has become increasingly
>>>>>>>>>> cryptic, we are now at the point where we have three different major
>>>>>>>>>> versions which diverge and converge as we work on them.  Most recent
>>>>>>>>>> changes have resulted in large sections of the config converging for 1.x
>>>>>>>>>> and 3.x leaving 2.x independent.
>>>>>>>>>>
>>>>>>>>>> So that I can add references to Elytron I am starting to add support for
>>>>>>>>>> version 4.
>>>>>>>>>>
>>>>>>>>>> One think that I have learned is that each major version tends to belong
>>>>>>>>>> to one branch of the codebase, all changes to that version happen on
>>>>>>>>>> that branch first: -
>>>>>>>>>>
>>>>>>>>>>             1.x - Maintained only for EAP
>>>>>>>>>>             2.x - WildFly 8.x branch
>>>>>>>>>>             3.x - WildFly Core master branch
>>>>>>>>>>
>>>>>>>>>> I would expect if further changes are made to core for WildFly 9
>>>>>>>>>> releases we will end up with 1.x branch of core and and 4.x version of
>>>>>>>>>> the schema will be owned by the master branch.
>>>>>>>>>>
>>>>>>>>>> To make things less cryptic I am proposing that until we find a better
>>>>>>>>>> solution for all subsequent major schema versions we just fork the
>>>>>>>>>> parser and all related classes.
>>>>>>>>>>
>>>>>>>>>> This will simplify the code being modified for the upstream development.
>>>>>>>>>>
>>>>>>>>>> Forward porting parsing changes will also become a simple copy and paste.
>>>>>>>>>>
>>>>>>>>>> For the current cryptic approach I think almost every engineer (and I am
>>>>>>>>>> finding it really hard to think of exceptions) that has worked in-depth
>>>>>>>>>> in this area has introduced at least one bug and I don't think the test
>>>>>>>>>> coverage is high enough to protect against this.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Darran Lofthouse.
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>