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

[Martin K. <Mar...@St...>]

Hi Juergen,

   Thanks for your reply. It made some points more clear.

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

What I was about is the dependencies that the Spring framework
draws. When I look on the composition model I noticed that
the application context draws in most of the capabilities the
bean package provides (Application context implements five
diffrent interfaces /types). So those packages point their fingers
to the man in the middle.

That the bean package has some advantage when being used
independently isn't something that I can not understand.

Let me show you this:

interface ApplicationContext extends:
  ListableBeanFactory -> beans (friendly)
  HierarchicalBeanFactory -> beans (friendly)
  MessageSource -> context (same)
  ApplicationEventPublisher -> context (same)
  ResourcePatternResolver -> core.io.support (friendly)

One major gap are the ListableBeanFactory and
the HierarchicalBeanFactory interfaces. Looking on the
resulting ApplicationContex two special methods are imposed

1. getParent() : ApplicationContext
2. getParentFactory() : BeanFactory

I think this indicates a mixed thinking.
Parent and parent factory, can be somewhat diffrent but
the domain should be clear. Maybe the application context
should not pretend to be a bean factory first place
(trade polymorphism for composition and therefore for
responsibility)

That is, what I was referring to. ApplicationContext
solves the same tasks, like an ordinary bean factory do
because it is(!) actually a bean factory. So the question
goes, if application solves the same tasks a bean factory
can and even some more, isn't it logical to think
that a factory is a realisation of a feature of an
application context?

And if yes, wouldn't it mean that every time a
user of the spring framework goes for a
bean factory instead of a context, that
the context is harder to use or misses some
more key features? I understand that while
implementing some of the features
context/bean factory needs, it may provide some
general purpose features, that may be usable on
their own. But this general purpose features are
no reason to not consider the beans package
as a realisation of some of the tasks the application
context has to deal with?

The same thinking goes to the web context as
well. All the association arrows point to the
web context as being the spider in the web.

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

The bean factory level is - in my thinking - the
application context 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.

Well I agree with that. But you can use the collections framework of
the Java JDK outside of Java by just applying the described logic
to a diffrent language. The collections framework is purpose driven.
It exists to serve the Java language, but is also capable to serve other
languages as well.

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

Well that is a point. But again I wouldn't see this as an argument
against it. The JDBC support is part of the application context
usage domain as well. It would justify to consider JDBC as a
sub-project but not to be more important than the context. It is
just an aspect of a special kind of applications (realise
a persistance layer)

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

I understand. But think about the Eclipse platform. The Eclipse folks
at IBM build the SWT/JFace packages to serve the needs of the
platform. But this support got so usefull that they made it a
sub-project to be used independently, too. The fun part of it
is that this swt and jface are still considered to mainly serve the
platform's needs and that their independent usage is just a result
of the overlappings of requirements from a diffrent target audience.

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

The misplacing was also ment in form of refering it as xml package.
XML is just a way to specifiy a factory. That's why I consider this
a view or translation related task. You translate something into
something more usable. This is what a parser mainly does.
It converts form one language into another one. Thats why I would
like to add this at least to a parser package. It is just a way to view
things.

But again I would consider this to be a context related issue, since
by using a xml file this would also be understandable by an application
context. So there is a replication of functionality here. You can read
a context or a more special form (bean factory) from the same
source, but you use diffrent features the framework provides. I don't
like this duplication in responsibility.

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

Thats why I don't like the beans module as it is currently shaped.

Since this are exchanges of thoughts, there is no guarantee that we will
reach a consensus at this topic. I guess this isn't also needed.

I enjoy using the Spring framework because it is so more simplier
than the EJB framework but I guess there is some room for
improvements. Something just don't feel right and if I see the
dependency graph, it just looks a bit too complicated for my
experience.

Never the less, thanks for developing the Spring framework,
it saved me countless hours of work! (it still does...)


Thanks and cheers,

Martin (Kersten)

PS: Thanks for your extense answer, I also wrote a
more extense reply to honor your afford and your will to
make me understand your position. I don't know if I could
provide you some additional informations about my point
of view. Maybe we reached a point where I have to provide
some kind of proof for my claims which I can not deliver yet
(but soon I will - in some months at least)