Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Juergen H. <ju...@in...>]

Martin,

<quote>
So in my oppinion the ApplicationContext should be placed in
org.springframework since beans, aop and context are only
exisiting to provide the functionality the ApplicationContext
needs (or better an implementation of the interface needed).
</quote>

In fact, the beans and aop packages do not only exist to serve the
ApplicationContext. Spring is not a single system with a single entry point:
In that respect, the Spring distribution is more similar to the JDK's
structure than it is to Hibernate's, for example.

The beans package is completely independent and can of course be used on its
own, both at the BeanWrapper level and at the BeanFactory level. Some people
happily do either of the two, and don't care about the context package (or
any other Spring packages) at all.

The beans package is also used internally by the JDBC support, the
validation package and other parts of Spring. No ApplicationContext (or
MessageSource etc) needed there, just low-level BeanWrapper and/or
BeanFactory functionality. Quite a lot of people are using Spring's JDBC
support completely outside a Spring application context, for example in
custom DAOs or in custom EJBs.

Also, parts of the web package are more reusable than you assume; the
WebApplicationContext isn't really central to it. For example, Spring-style
data binding can easily be used in a plain Servlet or any other web
component built on a ServletRequest: simply take Spring's
ServletRequestDataBinder (package web.bind) and use it in a library style.

This is why spring-core.jar just contains the beans package, not the context
package. Those spring-core.jar contents are perfectly sufficient for using
the JDBC support (spring-dao.jar), or the web data binding in a library
fashion (spring-web.jar). Such parts of Spring can be used in a library
style, within any kind of architecture (for example, in custom frameworks or
in EJB-centric applications).

Only for applications that are fully architected on a Spring basis, an
ApplicationContext will play a central role. This is significantly different
from a single-purpose tool such as Hibernate, where the
SessionFactory/Session combo plays a central role in all scenarios.

<quote>
For example, I am currently doing refactoring of
the DefaultXmlBeanDefinitionParser implementation.

This is part of bean.factory.xml. In my thinking this is
wrong placement. The parser first of all should be
in a modul about parsers. But beside this you read
an application context definition file. Check out  how
the dtd of spring is defined. All about beans. To
describe an application context you are referring to
the dtd.
</quote>

Again, I tend to look at this from a different perspective: The BeanFactory
stuff in the beans.factory package is the central part that deals with bean
definitions. An ApplicationContext is "just" a higher-level facade for it,
adding auto-detection for special beans and additional services like a
MessageSource.

Consequently, XML bean definition parsing does belong in the beans.factory
package, as it is "just" a special variant of parsing bean definitions. XML
bean definitions may be the current main format for defining application
contexts, but from the framework point of view, it is just yet another bean
definition format and by no means central to all other parts of Spring.

Juergen