cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: multiple cocoon contexts
Date Fri, 28 Sep 2001 09:04:17 GMT
Jeremy Quinn wrote:
> 
> Dear All,
> 
> I assume it is not a good idea to run multiple Cocoon 2 contexts in
> TomCat4, just to be able to arrange for unique URLs for separate projects.
> 
> It works OK, but I imagine it unnecessarily uses a lot more RAM.
> 
> Is this so?

Yes. Almost everything but static methods (which are almost never used
exactly to allow Cocoon to run in such a situation) are duplicated.

As for classpath operation, each class, even if it has the exact same
name (say org.apache.cocoon.Cocoon) is treated as a different class if
it was loaded from a separate classloader (this is to avoid collision on
versioning, since you might be able to run Cocoon1 *and* Cocoon2 on two
different context under the same JVM).

So, while this behavior is a *good* thing since avoids a bunch of
problems (Note: this only works on Tomcat 4.0 since it's the only
servlet container that is so advanced on classloading management, at
least the only one I know of) it's up to you to understand if this good
for you or not.

Mainly, this feature was estimated for ISP which might want to run
different Cocoon's depending on different clients, but, even so, this is
a rare situation and probably a good policy file would be enough to
guarantee security.

Anyway, I assume this will come up a lot in the future as Cocoon gets
more ready for production. 

In that case, making Tomcat avalon-aware (or maybe, simply placing
avalon and Cocoon components in the /tomcat/lib directory instead of in
that of web-apps, might allow us to share memory intensive components
such as cache, object pooling and such. Don't quote me on this, there
might be places where this doesn't work right out of the box, but it's
an idea to implement a short-of shared memory beteween webapps where
security is not a big concern but memory consumption is.

But only usage on the field will tell what is best and what is
desirable, so I'll wait to see what happens before planning
architectural or distribution changes.

Hope this helps.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

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


Mime
View raw message