Re: JSP integration
Andrew Stevens skrev: Date: Wed, 18 Jul 2007 23:42:34 -0400 From: [EMAIL PROTECTED] 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=433543view=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=433543view=markup Not quite - the implementation in [2] accesses the JSP engine through getNamedDispatcher, not getRequestDispatcher; if you're wanting to call /cocoon/foobar.jsp it looks up the configured name (getNamedDispatcher(*.jsp) by default, which is what Tomcat uses, but it's called JSP 1.2 Processor on Websphere 5 and probably something else on other containers) and before calling include (or forward, depending on configuration) sets the appropriate attributes in the request object, described in the servlet spec, to make the engine think it's been called by a 'jsp:include page=/cocoon/foobar.jsp' (or jsp:forward). What Daniel described would be an implementation that just calls getRequestDispatcher(/cocoon/foobar.jsp), and calls include/forward on that. There isn't an existing implementation which does that, but it's what I was describing in my earlier post (http://marc.info/?l=xml-cocoon-devm=118437354213375w=2). The biggest problem with it is that if JSPs are mapped to go through the Cocoon servlet (like the default Cocoon 2.1.x web.xml does), then getRequestDispatcher will return a reference to Cocoon. So Cocoon passes the request to Cocoon for processing, which passes it to Cocoon for processing, which passes it to ... well, you get the picture. Eventually you get a java.lang.StackOverflowError and a 500 Server Error gets returned to the browser :-( Which is probably why the existing Cocoon implementations all use some other way to call the container's JSP engine. You only get the infinite loop if you insist on mounting the Cocoon servlet and the JSP at the same path if you use different paths the problem disappear. Also if you want to use a named dispatcher, we could make the named dispatcher in the ServletServiceContext fall back to the original servlet context, for names that the servlet service isn't connected to. /Daniel
Re: JSP integration
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-devm=111791016006393w=2 OSGi based design: http://marc.info/?l=xml-cocoon-devm=114237414521595w=2 Removing OSGi: http://marc.info/?l=xml-cocoon-devm=116030483925649w=2 The change of names from block: protocol to servlet protocol: http://marc.info/?l=xml-cocoon-devm=116879027007408w=2 http://marc.info/?l=xml-cocoon-devm=116736231517487w=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
Date: Wed, 18 Jul 2007 23:42:34 -0400 From: [EMAIL PROTECTED] 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=433543view=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=433543view=markup Not quite - the implementation in [2] accesses the JSP engine through getNamedDispatcher, not getRequestDispatcher; if you're wanting to call /cocoon/foobar.jsp it looks up the configured name (getNamedDispatcher(*.jsp) by default, which is what Tomcat uses, but it's called JSP 1.2 Processor on Websphere 5 and probably something else on other containers) and before calling include (or forward, depending on configuration) sets the appropriate attributes in the request object, described in the servlet spec, to make the engine think it's been called by a 'jsp:include page=/cocoon/foobar.jsp' (or jsp:forward). What Daniel described would be an implementation that just calls getRequestDispatcher(/cocoon/foobar.jsp), and calls include/forward on that. There isn't an existing implementation which does that, but it's what I was describing in my earlier post (http://marc.info/?l=xml-cocoon-devm=118437354213375w=2). The biggest problem with it is that if JSPs are mapped to go through the Cocoon servlet (like the default Cocoon 2.1.x web.xml does), then getRequestDispatcher will return a reference to Cocoon. So Cocoon passes the request to Cocoon for processing, which passes it to Cocoon for processing, which passes it to ... well, you get the picture. Eventually you get a java.lang.StackOverflowError and a 500 Server Error gets returned to the browser :-( Which is probably why the existing Cocoon implementations all use some other way to call the container's JSP engine. Andrew. -- http://pseudoq.sourceforge.net/ _ Try Live.com - your fast, personalised homepage with all the things you care about in one place. http://www.live.com/?mkt=en-gb
Re: JSP integration
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=433543view=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=433543view=markup
Re: JSP integration
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
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
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-devm=118269446927501w=4
Re: JSP integration
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
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
Reposted, since I didn't get a copy from the list and don't see it in the
archives. Apologies if you've seen it already.
Date: Thu, 12 Jul 2007 11:31:51 +0200
From: [EMAIL PROTECTED]
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
Ah, that might be a problem then. In Websphere 6 (and presumably later
versions too), the JSP engine isn't actually a servlet any more - they use a
new server extension architecture to handle requests for JSPs (I assume
through some interception mechanism). In our existing 2.1.x app, I got it
working by creating a new JSPEngine implementation that looks up the
RequestDispatcher for the supplied URL and calls include or forward directly on
that (instead of using JSPEngineImplNamedDispatcherInclude to look up JSP 1.2
Processor servlet, which I'd been doing on WAS 5.x). **
How would that fit into the servlet-service-fw?
Andrew.
** NB I also had to remove the *.jsp servlet mapping from the Cocoon
servlet, so JSPs are now run directly by the container instead of going through
Cocoon first. It means you can't have Cocoon map whatever.jsp requests to
some other pipeline that doesn't call the JSP engine, but we weren't doing that
anyway. Without it, however, pipelines like
would go into an endless loop as the foo/{1}.jsp request is also directed
through Cocoon and matches the same pipeline...
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/
_
Try Live.com - your fast, personalised homepage with all the things you care
about in one place.
http://www.live.com/?mkt=en-gb
Re: JSP integration
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
On 13.07.2007 20:38, Andrew Stevens wrote: In our existing 2.1.x app, I got it working by creating a new JSPEngine implementation that looks up the RequestDispatcher for the supplied URL and calls include or forward directly on that (instead of using JSPEngineImplNamedDispatcherInclude to look up JSP 1.2 Processor servlet, which I'd been doing on WAS 5.x). What about Grek's idea? Creating a Cocoon-controlled servlet that does exactly this? I also had to remove the *.jsp servlet mapping from the Cocoon servlet, so JSPs are now run directly by the container instead of going through Cocoon first. I don't get it. How does this match with the above? Why do you need a JSPEngine implementation if Cocoon does not handle the JSP requests anyway? Joerg
Re: JSP integration
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
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
