ryan-highley commented on code in PR #4122: URL: https://github.com/apache/activemq-artemis/pull/4122#discussion_r911219489
########## artemis-server/src/main/resources/schema/artemis-configuration.xsd: ########## @@ -16,18 +16,23 @@ limitations under the License. Review Comment: And I understand your point. I work building large-scale production Artemis systems for clients every day--that's my job. I use modular files for common sections of broker.xml configurations extensively to build everything from cluster prototypes to multi-DC, world-wide messaging infrastructure. My point is simple. The XSD does not support modularity as well as it should due to the "anonymous" element and complexType definitions buried in the configurationType definition. This is bad XSD form as the embedded defined types and elements cannot be used directly--they're only useful in the context of the outermost defining type, the configurationType in this case. Moving these embedded elements and their associated complex types to top-level definitions enables XML tooling to recognize and support the schema definition in both modular files as they're being developed as well as complete broker.xml files. While the elements may not make sense outside a broker configuration, supporting modular files necessarily implies the elements therein are portable to those files. The same tooling support should be available in the modular files as is available when developing a monolithic broker.xml file. I agree the scale of this change involves significant risk. This is why I included additional updates to the existing xinclude unit tests to address that risk. If you would like to suggest additional test scenarios, I'm happy to include those as well. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
