Carsten Ziegeler wrote:
b) META-INF/legacy/xconf/** - Block specific avalon config files
c) META-INF/legacy/sitemap-additions/** - Block specific avalon config
files for sitemap components
d) META-INF/spring/** - Block specific spring config files
e) META-INF/properties/** - Block specific properties
f) META-INF/legacy/cocoon.xconf - The main avalon config file
g) WEB-INF/classes/** - Block specific resources for the classpath
h) WEB-INF/db/** - Support for the hsqldb block
i) META-INF/xpatch/*.xweb - Patches for web.xml
I think we can simplify this a little bit:
- No block should contain a cocoon.xconf - this file is either created
by using an archetype or by directly writing it per hand - so we should
drop the support for f)
- I see no use for g). We can simply put the resources "directly" into
the jar file.
+1
- I have no clue for h) and i) right now, but they are not very common
use-cases.
+1 for h)
My intention for i) was the ability for the block to contribute to
web.xml. You can create yourself a OpenSessionInViewBlock.jar which,
during deployment, will automatically enable the proper filter in
web.xml. As my web.xmls in different projects stay very alike I would
like to extract the common definitions into a reusable artifact.
This goes to any stuff that you need to put into web xml:
- filters
- listeners
- additional servlets (AFAIR some of the users used .xpath files to
include xindice servlets in web.xml)
My common design in: webapp depends on ui-block (contributes COB-INF)
depends on core block (contributes model and spring services) depends on
hibernate and opensessioninview (contributes filters to web.xml)
> - The separation between business components and sitemap components in
avalon is legacy as well, so I think we can all drop them into
"legacy/xconf", but in different configuration files.
+1
- Using "legacy" in the directory structure is fine, but somehow it
seems wrong to me that we use "legacy" during development but not
in the final web application (there we just use WEB-INF/cocoon/xconf).
So we should imho either rename "legacy/xconf" to just "xconf" or
put everything in the resulting webapp under "WEB-INF/cocoon/legacy":
the avalon configuration files and the initial cocoon.xconf.
For the reminder of this mail, I'll use the first solution.
+1
This leaves the COB-INF directory and some configuration directories in
META-INF. I know that we discussed the directory structure many times
but today I think we should put all configuration stuff inside one
single directory; I would suggest to put everything in the
META-INF/cocoon directory (apart from COB-INF):
META-INF/cocoon/xconf/**
META-INF/cocoon/spring/**
META-INF/cocoon/properties/**
I like the idea a lot - it is way clearer now.
Changing this simplifies the deployer as it just has to extract the
META-INF/cocoon directory to WEB-INF/cocoon.
So the final part is how to avoid the maven deploy plugin? We recently
discussed a possible solution which works using some classloader
functionality, some new protocols and so on and does not require any
extraction of files during deployment or runtime. Cocoon would be able
to serve everything directly from the jar files.
First of all: why don't we simply use spring functionality for that?
Spring has a nice resource resolution. Why don't we simply reference
classpath*:/META-INF/cocoon/spring/*.xml for context inclusion and
classpath*:/META-INF/cocoon/properties/*.properties,
classpath*:/META-INF/cocoon/properties/{currentmode}/*.properties
for properties resolution?
This way we can reference the files directly from jar file without the
need to extract it.
Moreover this automatically resolves all current problem for block
development. Currently if you test a development block in isolation none
of the resources are actually deployed into a webapp. Instead everything
is referenced from src/ directory. Everything apart
src/main/resources/META-INF/cocoon/properties/**.
Referencing properties with
classpath*:/META-INF/cocoon/properties/*.properties will also pick
property files from target/classes directory of local block. Poof - the
problem is gone.
While this is a very interesting solution, it has some problems: first
and most important: we have to develop it. As we are lacking resources,
this might take too much time until we have a final version.
So what are our alternatives? I come up with the following three, but
perhaps there are more:
a) We don't care and require people to use maven2 for their development
(or if they don't want to use maven2 they have to figure out how to do it)
b) We support other build system, for example by providing an ant task
doing the same stuff as the maven deployer
c) We implement a simpler solution which works for most people
a) is obviously not a good choice; I'm not sure about b) so I personally
would focus on c). A solution would be to simply extract the files on
startup of Cocoon into the web archive. We already have a place where we
can do this (in the setting up of the properties system of Cocoon which
is the first activity on startup) and implementing this should be fairly
easy.
I have a lot of legacy cocoon based project that I would like to port to
2.2 and without the deployer I had to move all resources from
src/main/resources/META-INF/spring to
src/main/webapp/WEB-INF/cocoon/spring so they get properly detected at
runtime. It would simplify a lot of things for me if we referenced
spring context anywhere on the classpath (in a proper dir of course).
We just have to find a smart way of not extracting everything on each
startup - but that shouldn't be too hard.
The only drawback I see right now is that people that want to run Cocoon
unexpanded can't use this approach. But if someone has the opinion to
run web apps unexpanded is the better approach, we could *for now*
require them to use the maven plugin. We can come up with a better
solution with upcomming versions.
So, wdyt?
Could the archetype stop putting cocoon.xconf into generated webapp? I
have at last 10 projects running 2.2 and never touched this file in any
project. It only gives me headaches when cocoon-core changes and I have
to update it manually from cocoon sources (Last time all my projects
broke after the namespaces have been renamed). That is why I think we
should move the configuration stuff (log4j configuration file location -
why isn't this controlled by properties after all?) out of the file and
either reference it directly from cocoon-core.jar or remove it
completely (create proper beans programatically at runtime).
Currently cocoon.xconf is only modified by cocoon deployer itself when
it creates appropriate imports to load development block resources
directly from source. As I proposed another way of handling it I think
we can drop this feature also.
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
