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.
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/8fc073eb11b71904d6235381ad2d390...
>>
>> 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/f4a07f4e9b41dc59823fea181...
>>>
>>> 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(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev