cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <pati_giac...@yahoo.com>
Subject Re: classpath-attribute (was C2: install problem)
Date Sat, 09 Dec 2000 15:22:38 GMT

--- Berin Loritsch <bloritsch@infoplanning.com> wrote:
> ----- 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?

As a non native english speaker I don't get what you mean by attitute. 

> 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.

Well, if we have to change code for servlet engine X this way and for
engine Y the other way then NO.

> 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".

Ok, I see your point.

> The smart webapp deployer will remove all non-essential entries
> anyway.

Sure.

> 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.

<shudder>

> 
> 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.

Ok, lets think how we can do that. Is it possible to do that at build
time (build.xml)? 

Giacomo

=====


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Mime
View raw message