3:29 a.m.
Hi,
I am working on a JIRA issue to add missing configuration parameters to
messaging resources[1]
I did a quick patch to unblock the performance teams but I am revisiting
it to fix it properly[2].
As I am changing the XSD schema, I need to bump up its version.
My changes are small (I'm just adding elements) but I wonder what the
policy to manage schema changes is.
* should I be able to read any previous configuration version? or only
the last 2?
* if I am reading an old configuration version, should I persist it at
the same old version or the latest version?
I looked at ejb3 subsystem to see how configuration schemas are handled.
Is it a good candidate to copy?
thanks,
jeff
[1] https://issues.jboss.org/browse/AS7-4330
[2]
https://github.com/jmesnil/jboss-as/commit/2f4389a10fe61bd054a5e4729ae8c6...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
4:18 a.m.
On 2 Apr 2012, at 09:29, Jeff Mesnil wrote:
Hi,
I am working on a JIRA issue to add missing configuration parameters to
messaging resources[1]
I did a quick patch to unblock the performance teams but I am revisiting
it to fix it properly[2].
As I am changing the XSD schema, I need to bump up its version.
My changes are small (I'm just adding elements) but I wonder what the
policy to manage schema changes is.
* should I be able to read any previous configuration version? or only
the last 2?
Old versions of the schema should be readable and converted into
whatever ops your subsystem currently takes
* if I am reading an old configuration version, should I persist it
at
the same old version or the latest version?
We persist as the latest version
I looked at ejb3 subsystem to see how configuration schemas are handled.
Is it a good candidate to copy?
thanks,
jeff
[1] https://issues.jboss.org/browse/AS7-4330
[2]
https://github.com/jmesnil/jboss-as/commit/2f4389a10fe61bd054a5e4729ae8c6...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
6:46 a.m.
+1 it is read all but only persist as the latest.
Different subsystems have taken different approaches to this, some
completely fork the parser for each version others adapt the existing
parser to support the additional versions as they are added.
My one comment on this is writing a single parser that can support
multiple versions is very complex and so far I have seen a lot of
mistakes where this is attempted - personally I believe that the long
term maintainability of the parsers should take higher priority than
minimising the amount of code.
Regards,
Darran Lofthouse.
On 04/02/2012 10:18 AM, Kabir Khan wrote:
On 2 Apr 2012, at 09:29, Jeff Mesnil wrote:
> Hi,
>
> I am working on a JIRA issue to add missing configuration parameters to
> messaging resources[1]
>
> I did a quick patch to unblock the performance teams but I am revisiting
> it to fix it properly[2].
>
> As I am changing the XSD schema, I need to bump up its version.
> My changes are small (I'm just adding elements) but I wonder what the
> policy to manage schema changes is.
>
> * should I be able to read any previous configuration version? or only
> the last 2?
Old versions of the schema should be readable and converted into whatever ops your
subsystem currently takes
> * if I am reading an old configuration version, should I persist it at
> the same old version or the latest version?
We persist as the latest version
>
> I looked at ejb3 subsystem to see how configuration schemas are handled.
> Is it a good candidate to copy?
>
> thanks,
> jeff
>
> [1] https://issues.jboss.org/browse/AS7-4330
> [2]
> https://github.com/jmesnil/jboss-as/commit/2f4389a10fe61bd054a5e4729ae8c6...
> --
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
> _______________________________________________
> 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
9:36 a.m.
On 04/02/2012 01:46 PM, Darran Lofthouse wrote:
Different subsystems have taken different approaches to this, some
completely fork the parser for each version others adapt the existing
parser to support the additional versions as they are added.
My one comment on this is writing a single parser that can support
multiple versions is very complex and so far I have seen a lot of
mistakes where this is attempted - personally I believe that the long
term maintainability of the parsers should take higher priority than
minimising the amount of code.
Thanks for the input.
For these changes, I opted to subclass the parser and let the child
class handle the new attributes.
However, if the changes were more substantial (modification of tree
hierarchy, etc.), I agree that a new standalone parser would be simpler
to maintain (at the cost of having code duplication in case of bug fix).
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
4647
days inactive
4647
days old
3 comments
3 participants
participants (3)
-
Darran Lofthouse -
Jeff Mesnil -
Kabir Khan