This is something I always wanted to bring up but never considered it to
be a priority high enough, but as soon as Cocoon2 reaches a status where
it's useable in production sites, people will start asking for something
more user friendly than a WAR file that can get as big as hell.
Let me start saying that I have a love/hate approach with WAR files and
has nothing to do with the acronym which I *very strongly* dislike for
the unfortunate resonance with a terrible thing.
ok, pacifist disclaimer given, I'll being saying that I love the way we
install cocoon in a big file we deploy on all servlet containers. Many
have already personally expressed their happyness to me compared to the
hassle that they required for installation for Cocoon1. This is mainly
given to the webapp deployment concept that latest servlet API include.
So, if you consider Cocoon and its samples a single web application,
this way is perfect and you will never going to need anything else, but
as soon as you start adding your own stuff, you'll find out that Cocoon
is not a single web application but a framework for applications.
In short, as Tomcat is a container for servlet-based web applications,
Cocoon is a container for cocoon-based web applications. The parallel is
evident to me and should *not* require (as Jeremy was asking, clearly
touched by the same feeling) separate cocoon instances just to *deploy*
different cocoon-based web applications.
There is also another reason: while there exist components that are
general enough to be distributed with Cocoon, in some other
circumstances, such components, might well turn out to be to specific
for a particular need (specific actions tight to your own business
logic, or specific transformers that are triggered by some precise
semantic, etc..)
In this respect, there is a big parallel between servlet-based web
applications and cocoon-based web applications: both require a
"deployment descriptor" that gives the container instructions on where
to "mount" it, where to find web-app specific components, libraries and
resources.
Clearly, the sitemap is the closes thing that matches this.
Let's make a solid example: I started integrating my image gallery thing
which now requires 12 (or so) new classes added to the Cocoon
distribution (some 6 new components), but they are general enough to be
useable on many other circumstances, but one component which is simply
too specific to be of any use in other circumstances.
Currently, the operations that we have to do to *install* a new
cocoon-based web application are:
1) prepare a directory with all the required files
2) mount the new web-app sitemap in the sitemap that controls the
URI-space we want to mount our stuff on
3) place our web-app specific components in the folder for new
components (defined in cocoon.conf, if my memory doesn't fail)
4) have the servlet container restart the entire web-application
handled by Cocoon.
While, following the servlet parallel, we should do:
1) have a CWA (Cocoon Web Application) file with a manifest file (or
equivalent thing) that specifies where is the sitemap file (I'm also
happy with forcing the sitemap file to be called sitemap.xmap and places
in the root of the package, thus eliminating the need for such a
manifest file) and contains all the required things (resources,
stylesheets, additional components and libraries, entity catalogs,
etc..).
2) open the cocoon manager (similar to Tomcat 4.0 manager webapp, just
*much* more user friendly) and authenticate (if more security is
required this could be mapped over an SLL-secured connection and
authentication guaranteed by client-side certification, but this is none
of our concern since Cocoon doesn't handle nor should that part of the
HTTP connection).
3) upload the CWA file (unlike Tomcat 4.0 manager which simply requires
you to indicate where the CWA file is on the machine, with upload we can
deploy a CWA from another machine entirely which is a great feature).
4) tell Cocoon to start the deployed CWA
and that's it, without even having to stop Cocoon or even tell the
servlet container about what we are doing.
Of course, Cocoon's classloader should be rearchitected to allow several
"contexts" which different classloaders, this will automatically solve
the issues of having to run multiple cocoon instances to separate the
resolution space of different cocoon-based webapps.
But there are other things that might turn out incredibly useful: almost
everybody works with two copies, one for development and one for
production. The first is used when developing, the second is deployed
and used until changes are required.
Everybody that has real-life working knowledge knows that is almost
impossible to force people to work on a centralized version, expecially
if the easiest way to modify something is to work on what is currently
live.
Currently, the processing cycles are something like:
1) write your webapp under the /cocoon2/ folder
2) use cocoon build file to generate the WAR file (which contains your
stuff as well)
3) deploy that on the servlet container.
but then you note that your stylesheets have something wrong, so you
don't do this over and over (since the cocoon-war file is so big and
restarting the entire crap takes forever and a half) but simply modify
the stylesheets in-place while they are live.
You can bet your ass that you'll forget to copy back the changes to your
original location.
Result: next revision gets deployed, many things that previously worked
well (expecially in sections you didn't touch because they were just
perfect as they were) don't work anymore. This is called: lost update.
One solution is to do the deploying once cocoon2 fresh out of the box,
then install your stuff over on the deployed version.
NOTE: the servlet API doesn't say *anything* about what happens to
deployed files that are subsequently modified after being unpacked from
the WAR. In some circumstances, the container might even erase the
unpacked version when the web-app is stopped or the container is shut
down in order to save space. The Servlet API assume the WAR file and the
unpacked version are the *same* and unpacking occurs only for speed
reasons, not to allow you to modify things live.
So, you installed Cocoon2 fresh, it gets unpacked, you stop tomcat
without shutting down but simply kill -9 it or CTRL-C on the shell, you
add your stuff and work well.
C'mon, this is crap, we must come up with something smarter.
Ok, the idea is: how do I make the files deployed unmodifiable?
My solution is: compile everything. Tranquillity by obscurity.
If you transform all XML files into CompiledXML files (using the code I
wrote for a long time ago and which is now used in the cache system),
not only parsing performance is greatly improved on live sites, but also
we obtain that people will very unlikely modify directly the unpacked
files because they are, in fact, binary.
This also means precompiling sitemaps and XSPs and everything that needs
compilation.
Of course, this is not suitable for close-cycle development of cocoon
web apps: I could not want to have to recompile my entire CWA, deploy,
restart, etc, everytime I have to modify my stylesheet, it would be
foolish to impose this, but on production this makes a real difference,
expecially in those places where carefully scrutinized quality assurance
phases must be performed before something enters production.
In these situations, we must take all the actions to allow packages as
sealed as possible (possibly even crypto-sealed) to be deployed even
remotely on a live site, making also possible to upgrade an existing
package with a new one while the other is running (which is not that
hard to do with carefully designed multi-threading management of
subcontexts).
Currently, development of cocoon webapps is rough and not engineered: is
mostly left to the user ability to manage the process.
In the future, I'd love to make it possible to design the system in such
a way that concerns are well kept separate even during the two stages,
development and production, for example, performing sitemap
interpretation during developement (since no high load is required, but
faster responsiveness at structure changes) while performing sitemap
compilation on deployment. Same thing for compiled XML.
Ok, hope this is enough to start a discussion. If you have any
suggestion to shape the way you will develop, deploy, manage your future
webapps in cocoon, make yourself heard now at design stage so that we
can get down in coding with a clear indication on what the people want
or would like to see.
Ciao.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
