cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: [2.2] Runtime deployment
Date Sun, 05 Nov 2006 14:15:16 GMT
Daniel Fagerstrom wrote:
> 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 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 
> 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.

The amount of mocking (and additional work to mimic the actual webapp) 
makes me think that it would probably be much easier if I just set up a 
jetty server programmatically and interface cocoon using commons http 

The test code I created is probably sufficient to use any cocoon 
component (parser, source resolver etc.) in business services.
Leszek Gawron                                    CTO at MobileBox Ltd.

View raw message