Re: [jboss-as7-dev] Default Configuration Namespace

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(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>>> _______________________________________________ >>>>>>> jboss-as7-dev mailing list >>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> >> > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev