[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:       Daniel Fagerstrom <danielf () nada ! kth ! se>
Date:       2006-01-14 10:39:14
Message-ID: 43C8D4D2.1080309 () nada ! kth ! se
[Download RAW message or body]

Giacomo Pati skrev:
> On Fri, 13 Jan 2006, Reinhard Poetz wrote:
>> 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?

+1

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

Or rather /COB-INF/sitemap.xmap, to mark that we access from the block 
context root.

>> and
>>
>> <components class="o.a.c....">
>>  <include>META-INF/block.xconf</include>
>> </components>
>>
>> hmmm, WDOT?

/META-INF/block.xconf for an absolute path and block.xconf for a 
relative path.

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

It is the concern of the controller within the block (in this case the 
SitemapServlet) to interpret the content of the servlet element, for the 
SitemapServlet it would make sense to have /COB-INF/sitemap.xmap as 
default value, still I think that it sometimes can be worthwhile to have 
it user configurable.

> 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

Here it is also the concern of the specific container to interpret the 
content of the components element so the same applies as for the servlet 
  configuration.

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

+1

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

No opinion about this.

/Daniel
[prev in list] [next in list] [prev in thread] [next in thread]