Kamal pisze:
Hi,
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.
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.
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.
2. Then it looks at her own application and evaluates how new concepts reflects the design of app
that has to be migrated.
3. Person starts to ask question that I (and other willing join the effort) are happy to answer by
pointing to some documentation and mail archives (there are plenty of good discussions in mail
archives).
4. If some parts of application are hard to evaluate how they should be migrated user creates a
simple C2.1 based application that shows the problem (e.g. some design decision that is hard to be
mapped to C2.2 way of building apps) and I promise to get it running in C2.2 or at least give
detailed instructions how to do it.
In short: If you have a problem, share it with community and we promise to you that we'll take care
of it.
Hopefully, based on experience gained from such process we can prepare some documentation on
migration process that will be based on user's real problems and use-cases.
NOTE: I'll agree to talk privately but only if some sensible information is involved in the
discussion. Otherwise I'll refuse private talks and always ask people to discuss their problems
here, on the mailing list.
Does this sound sane?
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.
Giving answer to your question: I think all of you want to achieve is possible right know but before
I give you some instructions I would love to hear why do need them. I would like you to avoid some
possible mistakes.
[1] http://blog.reverycodes.com/archives/000045.html
--
Best regards,
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
