Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4800BC04.5040806@tt.com.au>
Date: Sat, 12 Apr 2008 23:41:24 +1000
From: Kamal <kbhatt@tt.com.au>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: C2.2 Migration plan from 2.1
References: <4800151A.7000202@tt.com.au> <48009D52.7030007@tuffmail.com>
In-Reply-To: <48009D52.7030007@tuffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>> I am trying to work out the best way of migrating off 2.1 into 2.2. 
>> Firstly, we have far too much functionality to migrate everything in 
>> one hit. So,  I was wondering if it were possible to communicate XML 
>> between two instances of Cocoon easily (without hitting an URL). That 
>> is, from 2.2 to 2.1. Would the Cocoon Servlet Service help here?
>
> Hmmm. I haven't tried such approach. This should be possible, the only 
> problem I can see here is that running two Cocoon versions in the same 
> JVM may result in library clashes. It's still a subject for research.
We currently have two version of Cocoon running on the same application 
server (2.1.7 and 2.1.9). It is far from perfect, but it works. Not too 
sure about the ramifications of the 2.2 and 2.1.x.
>
> However, I wonder if you couldn't just migrate whole app to C2.2 but 
> running in "legacy" (or classic) mode. Vadim Gritsenko were talking 
> about such approach at last Cocoon GetTogether, see[1]. Provided you 
> manage to get your application running in classic mode you could start 
> gradually migrate portions of your application to new approaches and 
> design best-practices.
But this goes back to a comment I made previously about the lack of XSP 
support.
I didn't see anything in Vadim's slides that indicated how to get around 
the lack of XSP support (admittadly, I was looking at the slides through 
Google as my powerpoint viewer seems busted).
>
> A few days ago at ApacheCon's Hackathon event some Cocoon committers 
> have been discussing problem with lack of documentation on migration 
> process. I've expressed my own view that C2.2 is rather major shift 
> compared to C2.1 and so many changes happened in a few years that it 
> would be very hard to just make "brain dump" of few persons in oder to 
> produce good migration procedures. Having said this, I came up with 
> the idea that I (and hopefully others join me) will offer some kind of 
> migration guidance here at user's mailing list.
>
> I was going to announce it officially once C2.2 final release announce 
> is being prepared but I can give you a quick overview of the steps of 
> proposed service:
> 1. The person willing to migrate her app from C2.1 to C2.2 does some 
> basic research on how C2.2 works and how /new/ applications should be 
> created. We have some tutorials explaining this.
Where are these tutorials? Are you talking about the setting up of blocks?
> <snip>
>
> In short: If you have a problem, share it with community and we 
> promise to you that we'll take care of it.
Since you asked ...
I am confused by the RCL goal. I understand that is configures class 
loading, but how does the following line work:

au.com.tt.ccm.cocoon-ccm.service%classes-dir=./target/classes

There is no ./target/classes directory.

Also, I found out that if I add this property:

au.com.tt.ccm.cocoon-ccm.service/contextPath
you can put your sitemap file outside of a jar (at least when using 
Jetty). But I don't know the implications of this, or even what code to 
look at to find out.
>
>> Also, we have most of our files external to Cocoon. And I have said 
>> in the past, I don't want to bundle configuration files with Cocoon 
>> or in JAR files. I was thinking that having a sitemap which points to 
>> external sitemaps. Would this work in a production environment? Could 
>> I register components in these sub sitemaps. I would also like to 
>> have Cocoon look to an external place in the file system for its JAR 
>> files. That is, not bundle it with the WAR file. I have heard 
>> Cocoon2.2 allows this. Does this have benefits in terms of permanent 
>> generation space?
>
> Kamal, what exactly kind of resources you will need to access 
> externally? Is it only a simple configuration file (properties) or 
> something more complicated? Why do you want to access sitemaps that 
> are external to Cocoon application? To be honest, it doesn't make 
> sense to me.
>
The external resources are the XSLTs, sitemaps, etc...

For us, Cocoon has two main purposes - to provide a base for a CForms 
application and to dish out HTML pages (not necessarily related to the 
application). One is that we have an application that written in CForms 
and we dish out HTML pages. We currently bundle part of our application 
with Cocoon (namely, the data access objects). My company would prefer 
not having multiple instances of an application server or managing 
multiple instances of Cocoon in the one application server (I won't go 
into the details). As such, what we currently do is we have a number of 
mount points registered in the mount table file for Cocoon 2.1 and have 
these go off to the separate instances for our clients. This means (with 
the exception of one client) we have one instance of Cocoon in one 
application server, serving multiple clients. Having the files external 
to the main Cocoon war file for each client has been very beneficial. We 
have been able to deploy changes for a client without too much 
disruption, and we have built a process around this that ensures that 
the least number of files are deployed. This has allowed for minimal 
disruption of Cocoon caching. Part of the reason for maintaining the 
status quo is we wish to minimise changes to build processes etc, but 
part of it (for me) is the potential for "hot debugging". If there is a 
problem in a production environment (and I mean a serious problem) it is 
easier to diagnose if I can hop on to the server and modify the 
sitemaps, xslts, etc than if the content is bundled in a jar file.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org