You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Andrew Stevens <at...@hotmail.com> on 2007/07/03 02:19:31 UTC
JSP integration
Hi,
In the past I've used a few different JSPEngine implementations with the (2.1.x) JSP generator & reader. On iPlanet there was one that was configured with the fully qualified class name of its JSP servlet (can't remember offhand which one it was, but that's not important). On Websphere I'm using one that looks it up based on the servlet name ("JSP 1.2 Processor" or something like that). However, sometimes (even on the same app server type) I've had to tweak the configurations to avoid getting errors like "Text content found before prologue". Since switching settings to e.g. use RequestDispatcher.include() instead of .forward() fixes this, I don't think there's actually anything wrong with the JSP output. Best I can think of is maybe it's struggling with a 0xFFFE UTF-8 byte-order marker prior to the initial xml processing instruction. But I digress.
I actually find the fact the JSP generator requires the JSP to produce valid (or at least well-formed) XML is actually quite limiting. I had to rewrite various exisiting JSPs that were producing HTML, to output a single top-level DIV element and make the rest valid XHTML; with other static HTML files I just used the jtidy or neko generators to clean them up instead.
My first thought was to create a modified JSP generator component that passed the output through neko/jdity before parsing it. And then inspiration hit - why not instead create a new input Source for JSPs? That way, JSPs that produce XML can be processed by the default (file!) generator, ones that produce HTML can be processed by the HTML generator, and you could even have ones that produce CSV be processed by (you guessed it) the CSVGenerator. Seems much more flexible to me.
And then I started to over-think it :-) Why only JSPs? Why not servlets too? How does this differ from the context: source type? Surely someone must have thought of doing this before - is there no similar facility already? What about in Cocoon 2.2 - would the servlet/blocks framework that keeps getting discussed cater for this anyway?
At which point I figured the best thing to do was to dump my thoughts to the list and see if anyone had any feedback or suggestions...
So, what about it? Would this be a useful addition to the JSP block? Or is there already a similar facility that I'm overlooking?
Andrew.
_________________________________________________________________
Feel like a local wherever you go with BackOfMyHand.com
http://www.backofmyhand.com
Re: JSP integration
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: JSP integration
Posted by Joerg Heinicke <jo...@gmx.de>.
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. 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. What for example about applying
servlet filters? Is that to be integrated into servlet service framework
as well?
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.
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 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.
>> 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])?
Joerg
[1]
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/jsp/java/org/apache/cocoon/components/jsp/JSPEngineImpl.java?revision=433543&view=markup
[2]
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/jsp/java/org/apache/cocoon/components/jsp/JSPEngineImplNamedDispatcherInclude.java?revision=433543&view=markup
Re: JSP integration
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Joerg Heinicke skrev:
> On 16.07.2007 04:32, Daniel Fagerstrom wrote:
>
>>> 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.
>
>> So I would say that it is very far from the "almighty Cocoon syndrome".
>
> 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.
> 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)? The servlet protocol
just sets up request and response objects and call other servlets
through by the request dispatcher it gets from the current servlet
context. The servlet service fw executes each servlet (service) in its
own context, so you can't access other servlets (or JSP) through the
getRequestDispatcher method. To access other servlet services, one
instead use getNamedDispatcher.
Now currently there is no way to get the original context which is
needed to dispatch to e.g. JSP. But that is of course something that we
should make available. The simplest way to do it would be to have some
reserved name for the original context, "root" e.g. then one could
dispatch to that by asking for a named dispatcher with the name "root"
or by using the servlet service protocol: "servlet:root:/". Implementing
it would, AFAICS, as simple as extending
o.a.c.servletservice.ServletServiceContext.getNamedContext, so that it
returns the wraped root context (super) when asked for "root".
One could also think of registering a special purpose servlet service
that connects to the root context and that servlet services needs to
connect to if they want to call the root context, but I think that would
be overkill.
WDYT?
/Daniel
Re: JSP integration
Posted by Joerg Heinicke <jo...@gmx.de>.
On 16.07.2007 04:32, Daniel Fagerstrom wrote:
>> 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.
> So I would say that it is very far from the "almighty Cocoon syndrome".
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].
With the current servlet service framework I just don't know how to
integrate JSPs - what this thread was actually about.
Joerg
[1] http://marc.info/?l=xml-cocoon-dev&m=118269446927501&w=4
Re: JSP integration
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: JSP integration
Posted by Joerg Heinicke <jo...@gmx.de>.
On 13.07.2007 16:58, Grzegorz Kossakowski wrote:
> I really have no experience with JSP and I don't know how its servlet is
> initialized and how it works. If you could explain what could be a
> possible problem I would try to answer according to my knowledge.
Me neither. My last project was the first with JSP and that's purely in
the portlet environment. So no request dispatcher or other stuff.
You can have a look at the implementation of the 2.1's JSP block and the
different JSPEngine implementations [1]. This kind of integration always
caused many different kinds of problems, some things (forward and
include) were not supported at all.
> As a side-note: If particular servlet must be managed by servlet
> container can't we create servlet (as a Spring bean) that would forward
> all requests to the JSP servlet using request dispatcher:
> http://www.jguru.com/faq/view.jsp?EID=206736 ?
No idea. Never worked on that level.
Joerg
[1]
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/jsp/java/org/apache/cocoon/components/jsp/
Re: JSP integration
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> On 12.07.2007 05:31, Grzegorz Kossakowski wrote:
>
> How is that supposed to work with JSPs where Jasper (when using Tomcat) needs to
> kick in and compile the JSPs? 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? This approach still seems to suffer
> from the "almighty Cocoon" syndrome (doing everything itself, not delegating
> stuff to e.g. the servlet container).
Your impression seems to be right. However, I believe that one of main goals while designing cocoon-servlet-service was to stay as
transparent as possible. I guess that if we let servlet container to manage servlets we wouldn't get enough flexibility we need but it would
be better if Daniel could comment as a creator of whole stuff.
I really have no experience with JSP and I don't know how its servlet is initialized and how it works. If you could explain what could be a
possible problem I would try to answer according to my knowledge.
As a side-note: If particular servlet must be managed by servlet container can't we create servlet (as a Spring bean) that would forward all
requests to the JSP servlet using request dispatcher: http://www.jguru.com/faq/view.jsp?EID=206736 ?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: JSP integration
Posted by Joerg Heinicke <jo...@gmx.de>.
On 12.07.2007 05:31, Grzegorz Kossakowski wrote:
> Basically, you need to register JSP servlet as Spring bean, then you can
> connect to it from other servlet (Cocoon block) using its bean's Id and use
> servlet:/ source for this.
>
> All needed functionality is already there and working, it's a matter of
> providing sample and (really preferably) some documentation how to
> utilize servlet-service-fw functionality to integrate with JSP.
How is that supposed to work with JSPs where Jasper (when using Tomcat) needs to
kick in and compile the JSPs? 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? This approach still seems to suffer
from the "almighty Cocoon" syndrome (doing everything itself, not delegating
stuff to e.g. the servlet container).
Joerg
Re: JSP integration
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> On 02.07.2007 20:19, Andrew Stevens wrote:
>
>> And then inspiration hit - why not instead create a new input Source
>> for JSPs?
>>
>> And then I started to over-think it :-) Why only JSPs? Why not
>> servlets too? How does this differ from the context: source type?
>> Surely someone must have thought of doing this before - is there no
>> similar facility already? What about in Cocoon 2.2 - would the
>> servlet/blocks framework that keeps getting discussed cater for this
>> anyway? At which point I figured the best thing to do was to dump my
>> thoughts to the list and see if anyone had any feedback or
>> suggestions...
>
> Hi Andrew,
>
> your ideas sound absolutely reasonable. I appreciate every improvement
> to the integration of JSP or servlets in general though I don't use it
> myself (yet). In 2.1 I would really opt for a new source. I only wonder
> if this is necessary at all in 2.2. I got the impression (just from
> mailing list) it should be quite easy to integrate Cocoon with other
> servlets but somebody with actual knowledge might add more details here.
> What I for example would really like to have is a CocoonView for
> Spring's ViewRendererServlet or use Cocoon as replacement for the
> ViewRendererServlet.
Yep, you are right Joerg and Andrew, servlet-service-fw is the way to go.
Basically, you need to register JSP servlet as Spring bean, then you can connect to it from other servlet (Cocoon block) using its bean's Id
and use servlet:/ source for this. Take a look at:
[1] for servlet configuration as spring bean
[2] for demo servlet itself
All needed functionality is already there and working, it's a matter of providing sample and (really preferably) some documentation how to
utilize servlet-service-fw functionality to integrate with JSP.
[1]
http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/src/main/resources/META-INF/cocoon/spring/cocoon-servlet-service-demo1-servletService.xml?view=markup
[2]
http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/src/main/java/org/apache/cocoon/servletservice/demo1/DemoServlet.java?view=markup
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: JSP integration
Posted by Joerg Heinicke <jo...@gmx.de>.
On 02.07.2007 20:19, Andrew Stevens wrote:
> And then inspiration hit - why not instead create a new input Source
> for JSPs?
>
> And then I started to over-think it :-) Why only JSPs? Why not
> servlets too? How does this differ from the context: source type?
> Surely someone must have thought of doing this before - is there no
> similar facility already? What about in Cocoon 2.2 - would the
> servlet/blocks framework that keeps getting discussed cater for this
> anyway? At which point I figured the best thing to do was to dump my
> thoughts to the list and see if anyone had any feedback or
> suggestions...
Hi Andrew,
your ideas sound absolutely reasonable. I appreciate every improvement
to the integration of JSP or servlets in general though I don't use it
myself (yet). In 2.1 I would really opt for a new source. I only wonder
if this is necessary at all in 2.2. I got the impression (just from
mailing list) it should be quite easy to integrate Cocoon with other
servlets but somebody with actual knowledge might add more details here.
What I for example would really like to have is a CocoonView for
Spring's ViewRendererServlet or use Cocoon as replacement for the
ViewRendererServlet.
Joerg