Thorsten,
Thanks for this helpful reply.
One follow-up question below...
On 3/8/2012 3:32 PM, Thorsten Scherler wrote:
On 03/08/2012 10:09 PM, Lars Huttar wrote:
Thanks, that's very helpful!
We have a lot of what we call "applications" that run side-by-side
under a single Cocoon 2 instance. They each live under a separate
subfolder (child of "mount/") under the main Cocoon sitemap. Each
"application" has its own sitemap.
It sounds like these "applications" actually correspond to the
"blocks" you describe below.
They would make good candidates for blocks after all.
Is it fair to say that a Cocoon "web app" corresponds to one instance
of Cocoon running?
web app I use actually only for packaging to deploy to tomcat.
So a "web app" can consist of several blocks?
web app can have deps to different blocks yes.
However like Robby described you normally end up with the following:
- war block -> web app -> deb to web block
- web block -> block -> deb to all sub blocks (like cocoon-shiro for
auth mgt, ...), providing REST services and gui
- common block -> block -> util, helper, cross cutting concern code
- dao block -> block -> connection to db (in our current customer
project we use jpa over hibernate with a postgres db) providing dto
for the
- ...
What do the "A -> B" arrows mean here ... A has a dependency on B?
Lars
What you describe is like a farm, I have a customer that is hosting
>300 lenya publication in one lenya instance. However I tend to deploy
each cocoon app as war on its own since this way scalability is easier
and you have a finer control over each app.
Now the reason for "farming" is normally that you have common code
that you want to use across the apps. This would be done now in your
common block. The benefit is that you can just declare the dep and you
are ready to use this common code.
It is important to note that consist in c3 context means "declaring
deps to" and the war project is a simple "zombie" that distributes the
work to the blocks.
salu2
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
