Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <469F2805.7050304@nada.kth.se>
Date: Thu, 19 Jul 2007 10:59:49 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: JSP integration
References: <BAY121-W89F25F24A6163E94DACF5AD0C0@phx.gbl>
 <46951373.6050507@gmx.de> <4695F507.4080708@apache.org>
 <loom.20070713T214606-983@post.gmane.org> <469B2D2C.9030107@nada.kth.se>
 <469BB86A.6050607@gmx.de> <469C9504.6060806@nada.kth.se>
 <469EDDAA.8050309@gmx.de>
In-Reply-To: <469EDDAA.8050309@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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