Joerg Heinicke skrev:
...
From what I understand other servlets need to be
registered in Cocoon (or the underlying Spring container). Doesn't that make it
a servlet container in a servlet container?
Yes, but the internal "container" is very light weight.
This approach still seems to suffer
from the "almighty Cocoon" syndrome (doing everything itself, not delegating
stuff to e.g. the servlet container).
As much as possible is delegated. But servlet containers doesn't contain
any mechanisms for building webapps based on plugins that can
communicate and share components, so I don't see how we can achieve the
goals without creating some own infrastructure. Do you have any concrete
suggestions?
Otherwise the servlet service and block architecture is really non
intrusive. As you can see
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml
it haven't any dependencies on the rest of Cocoon, the only API, the
user need to care about is the servlet one. Configurations is done with
Spring.
The architecture consists of a dispatcher and an own ServletContext
implementation that allow for inter block communication and some support
classes.
So I would say that it is very far from the "almighty Cocoon syndrome".
/Daniel
