[jboss-as7-dev] Default Configuration Namespace

[Brian Stansberry]

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


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat