cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
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 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.

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 
client.

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.


Mime
View raw message