Leszek Gawron skrev:
Daniel Fagerstrom wrote:
Might be that it will not that easy to create a mock servlet context
that contain exactly what is needed for creating beans in a
XmlWebApplicationContext. In my experience getting the different
context used within Cocoon is never easy. But I can assure you that
creating a mock servlet context is a much simpler solution to the
problem that you want to solve than refactoring Cocoon so that it
doesn't depend on having a servlet context available.
We should of course provide a mock servlet context so that users
doesn't need to implement one themselves.
For the particular problem you get, I would need to see what the
malformed URL looks like to have any clue about what goes wrong.
It was my mistake in ServetContext.getResource().
Seems I have a running cocoon with no servlet container:
Cool!
Now if somebody could show me how to build a pipeline...
If you mean building a pipeline in Java it is not as easy as one would
like, see http://marc.theaimsgroup.com/?t=116133031100001&r=1&w=2 for a
recent discussion about the topic.
It is easier to build the pipeline in a sitemap and call the SitemapServlet.
What you need to do is that create and init the SitemapServlet. For the
initialization you need a mock servlet configuration that "contains" to
your mock servlet context. You need to set the mock servlet context
attribute WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE
to contain the web application context to make the sitemap servlet to work.
Then you need a mock request and response object for being able to call
the service method of the servlet. Here you can reuse o.a.c.blocks.util.
BlockCallHttpServletRequest and BlockCallHttpServletResponse, from the
cocoon-blocks-fw-impl. There is nothing block fw specific in them and we
might want to rename them an move them to some servlet util package. You
can find an example of how to use the mentioned request and response
objects in o.a.c.blocks.BlockConnection.
/Daniel
