cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Unblocking Blocks - microstep 1
Date Fri, 31 Jan 2003 15:08:01 GMT


Pier Fumagalli wrote:
> "Nicola Ken Barozzi" <nicolaken@apache.org> wrote:
> 
>>Pier Fumagalli wrote:
>>
>>>The only thing I have "against" this is to start thinking about making
>>>"WEB-INF" an optional feature (all throughout the code)... It should be a
>>>configurable feature.
>>>
>>>The "web application" concept collides with a "full-server" concept...
>>>Web-Applications were designed to allow multiple web-applications in the
>>>same container...
>>>
>>>With blocks, web applications are "redundant" (not to say, obsolete). Sooo,
>>>let's try to think about a possible non-web-application layout...
>>
>>Suggestions?
>>
>>The fact is that cocoon.xconf was moved to WEB-INF for security reasons.
>>In that servlet environment I would surely move the blocks under
>>WEB-INF. IMHO it's simple enough to imagine that in all other
>>environments we have a COCOON-INF dir that mimics the WEB_INF one.
> 
> 
> 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.

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.

>>>>issues
>>>>---------
>>>>
>>>>Small step, but already there are issues.
>>>>
>>>>1. when we will enable versioning, we can have that a block uses
>>>> a version of some libraries, and others another.
>>>> This mean that we have to load the blocks with different
>>>> classloaders, right?
>>>
>>>Correct... And each classloader should work in the "web-application" mode:
>>>check _HERE_ first, and _THEN_ go to the parent classloader... It's not a
>>>big issue though, it could be a problem if we want to start "live reloading"
>>>of blocks, or pass instances of the same class around between different
>>>blocks...
>>
>>yup, let's KISS for now.
> 
> 
> 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.

> 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 :-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message