[jboss-as7-dev] Default Configuration Namespace

Wed Sep 28 14:30:30 EDT 2011

+1 - I just really wanted agreement we should be checking, the changes I 
am making are to ensure we are handling multiple schema versions cleanly 
so I think this should be in before end users have a chance to start 
mixing and matching schema versions as fixing it later could become a 
backwards compatibility issue.

Regards,
Darran Lofthouse.

On 09/28/2011 07:24 PM, Brian Stansberry wrote:
> +1, although if you are going through this code, it's not a bad time to
> fix it.
>
> On 9/28/11 1:14 PM, David M. Lloyd wrote:
>> We ought to be quite strict; we should be checking on every element.  If
>> we're not doing so right now though, I'd say it's not our #1 problem.
>>
>> On 09/28/2011 01:03 PM, Darran Lofthouse wrote:
>>> One more question ;-)
>>>
>>> How strict do we want to be on the elements below say host, domain and
>>> server?
>>>
>>> At the moment we check the namespace at the root element but after that
>>> we don't really check the namespace so nothing to prevent an end user
>>> trying to mix and match schema versions even though the schema don't
>>> support it.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>> On 09/28/2011 05:00 PM, Darran Lofthouse wrote:
>>>> Thanks Brian.
>>>>
>>>> Yeah thinking further I think option 3 would possibly make more sense
>>>> when the first digit of the schema version is updated, at the moment we
>>>> are updating the second digit so option 1 is probably sufficient for that.
>>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>>
>>>>
>>>> On 09/28/2011 04:38 PM, Brian Stansberry wrote:
>>>>> Go with 1.
>>>>>
>>>>> We can always go with 3 later if it proves necessary, but I don't think
>>>>> the effort is justified at this point.
>>>>>
>>>>> On 9/25/11 3:33 PM, Darran Lofthouse wrote:
>>>>>> Working on this issue (AS7-1923) so far the biggest task I see is
>>>>>> ensuring namespace handling in StandaloneXml.java, DomainXml.java,
>>>>>> HostXml.java and CommonXml.java
>>>>>>
>>>>>> Firstly I think consistency across the files I listed is essential so
>>>>>> whichever approach we choose I will ensure is implemented across these
>>>>>> files.
>>>>>>
>>>>>> Generally I see these options for handling multiple versions: -
>>>>>>
>>>>>> * 1 - Switch statement on version and duplicate parsing. *
>>>>>>
>>>>>> Here I would see each readElement type method with a switch on the
>>>>>> schema version, the attribute and element parsing would then be version
>>>>>> specific so no further version specific checks would be needed for that
>>>>>> version.
>>>>>>
>>>>>> The biggest disadvantage of this would be duplication of code where
>>>>>> complex type definitions have only minor changes, where they are
>>>>>> identical the same code could handle mutliple versions.
>>>>>>
>>>>>> The main advantages would be ease for commiters to verify old schema
>>>>>> parsing not inadvertently updated by a change and easier to map code 1:1
>>>>>> to exact schema version.
>>>>>>
>>>>>> * 2 - Leave entire implementation based on V1.0 with specific checks for
>>>>>> updates *
>>>>>>
>>>>>> Here everything remains written in terms of version 1.0 but as changes
>>>>>> are made for subsequent versions we just add version checks at the
>>>>>> points where updates are made to the schemas e.g. for new elements /
>>>>>> types or removed types.
>>>>>>
>>>>>> This keeps us with the least duplication as the version checks are at
>>>>>> exactly the points where they are required.
>>>>>>
>>>>>> The down side I see here is for longer term maintenance, if you are
>>>>>> going to work on a bug in existing parsing code you will need to review
>>>>>> every schema we support to ensure the one block of code is compatible
>>>>>> with them all.  If in the future we wanted to deprecate or remove old
>>>>>> versions I think this approach could lead to having to re-write all the
>>>>>> classes I listed to re-base on a new base version and take into account
>>>>>> the subsequent versions or risk a build up of dead code.
>>>>>>
>>>>>> * 3 Duplicate the *Xml.java classes *
>>>>>>
>>>>>> When the version of the xsd is switched all parsing will be in terms of
>>>>>> the new schema so we don't need to support the version switching
>>>>>> mid-parse (although we should still detect to ensure it doesn't happen)
>>>>>> - if we created version specific classes each version will be completely
>>>>>> isolated.
>>>>>>
>>>>>> At this stage unless bugs are reported there should be no further
>>>>>> updates to 1.0 parsing as we move to 1.1 parsing.
>>>>>>
>>>>>>
>>>>>> Any other thoughts?  Personally for longer term maintenance I would
>>>>>> think options 1 or 3 even with the code duplication.
>>>>>>
>>>>>> Regards,
>>>>>> Darran Lofthouse.
>>>>>>
>>>>>>
>>>>>> On 09/23/2011 03:30 PM, Darran Lofthouse wrote:
>>>>>>> Anyone mind if I make these changes?  My next changes are dependent on
>>>>>>> being on the next version of the schema.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Darran Lofthouse.
>>>>>>>
>>>>>>>
>>>>>>> On 09/23/2011 03:03 PM, Brian Stansberry wrote:
>>>>>>>> We should shift the 1.1 as the default and the marshallers should write
>>>>>>>> the latest.
>>>>>>>>
>>>>>>>> On 9/23/11 8:57 AM, Darran Lofthouse wrote:
>>>>>>>>> Also one more question.
>>>>>>>>>
>>>>>>>>> Which version should the server now be writing when the configuration is
>>>>>>>>> persisted?
>>>>>>>>>
>>>>>>>>> Do we have a policy for everything to write using the latest schema
>>>>>>>>> version or are we going to be trying to use the version specified until
>>>>>>>>> new elements/attributes are encountered?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Darran Lofthouse.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 09/23/2011 02:33 PM, Darran Lofthouse wrote:
>>>>>>>>>> Now that 7.0.2 is out and the only subsequent planned releases are for
>>>>>>>>>> 7.1 can we switch the namespace for all default configuration to
>>>>>>>>>> 'urn:jboss:domain:1.1'?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Darran Lofthouse.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> jboss-as7-dev mailing list
>>>>>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>>> _______________________________________________
>>>>>>>>> jboss-as7-dev mailing list
>>>>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jboss-as7-dev mailing list
>>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>
>