XML bean definition parsing refactoring

[daleth]

I'm currently using Spring 2.5 within a project and looking to update to 3. The project uses custom namespaces pretty extensively and I've implemented an extension to Spring to allow selection of the Namespace handler and bean parsers via schema type as well as qualified element name.

When I started to look in to adding a similar feature to our Spring 3 I began taking a in-depth look at the org.springframework.beans.factory.xml classes. What I noticed is that within the DefaultBeanDefinitionDocumentReader and BeanDefinitionParserDelegate the parsing of "native" beans (e.g. <bean>) were intermixed with the parsing of custom beans.

What this means for me is that if I wanted to go in and change how the custom parsing was done, specifically looking up parsers by schema type in addition to element names, I'd have to touch and extend classes that also handled Spring's native elements. That just doesn't feel right to me and it seems like it could lead to problems.

Would the spring developers be amenable to a patch that tried to split the handling of native Spring elements from the handling of custom elements such that changes could be made in the custom element parsing logic without touching any of the classes responsible for the native element parsing? I'm not sure it's possible without changing APIs, but if there is some interest I'd give it a shot.

[al0]

I guess this topic should rather migrate to Spring JIRA (jira.springframework.org), create an issue there.

I'm currently using Spring 2.5 within a project and looking to update to 3. The project uses custom namespaces pretty extensively and I've implemented an extension to Spring to allow selection of the Namespace handler and bean parsers via schema type as well as qualified element name.

When I started to look in to adding a similar feature to our Spring 3 I began taking a in-depth look at the org.springframework.beans.factory.xml classes. What I noticed is that within the DefaultBeanDefinitionDocumentReader and BeanDefinitionParserDelegate the parsing of "native" beans (e.g. <bean>) were intermixed with the parsing of custom beans.

What this means for me is that if I wanted to go in and change how the custom parsing was done, specifically looking up parsers by schema type in addition to element names, I'd have to touch and extend classes that also handled Spring's native elements. That just doesn't feel right to me and it seems like it could lead to problems.

Would the spring developers be amenable to a patch that tried to split the handling of native Spring elements from the handling of custom elements such that changes could be made in the custom element parsing logic without touching any of the classes responsible for the native element parsing? I'm not sure it's possible without changing APIs, but if there is some interest I'd give it a shot.

[daleth]

Will do. I just wanted to start here in case people were totally against the idea of doing any work in this area of the code. Or against having an external individual do work in this area.

[mikelangelo11]

Spring is a powerful Java application framework, used in a wide range of Java applications.It provides enterprise services to Plain Old Java Objects.Spring uses dependency injection to achieve simplification and increase testability.Spring beans, dependencies,and the services needed by beans are specified in configuration files, which are typically in an XML format.The XML configuration files,however, are verbose and unwieldy.They can become hard to read and manage when you are working on a large project where many Spring beans are defined.Some of them are more necessary practices than best practices.Note that other factors,such as domain model design, can impact the XML configuration,but this article focuses on the XML configuration's readability and manageability.

[al0]

Which article?

Spring is a powerful Java application framework, used in a wide range of Java applications.It provides enterprise services to Plain Old Java Objects.Spring uses dependency injection to achieve simplification and increase testability.Spring beans, dependencies,and the services needed by beans are specified in configuration files, which are typically in an XML format.The XML configuration files,however, are verbose and unwieldy.They can become hard to read and manage when you are working on a large project where many Spring beans are defined.Some of them are more necessary practices than best practices.Note that other factors,such as domain model design, can impact the XML configuration,but this article focuses on the XML configuration's readability and manageability.