[jboss-as7-dev] Default Configuration Namespace

Wed Sep 28 14:14:21 EDT 2011

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

-- 
- DML