Pier Fumagalli wrote:
<snipped-detailed-explanation/>"Nicola Ken Barozzi" <[EMAIL PROTECTED]> 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
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.
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.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.
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
