Kamal pisze:
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.
I fear that differences in libraries used by C2.1 and C2.2 can be quite serious but as I said
someone need to check it.
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).
Oh XSP may be a big problem. I mean, we have XSP block in C2.2 but it was never officially released
and I doubt it will ever get released. It looks like nobody is interested in maintaining XSP these
days when we have different approaches.
Standard question: What features of XSP do you need the most? Yep, I'm thinking about suggesting you
some smooth migration from XSP to something that will satisfy your needs.
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?
Yep. That's not much but give you some starting point and should clearly suggest that C2.2 is all
about blocks. Your application should basically consists of a few blocks of the structure the same
as standard Cocoon blocks has.
The most urgent issue is documentation of SSF that plays very important role in C2.2. We have some
bits already but documentation process stopped because all of us are busy with COCOON-2176 issues
which is our major problem at the moment. Once we are done with it I'm going to continue my work on
SSF docs.
Since you asked ...
I am confused by the RCL goal. I understand that is configures class
loading, but how does the following line work:
Yep. Actually it configures classreloading and setups basic webapp env for running Cocoon blocks
because Cocoon block is not a full servlet application that can be executed by Servlet container.
au.com.tt.ccm.cocoon-ccm.service%classes-dir=./target/classes
There is no ./target/classes directory.
There is. You will find it in myBlock directory once you execute:
mvn jetty:run (or at least mvn cocoon:prepare)
It points to the directory where mvn compiles classes.
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.
It uses Spring property overriding[2] functionality of Spring Configurator. Basically it overrides
default value of contextPath property of bean named au.com.tt.ccm.cocoon-ccm.service. You can find
configuration of this bean in
myBlock/src/main/resources/META-INF/cocoon/spring/block-servlet-service.xml
It's totally safe to use your own value pointing to some directory in file system here. Basically,
contextPath points to the base directory for your block and it can be anywhere you want.
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.
Exactly the same should be achieved using blocks. One block for each application, routings to
applications (blocks) could be set in mountPath property of Servlet. See [3] for some details how it
works.
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.
I see your arguments here. Your requirements could be perfectly met by OSGi integration we planned
for Cocoon for years now. Then you could install your blocks without restarting the server and only
one application would get affected by redeployment. However, OSGi integration is not an easy topic
and we decided to leave it for upcomming releases.
As you already figure it out you could point SitemapServlets to external locations for block content
overrding contextPath. I think it's quite sane options and you should get what you are looking for.
There would be one issue remaining: each time you add a new sitemap, you need a new SitemapServlet
configuration that will handle this new sitemap. That means you would still need restart your
servlet container if any new sitemap is being created. I think it's not that a big problem, right?
Even everything should work fine with such setup I would suggest to you to stay as close as possible
to standards that Cocoon is now trying to establish. I'm talking here about directory layout and
blocks. If you want block contents to be outside the JAR it's fine but keep directory structure
standard so once we get OSGi running in Cocoon your migration process will be much, much smoother.
I hope I helped you a little.
[1] https://issues.apache.org/jira/browse/COCOON-2176
[2]
http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurator/1.0/1312_1_1.html
[3]
http://cocoon.apache.org/subprojects/servlet-service/1.0/servlet-service-impl/1.0/1412_1_1.html
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
