Leszek Gawron wrote:
> 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)
Ok, I see - obviously we can't patch the web.xml at runtime as its too
late then, so this has to be done during deployment (or packaging).
I think we could leave this functionality in the our plugin for now, but
I would love to have such support directly in the maven webapp plugin.
The same for the shielded classloading stuff. This would free us from
having to use Cocoon specific plugins for non-Cocoon specific things.
> 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?
>
Does this work in Spring? I briefly looked at the code but did not find
support for patterns when using the classpath protocol. *If* this is
working we can directly read these files from within the jars without
need to extract anything. That should be simple.
> 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.
Yepp.
> Could the archetype stop putting cocoon.xconf into generated webapp?
It does not do this anymore (since monday) :)
> 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).
Yes we should do something with the logging configuration as well, agreed.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
