Re: [2.2] Deployment and the maven plugin

[Leszek Gawron <lg...@mobilebox.pl>]

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

Re: [2.2] Deployment and the maven plugin

[Carsten Ziegeler <cz...@apache.org>]

Leszek Gawron wrote:
> 
> It sure is. I am setting up my tools/test cases like this:
> 
Great! So we don't have to extract this stuff! Thanks for the info!
> 
> If you only pointed me to the location where cocoon/spring/* are 
> enumerated I will do the necessary changes.
> 
Ok, I just added initial support - the only thing remaining should be
testing and bug fixing - I can't test right now as I can't build Cocoon
due to the missing artifacts (jci ...) :(

Ok, here the locations:

SettingsBeanFactoryPostProcessor.java
   Read the properties from cocoon/properties and cocoon/properties/{mode}.
   For reading the properties it is calling
ResourceUtils.readProperties(..) in line 189ff

I already added the calls, but I guess ResourceUtils.readProperties
might not handle the classpath* case properly.

SettingsElementParser.java
   This one reads all bean definitions. I added the call to
   this.handleBeanInclude() in line 71 - but handleBeanInclude might
   need some updates to handle the classpath:* protocol.

CocoonPropertyOverrideConfigurer.java
   This one read the properties from cocoon/spring/*.properties for
   overriding bean configurations. I added the calls to
   ResourceUtils.readProperties(..) in line 86ff.

HTH
Carsten

-- 
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [2.2] Deployment and the maven plugin

[Leszek Gawron <lg...@mobilebox.pl>]

Carsten Ziegeler wrote:
> 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.

It sure is. I am setting up my tools/test cases like this:

> public abstract class AbstractSpringTool {
> 	protected static final Log					logger	= LogFactory.getLog( AbstractSpringTool.class );
> 	protected ConfigurableApplicationContext	context;
> 
> 	public AbstractSpringTool() {
> 		this.context = new ClassPathXmlApplicationContext( getContextLocation() );
> 		this.context.getBeanFactory().autowireBeanProperties(	this,
> 																getAutowireType(),
> 																false );
> 	}
> 
> 	public String[] getContextLocation() {
> 		return new String[] { "classpath*:/META-INF/spring/*.xml" };
> 	}
> 	
> 	public int getAutowireType() {
> 		return AutowireCapableBeanFactory.AUTOWIRE_BY_NAME;
> 	}
> 	
> 	public abstract void run() throws Exception;
> }

and property placeholders:

> 	<bean id="placeholderConfig" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
> 		<property name="locations" value="classpath*:META-INF/properties/*.properties"/>
> 	</bean>

works like a charm.

If you only pointed me to the location where cocoon/spring/* are 
enumerated I will do the necessary changes.

You can even use ant style wildcards. The only thing you cannot do is 
classpath*:*.xml. You have to at least reference a single directory in 
the path. The appropriate docs can be found here [1]

>> Could the archetype stop putting cocoon.xconf into generated webapp?
> It does not do this anymore (since monday) :)

Superb. I'll test the changes today.

[1] http://www.springframework.org/docs/reference/resources.html#d0e6335

-- 
Leszek Gawron                                    CTO at MobileBox Ltd.

Re: [2.2] Deployment and the maven plugin

[Carsten Ziegeler <cz...@apache.org>]

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/