Joerg Heinicke skrev:
On 17.07.2007 06:08, Daniel Fagerstrom wrote:
Ok, sorry for implying that. The only alternative is probably to use
the shared application context as mentioned in the thread about
"interblock communication" [1].
I guess that would mean that each Cocoon block should be a war and
have its own web.xml and application context. I'm not certain that it
would simplify things.
Didn't we talk about servlets? Why now also the blocks? I only thought
about a solution of Cocoon playing more nicely together with other
frameworks.
We talked, among other things, about the design choices in the servlet
service fw. As the servlet service fw is designed to implement the
functionality described in
http://wiki.apache.org/cocoon/BlockIntroduction (but in a non Cocoon
centric way), the design doesn't make any sense if we remove the plugin
(block) aspect from it. If the only goal had been to make Cocoon play
nicer with other servlet based frameworks in a monolithic (not plugin
based) webapp, I'm certain that it could have been done in a simpler
way. Neither the less, as I suggest below, it seem like it would be
fairly easy to call JSP through the servlet service fw.
Even if it is only a thin wrapper registering the servlets
in Cocoon does not make them available as registering them directly in
the servlet container would do it.
That is correct, and it is a design choice. The servlet services are
Spring managed, not servlet container managed. IMO, that is mainly an
advantage, as Spring is so much more powerful and flexible as a service
manager. The servlet services are still callable through the dispatcher
that is an ordinary servlet container managed servlet.
What for example about applying
servlet filters? Is that to be integrated into servlet service framework
as well?
If people feel a need for it we can do that. IMO the preferable way
would be as package the filters as Spring interceptors.
If they are just servlets, not webapps/wars they have even access to the
application context set up by the ContextLoaderListener and we do not
even need the shared application context.
As said above the servlet services are designed as part of a plugin
architecture, so the above assumption doesn't hold.
But the servlet services are setup so they get the application context
in the standard way.
If you see the need though or just think the current approach is the
better one I'm happy to rely on your evaluation.
I think that the current approach solves the problems it is supposed to
solve in a rather clean, flexible and non intrusive way. But there is of
course tons of use cases that we haven't considered yet. So all feedback
is welcome.
I also know it's quite
late getting into this topic since probably all has been discussed
repeatedly when I did not follow the list that closely.
Stefano wrote detailed design documents five years ago, so it has been
discussed ;) The following links cover much of the current design choices:
Original design discussion:
http://wiki.apache.org/cocoon/Blocks
First implementation:
http://marc.info/?l=xml-cocoon-dev&m=111791016006393&w=2
OSGi based design:
http://marc.info/?l=xml-cocoon-dev&m=114237414521595&w=2
Removing OSGi:
http://marc.info/?l=xml-cocoon-dev&m=116030483925649&w=2
The change of names from block: protocol to servlet protocol:
http://marc.info/?l=xml-cocoon-dev&m=116879027007408&w=2
http://marc.info/?l=xml-cocoon-dev&m=116736231517487&w=2
With the current servlet service framework I just don't know how to
integrate JSPs - what this thread was actually about.
Isn't the standard way of integrating JSP to just call it through a
RequestDispatcher that you get from
ServletContext.getRequestDispatcher(String path)?
I have rarely worked with all that stuff and am not familiar with it.
When reading the corresponding section in the servlet spec it sounds
reasonable though. I only wonder what the downsides of this approach
are. Or: Why was the default implementation JSPEngineImpl [1]
implemented differently (though there is an implementation with the
approach you describe [2])?
No idea why there are two implementations, maybe the JSPEngineImpl is a
little bit tighter integrated into Cocon. Most other frameworks like
Struts and Spring MVC, seem to use request dispatchers to call JSP,
IIUC, so it should probably be good enough for us.
/Daniel
