On 28/04/2008, John Lung <[EMAIL PROTECTED]> wrote: > Hi: > > We're trying to use JSTL 1.1 c:import tag on weblogic 9.2 in an JSP page to > import the Cocoon page (Cocoon 2.1.11) under a different context (a > different webapp in the same weblogic domain). > > <c:import url="/MyCocoonPage" context="/Cocoon" /> > > cocoon throws a 404 error and saying no match in the sitemap. But when I > directly access this page: > > http://localhost:port/Cocoon/MyCocoonPage > > the page displays fine. I tested on Tomcat5.5 and it worked fine. I tested > to c:import a different JSP on weblogic and it worked fine too. Any > suggestions?
If I remember rightly, c:import works much like jsp:include in that it looks up the relevant RequestDispatcher (in this case, for the Cocoon servlet) and does a .include() on it. There's some added trickery to allow for the included resource calling getOutputStream when the jsp containing the tag will have already called getWriter, which would otherwise throw an IllegalStateException. The thing that's catching you out is that the .include() call gets passed the original request & (wrapper around the) response objects, so if your Cocoon pipeline uses the wildcard or regex URI matchers the URI they see will be for the originally requested JSP rather than the path & context mapped to the Cocoon servlet. That's why it's failing to match and you get the 404s. We had the same problem on a project I worked on a few years back - the Content Management System generated JSPs from its data structures, and we needed to embed some stuff generated by Cocoon. The first workaround we used was to change the CMS's templates to generate c:import tags along the lines of <c:import url="/MyCocoonPage?cocoon-path=/MyCocoonPage" context="/Cocoon" /> and in our root sitemap.xmap change the default matcher to the request parameter one instead of the URI one. That way we didn't have to change any of the map:match entries except where one pipeline called another via cocoon:/ The second version workaround we used was to create our own version of the c:import tag. This passed a request wrapper to the dispatcher's include method that behaved as if it was a new request for the included resource, so the various getServletPath/URI/etc. methods would return the appropriate values for /Cocoon/MyCocoonPage and no need to mess around with the extra request parameter. The third version sent all requests through Cocoon, and anything asking for a JSP matches a pipeline that uses the JSP reader to call it. The rest was down to configuring the jsp-engine entries in cocoon.xconf so that things got dispatched correctly (not initialising a new copy of the JSP with every call, and not attempting to forward the request back through the Cocoon servlet again as that led to a blown stack and/or Out Of Memory errors). I'm not entirely sure we had any JSPs doing further jsp:include or c:import calls, though, as by this stage we were doing most of the page inclusion on the Cocoon side via the cinclude transformer. Hope that gives you some ideas to be going on with. Andy. -- http://pseudoq.sourceforge.net/ Open source java Sudoku application. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
