[jboss-as7-dev] Default Configuration Namespace

Darran Lofthouse darran.lofthouse at redhat.com
Wed Sep 28 12:00:54 EDT 2011


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
>
>

-- 
Darran Lofthouse - Principal Software Engineer

Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)


More information about the jboss-as7-dev mailing list