Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Thu, 12 Jan 2006 22:12:05 +0100 (CET)
From: Giacomo Pati <giacomo@apache.org>
Sender: giacomo@lapgp.otego.com
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user's point of
 view
In-Reply-To: <43C6BFAD.1080102@nada.kth.se>
Message-ID: <Pine.LNX.4.64.0601122153250.8085@lapgp.otego.com>
References: <20060112094456.31051.qmail@web26812.mail.ukl.yahoo.com>
 <Pine.LNX.4.64.0601122008550.8085@lapgp.otego.com>
 <43C6BFAD.1080102@nada.kth.se>
X-GPG-PUBLIC_KEY: 
 http://pks.gpg.cz:11371/pks/lookup?op=get&search=0x2CD749BD98E35590
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: ClamAV version 0.88,
 clamav-milter version 0.87 on smtp-08.tornado.cablecom.ch
X-Virus-Status: Clean
X-DCC-spamcheck-01.tornado.cablecom.ch-Metrics: smtp-08.tornado.cablecom.ch
 32700;
	Body=1 Fuz1=1 Fuz2=1
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 12 Jan 2006, Daniel Fagerstrom wrote:

> Date: Thu, 12 Jan 2006 21:44:29 +0100
> From: Daniel Fagerstrom <danielf@nada.kth.se>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Block deployment: working with blocks from a user's point of view
> 
> Giacomo Pati skrev:
> ...
>>  Where should .xconf file be located so they will be included?
>
> There is a working example of the blocks architecture that runs under
> servletunit (and soon under Jetty) at
> cocoon-blocks-fw/src/test/resources/org/apache/cocoon/blocks

Ok.

> It is not yet adapted to Reinhards latest naming and directory
> structure, but most things are the same. The only configuration file
> with predifined position is wiring.xml at the servlet context root 
> (/WEB-INF/wiring.xml in Reinhards
> document IIUC). The wiring.xml can give
> expilcit locations for the blocks, otherwise they have the default
> location /WEB-INF/blocks/.
>
> In each block there is a block desciptor located at /COB-INF/block.xml 
> relative to the block context root (which was given in wiring.xml or by 
> default).
>
> As a side note I would prefer to use /WEB-INF/block.xml instead as the 
> container for a single block, (after the ongoing refactoring) will be servlet 
> that can be run independently as long as it not connects to other blocks.

In Reinhards document it is META-INF/block.xml on the Wiki it's 
COB-INF/block.xml. So we need to make a decision:-)

> Now to answer your question ;) the position of the .xconf of a block is 
> defined in the components element of block.xml.

Ok, looking at [1] it is defined in the block.xconf file, which is 
located in COB-INF (or WEB-INF or META-INF respectively). Is that still 
correct?

>>  Do we need a different mechanism to include those (is copying over to the
>>  Cocoon WEB-INF/xconf an option for rapid development)?
>
> For blocks the component configuration file is intended to be fixed and 
> included in the block jar. So it is never copied anywhere as in 2.2 before 
> M2. User configurability is solved with using block properties in the 
> configuration file instead. Whether this will be enough is an open question. 
> But I guess most agree with that the copy and modify approach to 
> configurations in 2.1 not is the way to go.
>
> For rapid development the wiring.xml (or some development time equivalent) 
> should point to the source code of the respective blocks, rather than on some 
> packaged and deployed blocks.

Forget it. The current inclusion mechanism with the xconf directory in 
WEB-INF is obsolete I guess.

>>  How can one ev. define logkit.xml stuff if they want to have their own
>>  logging factory/target/category for the components defined in the block
>>  (asuming logkit is still the main logging system in Cocoon)?
>
> That is an open question, we have not discussed that much. In the current 
> implementation I have just reused the existing Cocoon mechanism with 
> centralized log configurations in /WEB-INF, and is feeding the Logger to all 
> the blocks. But I would much prefer to distribute configurations and maybe 
> even choice of logging framework to the individual blocks. OTH completely 
> distributed logging with numerous log strategies in the same applications, 
> will be nightmare when trying to see what got wrong so some level of 
> centralization is required.
>
> WDYT?

I'd pretty much like distributed logging configuration (whereas
distributed logging implementation might be overkill).

>>  Same applies to stuff going into web.xmlof the context?
>
> After the refactoring I actually use the ServletContext, with a few extra 
> methods for all block context information and inter block communication. 
> Everything isn't implemented yet, but the idea is that the individual blocks 
> get a context object that wrapps the servlet context from the container and 
> in some cases add and in some cases overide the content of that.
>
> But this is also a rather open question. The current implementation uses the 
> o.a.c.core.Settings interface that Carsten have developed and that have a 
> rather neat impelemntation where you can combine the web.xml parameters with 
> Java properties. But the bad thing about it in the block context is that it 
> is centralized. We need to discuss what settings that need to be centralized 
> and what we want to handle on the block level.

One thing of the web.xml is configuration stuff that is passed to the 
Servlet (which is Cocoon) deployed. This is not troubling me (we do have 
other mechanisms to pass down configuration values as you've described).

The other thing is container configuration as defined by the Servlet 
Spec (security, mime types, and alike). Blocks might want to define 
security policies for the URL they are mounted on.

[1] http://wiki.apache.org/cocoon/BlocksDefinition

- -- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDxsYmLNdJvZjjVZARAo+7AKCKTY/8FaoCrBm8FFsGr8CxSZFdOwCdFBGa
9edo/yT4f8tCR93QHKg2nFE=
=Jv8k
-----END PGP SIGNATURE-----