cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@infoplanning.com>
Subject Re: classpath-attribute (was C2: install problem)
Date Fri, 08 Dec 2000 16:00:31 GMT
----- Original Message ----- 
From: "Giacomo Pati" <pati_giacomo@Yahoo.com>
To: <cocoon-dev@xml.apache.org>
Sent: Friday, December 08, 2000 10:35 AM
Subject: Re: classpath-attribute (was C2: install problem)


> 
> --- Berin Loritsch <bloritsch@infoplanning.com> wrote:
> > Robin Green wrote:
> > > 
> > > Shouldn't this be a list which you can add to, rather than a single
> > > selectable thing? There's no need to force the user to configure
> > that when
> > > you could just read each property in turn.
> > 
> > That list would get pretty daunting fairly quickly, and only serve to
> > slow
> > down the init time of an already complex servlet.  In the long run,
> > it is
> > better for someone to learn their servlet engine.  As a matter of
> > course,
> > the install directions should always list the proper settings for
> > this
> > init parameter.
> 
> Is it really costly to check some properties at init time even if we
> had 20 or 30 different servlet engines (will there be more than that)?

Do I smell an attitude?

Anyway, The thing is I don't want to get us into a place where we have
to change CODE to get Cocoon working with Servlet Engine X.  That is
the main concern.  Now, where do you want all this information?
Cocoon.xconf? web.xml?  Don't say CocoonServlet.java because that is
a maintenance nightmare.

I don't have anything against including that information in the
distribution, I just don't want us to be in a position where all these
things are hard-coded.  Servlet specific Classpath Attributes are here
to stay, but let's not code ourselves in a corner with it in the name
of "convenience".

The smart webapp deployer will remove all non-essential entries anyway.
We could also have security nightmares with teenagers hacking servlet
engines to put their jars in a classpath-attribute that has a higher
priority because it is picked first.

My admonition is BE SMART!!!!

How about we implement a solution where there are many values for
classpath-attribute, and the discerning user can remove anything they
don't want.


Mime
View raw message