[jboss-as7-dev] Default Configuration Namespace

[Brian Stansberry]

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


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat