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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
