-----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 <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
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-----
