Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 73743 invoked by uid 500); 31 Jan 2003 09:37:18 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 73683 invoked from network); 31 Jan 2003 09:37:15 -0000 Message-ID: <3E3A2A1E.6080706@apache.org> Date: Fri, 31 Jan 2003 08:47:42 +0100 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org Organization: Apache Software Foundation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org CC: sylvain@apache.org Subject: Re: Unblocking Blocks - microstep 1 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Pier Fumagalli wrote: > On 30/1/03 9:09, "Nicola Ken Barozzi" wrote: > >>Starting the blocks walk done with microchanges. > > > Yeah! :-) > > >>microstep 1: loading of components from blocks >>-------------------------------------------------- >> >>goal >>------ >> >>The goal is that if I specify: >> >> >> >> >> >>then the sitemap processor will >> >>* look in WEB_INF/blocks for the block jars >>* load the batik-block.jar classes >>* load the avalon components therein specified in a >> cocoon.xconf file in the block jar >> >>Note: All other features like versioning, download (of the block and >>realted jars), etc will be another microstep. > > > 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. >>benefits >>---------- >> >>No more need to recreate the cocoon.jar after the blocks build. This >>will make cocoon.jar really indipendent from the blocks. > > Shall we think about layering better the build system? It's not the build system, it's that cocoon.jar now needs that all Avalon components be inserted in a property file in cocoon.jar. This is why I want to do this microstep ;-) >>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. >>2. Where does the treeprocessor actually create these components? ;-P >> It seems that methods are calling methods that are... you get the >> picture... I've got not much time to dwelve into that code, but >> I looked at the DefaultTreeBuilder.java, but still I'm puzzled. >> >> Can someone please help me and explain how Cocoon uses-handles >> the ComponentManager(s), and how the TreeProcessor works? > > On that, I can't help you mate, but once you figure something out, I can > help you writing some code for it! :-) Sylvain? (the Source ;-) -- 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