cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: idle suggestion on building webapps with c2
Date Mon, 11 Feb 2002 09:57:58 GMT
On Sun, 10 Feb 2002, Donald Ball wrote:

> i've been thinking recently on what it's like to get starting with c2, and
> what one has to do to build a new webapp using c2. i just scanned the bulk
> of the c2 user docs and note that there's nothing that tells you how to
> get started building your own webapp using c2. it's easy and
> well-documented how one installs the c2 sample webapp, but that's only
> half of the story, and maybe not even the best starting point for a new
> webapp. i guess the idea is that users are supposed to take the sample c2
> webapp, rip out the sample stuff and modify it for their own purposes.
> and at least one useful option, precompiling the sitemap and xsp pages, is
> only easily available to users if they choose that approach and continue
> to use c2's build file and directory structure in their webapp.

I've posted recently how we setup a C2 dev infractructure. The main
points to controll are:

cocoon.xconf
sitemap.xmap
logkit.xconf
web.xml
WEB-INF/lib
WEB-INF/classes

For cocoon.xconf it would be convenient to have a similarity as with the
user-roles attribute to define ones own cocoon.xconf extension so you
don't have to edit the original cocoon.xconf everytime you deploy a
newer Cocoon dist (this needs to setup dummy user-roles and user-xconfs
included in the original cocoon.xconf file).

We rename the sitemap.xmap to something different and install our own
sitemap.xmap which is a root for all our apps (which gets mounted as
sub-sitemaps). You can mount the original sitemap by a match-all rule at
the end of the custom root-sitemap to have access to the samples in a
dev environment.

The logkit.xconf is usually twiddled to get rid of the annoying free
memory announcement of the store.janitore every 10 seconds.

The web.xml needs to be modified in case you use different jdbc drivers
or specifics for your servlet engine (classloader).

WEB-INF/lib and WEB-INF/classes is used to install own jar/classes.

Finally all of our own apps have an deploy ant target to copy the
sub-sitemaps and the necessary xml/xsl/xsp etc. files into the right
place as well as the custom jars/classes for testing.

At the end you have to do the following steps to upgrade to a newer
Cocoon version (well changes introduces from Cocoon version to the next
version will still have to be reflected in the custom config files)

1. remove the old cocoon servlet context
2. expand the new cocoon.war file into that context
3. redeploy your Cocoon customizations into that context. This will
   rename the original sitemap.xmap and copies (or overwrites) others to
   fit into the environments like describbed above
4. redeploy your Cocoon webapps into that context

Step 3 is done in our env with a special module having it's own
ant build.xml.

Step 4 is common to all our Cocoon apps we develop.

This approach can also be used to setup production environment where we
have a special production user which has CVS access to our repos and
does the steps above in a production environment (maybe with special
deployment ant targets for that environment).

> but like i said, that might not be the best approach for new users. for
> one thing, the configuration files and sample content are very thorough
> and complex - not necessarily the best starting point for a new webapp.

I totally agreed here. That's why we have a special root sitemap which
only contains mounts to sub sitemaps (and the original sitemap is also
mounted here)

> the c2 build file is not only responsible for building the c2 sample
> webapp, but also for building the c2 library and documentation, neither of
> which are necessary or even useful for c2 users.

Not sure here. I regularly use the online documentation that comes with
Cocoon as reference and thus use the mounting mechanism to have it at
hand)

> also, the c2 repository
> isn't frozen, it changes. but the user has to fork from the repository
> when they start to build their webapp, and then has to manually keep their
> cocoon configuration files in sync with the distro. that's a hassle.

For some configuration files you have to at the moment (cocoon.xconf,
web.xml). For other you don't have to if you follow the approach above.

> so i was thinking that a (partial) solution would be to make available,
> and maintain, a c2-skeleton distro, with a minimal directory tree and
> configuration files, no sample content, a build file that just builds the
> webapp and can precompile things. sort of a best practices c2 skeleton for
> others to use. something like:
>
> /WEB-INF
>         /etc
>             sitemap.xmap
>             cocoon.xconf
>             logkit.xconf
>         /lib
>             cocoon2.jar
>             ...
>         web.xml
> build.xml

In fact this doesn't free you from updating you configfiles when changes
had occurrend in the CVS. our approach seems to minimize that to the
absolute minimum (with the exception of cocoon.xconf, which doesn't have
a user extension as well as the web.xml file)

> (i suggest hiding the cocoon configuration files under WEB-INF so that
> they'll be more protected in case of a malfunction. there can be passwords
> and such in cocoon.xconf, at the very least.)

That's ok for cocoon.xconf (as there is usually only one) but not sure
about sitemap.xmap (think of sub-sitemaps). If you attemp to use a root
sitemap that has only mounts to subsitemaps, than yes, hiding it could
advance security.

> i know this is a pretty boring and simple suggestion, but based on my
> experiences watching and reading about people trying to get started with
> c2, i think it could help a good bit. i mean, now you, you download the c2
> binary distribution, unpack it, and don't have any roadmap for going
> anywhere after installing the sample webapp. providing a c2 webapp
> skeleton would start to fill that void.

I'm interested in your oppinion about the approach I've mentioned above
(which I like better than the one with a sole skeleton webapp target).

Giacomo


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


Mime
View raw message