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
