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

We store the history of the file; you're not hosed. Trying to have every extension track every change that's made to see if it introduces something not supported will be a bug fest. Imagine the doc is version 1.0 and the default is up to 2.2. Even for 1.1 it would be likely bug fest. On 9/23/11 9:01 AM, Jason T. Greene wrote: > Thanks for reminding me of this problem. We need to do the latter, but > we are unfortunately doing the former. The problem this causes is that > if you upgrade to a patched release of AS, and then you deploy > something, and then decide you need to revert back you are hosed. The > deployment triggered a write to the config, which now has too new of a > version. > > 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 > >

Thanks for reminding me of this problem. We need to do the latter, but we are unfortunately doing the former. The problem this causes is that if you upgrade to a patched release of AS, and then you deploy something, and then decide you need to revert back you are hosed. The deployment triggered a write to the config, which now has too new of a version. 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

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

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

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

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

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

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