"Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>> 
>> Somehow, well, yes, but at the same time, no... WEB-INF is (IMO) a hack
> 
> <snipped-detailed-explanation/>
> 
> Yes, the reliance on web.xml is really ugly and stook because we really
> only used it as a servlet for so much time. We have mused sometimes over
> fixing it, but the barrier2start it was too high, given our needs in
> using it as a servlet.
> 
> Your analysis is detailed and correct. If you start moving stuff from
> web.xml out of there, I'm +1 for it.

I'll send out a proposal...

> One thing also: we have a cocoon.xconf that talks about both Cocoon
> "core" components and "non-core" ones. The ones that are non-core should
> move to blocks.
> 
> This will give us the issue about changing configuration for
> block-loaded Avalon components later on.

I didn't catch up with the entire Avalon stuff quite enough to understand
the full extent of what you're saying... Sorry :-(

>> Hm... I was actually thinking whether we wanted it or not last night... I'm
>> thinking, I don't know if cocoon-blocks should be allowed to "rely" on a
>> particular version of a given library... If two blocks use the same lib,
>> they should be using the same version, and both should be using the latest
>> version... I don't know.
> 
> I will always use the latest version, but that's me. In real life you
> will always find blocks that are not managed by us being used, and they
> can rely on any kind of version of a package. It would be a nightmare
> not to make separation possible.

Micro-Step #2 then? :-)

>> If needed, anyohow, I can throw in a ClassLoader
>> implementation (I use it for a thing called "OracleObjects" here at VNU and
>> it does more or less what you need)...
> 
> Ok :-)

WHAT THE HELL AM I SAYING? It's already in CVS (and I spent 3 days rewriting
one for my stuff): org.apache.cocoon.servlet.ParanoidClassLoader

    Pier (dumb code-that-already-exists-rewriter)


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to