cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barbara Slupik <>
Subject Re: Cocoon 2.2.1 - Context path at root doesn't work
Date Sun, 27 Jul 2008 20:13:11 GMT
Before cocoon-2.2 I was using tomcat in my development, test and  
production environments. Now I use maven/jetty for development and  
tomcat for test/production. In maven/jetty I change my block cforms,  
sitemap and flow and I can see the changes after refreshing the  
screen. When development is finished I package my block, build the  
application war file and put it in my tomcat test environment.


On 27 Jul, 2008, at 8:05 pm, Hugh Sparks wrote:

>> Hugh suffers regression:
>> [...wants to allow the SitemapServlet context path
>> to point to the webapp root directory for some but
>> not all webapps...]
>>> Grzegorz Kossakowski writes:
>>> Is there anything that stops you from using one block for
>>> migration? I guess your life should be  much easier in that
>>> case.
> It is not entirely an issue of migration. I think there are
> other good reasons to allow some webapps easy access to files
> in the root directory.
>>> [...]
>>> You may convince us that we need to support blockless style
>>> of using 2.2 by pointing out some serious limitation that
>>> block architecture introduces. At this moment, I fail to
>>> see any.
> Let me try.
> First of all, the block architecture and the use of Spring is a  
> fantastic development: It is now possible to create servlets using  
> Cocoon that deploy and behave like java servlets. And with
> Spring, they can be created and interconnected entirely by editing  
> configuration files. Cocoon has truly become "Web glue for web  
> applications." This is a great thing! In my opinion there are
> no "serious limitations" introduced by the block architecture.
> Only advantages!
> But I feel that a distinction should be made between software and  
> content: It is a fine thing to assemble functional components from  
> a network of servlets. I have several
> applications very well suited to this pattern. Even some
> content naturally belongs in the "instance variables" of servlets.
> But packing <all> content into blocks is another matter: One of
> the greatest contributors to software productivity in my opinion is  
> the use of interactive development environments. Being able to  
> navigate into the web server's root directory and edit html with  
> only a browser refresh needed to see the changes is very powerful.  
> It is simply not reasonable to restart the web server when simple  
> "eye-candy" content is modified. Not only
> does it take time, but it disrupts the transactions of other
> users who access the site. I realise we have the RCL, but
> what happens when we deploy blocks with other servlet
> containers?
> Web developers expect to have instant gratification when it
> comes to changing simple content and would have serious
> reservations about adopting a tool that prevents this sort
> of experience. And cocoon - for its entire history until
> a few days ago - did support this interactive style as well
> as the blocks style. Why not preserve both capabilities?
> Particularly since it makes cocoon far more accessible to
> outsiders.
> As an example: I configure tomcat so the cocoon webapp is a  
> symbolic link to the apache server root directory. The WEB_INF and  
> META_INF for cocoon are right at the top level of my website.  
> Apache recognizes special urls and uses a proxy connection to send  
> these requests to Tomcat and on to Cocoon.
> The top level sitemap.xmap is also at the apache root directory.
> What is gained by this?
> I can edit any content - html, css, sitemaps, and flowscript  
> without disturbing any of the running software or (in most
> cases,) anyone accessing the site.  Most importantly, I can
> see the effects of these changes by simply refreshing the
> browser page.
> The content at the webserver root can be mixed:
> Apache handles requests it does best with its vast
> assortment of modules and languages while cocoon handles content
> it does best. And these domains are not independent: I have
> applications where the same content may be accessed by both
> apache and cocoon. A simple example is the set of css
> stylesheets.
> So what I'd like to preserve is a hybrid environment: It is a  
> valuable innovation to have blocks as independent
> servlets configured by Spring. But I feel that putting all
> content into blocks is a barrier to developer productivity
> and shuts out the ability of some-but-not-all web tools to
> share content with cocoon.
> I'd like to mention another advantage of interactive programming  
> environments: The preservation of state:
> It takes very little time to update a block with maven. The same is  
> true for recompiling a C source code file in a traditional  
> application. The real cost is re-establishing the state of a  
> complex network of interacting components. In many cases, this  
> takes far more time than rebuilding the entire site. But with  
> interactive tools (think Smalltalk) you can explore the state of  
> the running program, recompile a particular method and continue  
> running. True, you may want to restart the whole thing to verify  
> that the changes are consistent, but much of the time, particularly  
> when only static content is altered, nothing has to be disturbed.
> This is one of the reasons why scripting language users
> report higher levels of productivity than "compiler
> language" users. I'd like to see cocoon evolve as a
> "never shut it down" network of components, just as
> we expect from a web server O.S. or distributed set of
> cooperating hosts.
> This seems like a lot to gain at the cost of allowing a context- 
> path to be "/" in the SitemapServlet bean.
> To summarize my position: I am not advocating a "blockless style"  
> of using cocoon. I'm not a "block skeptic"
> or a "Spring skeptic." But I believe there is a place for
> allowing content outside of jars in the webapp root directory
> and this should probably be the default situation when no
> protocol is specified. This allows cocoon applications to work
> and play well with other established web development tools,
> and makes it far easier for developers to see the consequences
> of trivial changes when editing content.
> Thanks for listening. -  Perhaps I'm the only cocoon user who
> thinks this way and I will have to mend my ways.
> -Hugh Sparks,
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message