[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: Block deployment: working with blocks from a user's point of
From:       Giacomo Pati <giacomo () apache ! org>
Date:       2006-01-13 18:45:38
Message-ID: Pine.LNX.4.64.0601131930200.17502 () lapgp ! otego ! com
[Download RAW message or body]

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

On Fri, 13 Jan 2006, Reinhard Poetz wrote:

> Date: Fri, 13 Jan 2006 19:20:43 +0100
> From: Reinhard Poetz <reinhard@apache.org>
> 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 wrote:
>
>
>>  Ok, seems like we need a structured proposal :-)
>>
>>  1. All files needed at deployment time should go into META-INF
>>     - block.xml
>>     - block.xconf
>>     - xconf/*.xconf (includes? do we need more that one .xconf for a
>>       block?)
>>     - block.xlog (if we do have logging support)
>>     - block.xweb (if we need to patch the web.xml; If we need to have
>>       directives to the servlet container for i.e. security policies,
>>       additional mime-types this won't work here if we have hot
>>       deployment of blocks)
>>     - what else?
>
> hmmm, AFAIU only block.xml and block.xweb are needed at deployment time but I 
> don't have a problem if all those files go into META-INF. The only concern I 
> have is, as said in some other mail, that we have different meanings how 
> relative paths are resolved:

Extend the scope to 'deployment, instatiation and initialization time of 
a block'

> <servlet class="o.a.c.s.SitemapServlet">
>  <sitemap>sitemap.xmap</sitemap>
> <servlet>
>
> and
>
> <components class="o.a.c....">
>  <include>block.xconf</include>
> </components>
>
> Do you see what I mean?
>
> An alternative could be:
>
> <servlet class="o.a.c.s.SitemapServlet">
>  <sitemap>COB-INF/sitemap.xmap</sitemap>
> <servlet>
>
> and
>
> <components class="o.a.c....">
>  <include>META-INF/block.xconf</include>
> </components>
>
> hmmm, WDOT?

May I raise the following questions:

1. Is there a need to have the freedom to indvidually name the root
    sitemap of a block other than 'sitemap.xmap' (I think you can still
    mount sub sitemaps which dont follow that naming pattern)?

If you answer is NO why don't we stick with 'CON-INF/sitemap.xmap'

2. Is there a need for dividing the component configuration of a block
    into multiple files which need to be included (isn't it better to
    split up the block into smaller piecies)?

If your answer is NO why don't we stick with META-INF/block.xconf

>>  2. All file that were NOT supposed to be accessed as normal classloader
>>     resource (the webapp stuff) go into COB-INF
>>     - sitemap.xmap
>>     - **/*.xsl
>>     - **/*.xml
>>     - **/*.css
>>     - and many more
>
> yes
>
>>
>>  3. The rest are normal classloader resources and belongs to the root
>>     - **/*.class
>>     - **/*.properties
>>     - **/*.xml (i.e. internal config file)
>>     - I'm sure there are more
>
> yes

I've missed to place the dependant jars of a block. So I propose they go 
to META-INF/lib with no strong agruments for it but they are needed 
to setup the classloader for the block or to populate the parent 
classloader and that's done at initialization time.

WDYT?

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

iD8DBQFDx/VXLNdJvZjjVZARAjxMAJ9QQs+aeXki2iR9FwYjiYQXqCGY7ACfbULP
lAtZakj/ELIoCMbk/NaqAwM=
=JQ/x
-----END PGP SIGNATURE-----
[prev in list] [next in list] [prev in thread] [next in thread]