[jboss-as7-dev] Default Configuration Namespace

[Darran Lofthouse]

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