You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Giacomo Pati <gi...@apache.org> on 2006/11/07 11:14:29 UTC

Property overwriting mechanism

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all

I've tested the block archetype (and made it more Spring like).

There seems to be a problem with it!

The
src/main/resources/META-INF/cocoon/spring/demo-application-context.xml
looks like this:

<beans>
        <bean id="demo" class="demo.MyBean" scope="singleton">
                <property name="message" value="This is a message coming from a Spring bean."/>
        </bean>
</beans>

and I've place a
src/main/resources/META-INF/cocoon/spring/demo-application-context.properties
next to it that looks like this:

demo/message=This is a overwritten message coming from a Spring bean.

I've expected the overwritte message text to appear in the browser but got:

BoundedThreadPool0-1 ERROR cocoon - Internal Cocoon Problem
org.springframework.beans.factory.BeanInitializationException: Could not process key 'demo/message' in PropertyOverrideConfigurer; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean
 named 'demo' is defined
Caused by:
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'demo' is defined
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:355)
        at org.springframework.beans.factory.config.PropertyOverrideConfigurer.applyPropertyValue(PropertyOverrideConfigurer.java:139)
        at org.springframework.beans.factory.config.PropertyOverrideConfigurer.processKey(PropertyOverrideConfigurer.java:127)
        at org.springframework.beans.factory.config.PropertyOverrideConfigurer.processProperties(PropertyOverrideConfigurer.java:99)
        at org.apache.cocoon.core.container.spring.CocoonPropertyOverrideConfigurer.postProcessBeanFactory(CocoonPropertyOverrideConfigurer.java:126)
        at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:416)
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:330)
        at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156)
        at org.apache.cocoon.core.container.spring.CocoonWebApplicationContext.<init>(CocoonWebApplicationContext.java:70)
        at org.apache.cocoon.core.container.spring.avalon.SitemapHelper.createContainer(SitemapHelper.java:180)
        at org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage.build(SitemapLanguage.java:340)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:349)
        at $Proxy1.build(Unknown Source)
        at org.apache.cocoon.components.treeprocessor.TreeProcessor.buildConcreteProcessor(TreeProcessor.java:389)
        at org.apache.cocoon.components.treeprocessor.TreeProcessor.setupConcreteProcessor(TreeProcessor.java:323)
        at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:231)
        at org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:368)
        at org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:150)
        at org.apache.cocoon.servlet.SitemapServlet.service(SitemapServlet.java:41)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
        at org.apache.cocoon.bootstrap.servlet.ShieldingServlet.service(ShieldingServlet.java:95)
        at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:423)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:867)
        at org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(MultipartFilter.java:104)
        at org.apache.cocoon.bootstrap.servlet.ShieldingServletFilter.doFilter(ShieldingServletFilter.java:50)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:858)
        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:348)
        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:195)
        at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:164)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:536)
        at org.mortbay.jetty.Server.handle(Server.java:309)
        at org.mortbay.jetty.Server.handle(Server.java:285)
        at org.mortbay.jetty.HttpConnection.doHandler(HttpConnection.java:364)
        at org.mortbay.jetty.HttpConnection.access$1600(HttpConnection.java:46)
        at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:612)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:485)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:194)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:298)
        at org.mortbay.jetty.nio.SelectChannelConnector$HttpEndPoint.run(SelectChannelConnector.java:710)
        at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:412)

Has this ever been tested or am I doing something completely wrong????

Ciao

- --
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.5 (GNU/Linux)

iD8DBQFFUFyELNdJvZjjVZARAgr3AJ0Y+6KqaoWWBDYH0mKCQIKEuPZw/ACfaMHi
evgkPt47XqUTPhy0zo3eIO4=
=T/9Z
-----END PGP SIGNATURE-----

Re: Property overwriting mechanism

Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Carsten Ziegeler wrote:
> Giacomo Pati wrote
> 
>>> Strange! When I wrote the CPOC some weeks ago I did not experience these
>>> problems. It "just worked" :) The post processing is the final phase of
>>> setting up the application context, so this should happen only once.
>>> Could it be that now the whole context is instantiated anew on each request?
>> Honestly I have no idea as I have not changed any code that initiates 
>> something, juts fixes broken thing.
>>
> I'll try to have a look over the weekend.

No need for. After a short debugging session this morning it seems all is
running smooth again (CPOC is just called once per startup and once for a
specific sitemap).

Enjoy your free weekend ;-)

Ciao

- --
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.5 (GNU/Linux)

iD8DBQFFUZAiLNdJvZjjVZARApNqAJ9UuIW1fUCKNpouvwXCoqPW3fTbXQCfWxJ5
EIPn9TrZSGD/9IaJjS7i/hg=
=5nYt
-----END PGP SIGNATURE-----

Re: Property overwriting mechanism

Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati wrote

>> Strange! When I wrote the CPOC some weeks ago I did not experience these
>> problems. It "just worked" :) The post processing is the final phase of
>> setting up the application context, so this should happen only once.
>> Could it be that now the whole context is instantiated anew on each request?
> 
> Honestly I have no idea as I have not changed any code that initiates 
> something, juts fixes broken thing.
> 
I'll try to have a look over the weekend.

Carsten

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

Re: Property overwriting mechanism

Posted by Giacomo Pati <gi...@otego.com>.
On Wed, 8 Nov 2006, Carsten Ziegeler wrote:

> Date: Wed, 08 Nov 2006 06:01:14 +0100
> From: Carsten Ziegeler <cz...@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Property overwriting mechanism
> 
> Giacomo Pati wrote:
>>
>>
>> Leszek Gawron wrote:
>>>> Giacomo Pati wrote:
>>>>> Ok, I think I've found the bug.
>>>>>
>>>>> The CPOC had a section where it was *always* loading the general overwriting
>>>>> properties files. This has lead to the NoSuchBeanDefinitionException during
>>>>> request handling where a different beanFactory (the one for the sitemap, not
>>>>> the global one) was used which didn't had the bean trying to overwrite!
>>>>>
>>>>> So far I've committed this fix.
>>>>>
>>>>> Question remaining:
>>>>>
>>>>> Is it necessary to load those property files (probably for the sitemap
>>>>> beanFactory) for each request?
>>>> IMO once the context is up an running it should not be post processed again.
>>
>> I have the same oppinion but during my debugging sessions with the CPOC I've
>> seen that (probably the beanFactory for that sitemap) is processed for each
>> request!
>>
> Strange! When I wrote the CPOC some weeks ago I did not experience these
> problems. It "just worked" :) The post processing is the final phase of
> setting up the application context, so this should happen only once.
> Could it be that now the whole context is instantiated anew on each request?

Honestly I have no idea as I have not changed any code that initiates 
something, juts fixes broken thing.

-- 
Otego AG                                  Tel:   +41 (0)1  240 00 55
Giacomo Pati, CTO                         Mobile:+41 (0)79 262 21 04
Apache Software Foundation Member         Mailto:giacomo@apache.org
Hohlstrasse 216                           Mailto:Giacomo.Pati@otego.com
CH-8004 Zürich                            http://www.otego.com

Re: Property overwriting mechanism

Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati wrote:
> 
> 
> Leszek Gawron wrote:
>>> Giacomo Pati wrote:
>>>> Ok, I think I've found the bug.
>>>>
>>>> The CPOC had a section where it was *always* loading the general overwriting
>>>> properties files. This has lead to the NoSuchBeanDefinitionException during
>>>> request handling where a different beanFactory (the one for the sitemap, not
>>>> the global one) was used which didn't had the bean trying to overwrite!
>>>>
>>>> So far I've committed this fix.
>>>>
>>>> Question remaining:
>>>>
>>>> Is it necessary to load those property files (probably for the sitemap
>>>> beanFactory) for each request?
>>> IMO once the context is up an running it should not be post processed again.
> 
> I have the same oppinion but during my debugging sessions with the CPOC I've
> seen that (probably the beanFactory for that sitemap) is processed for each
> request!
> 
Strange! When I wrote the CPOC some weeks ago I did not experience these
problems. It "just worked" :) The post processing is the final phase of
setting up the application context, so this should happen only once.
Could it be that now the whole context is instantiated anew on each request?

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

Re: Property overwriting mechanism

Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Leszek Gawron wrote:
> Giacomo Pati wrote:
>> Ok, I think I've found the bug.
>>
>> The CPOC had a section where it was *always* loading the general overwriting
>> properties files. This has lead to the NoSuchBeanDefinitionException during
>> request handling where a different beanFactory (the one for the sitemap, not
>> the global one) was used which didn't had the bean trying to overwrite!
>>
>> So far I've committed this fix.
>>
>> Question remaining:
>>
>> Is it necessary to load those property files (probably for the sitemap
>> beanFactory) for each request?
> 
> IMO once the context is up an running it should not be post processed again.

I have the same oppinion but during my debugging sessions with the CPOC I've
seen that (probably the beanFactory for that sitemap) is processed for each
request!

- --
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.5 (GNU/Linux)

iD8DBQFFULANLNdJvZjjVZARAmpCAJ9nlr7LQq8Uo4hpno+d3QPJRsY+HwCg1nQy
hyPPgoMY+3/oM2hnIsGp/DE=
=a3uL
-----END PGP SIGNATURE-----

Re: Property overwriting mechanism

Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> Ok, I think I've found the bug.
> 
> The CPOC had a section where it was *always* loading the general overwriting
> properties files. This has lead to the NoSuchBeanDefinitionException during
> request handling where a different beanFactory (the one for the sitemap, not
> the global one) was used which didn't had the bean trying to overwrite!
> 
> So far I've committed this fix.
> 
> Question remaining:
> 
> Is it necessary to load those property files (probably for the sitemap
> beanFactory) for each request?

IMO once the context is up an running it should not be post processed again.

-- 
Leszek Gawron                                    CTO at MobileBox Ltd.

Re: Property overwriting mechanism

Posted by Giacomo Pati <gi...@apache.org>.
Ok, I think I've found the bug.

The CPOC had a section where it was *always* loading the general overwriting
properties files. This has lead to the NoSuchBeanDefinitionException during
request handling where a different beanFactory (the one for the sitemap, not
the global one) was used which didn't had the bean trying to overwrite!

So far I've committed this fix.

Question remaining:

Is it necessary to load those property files (probably for the sitemap
beanFactory) for each request?

Ciao

Giacomo Pati wrote:
> I've debugged a little further on.
> 
> I've figured that the method CocoonPropertyOverrideConfigurer#postProcessBeanFactory
> is called once during startup and once for each request (is that necessairy to load
> and process it for every request????).
> 
> The call during startup is processed correctly (to my limited knowledge) as it can
> find the bean for the overwriting property values.
> 
> But, the beanFactory passed into mentioned method at request time is a different
> one and doesn't has the bean in question. So the underlying Spring machinery throws
> a NoSuchBeanDefinitionException.
> 
> Carsten, is the beanFactory passed into mentioned method above at request time the
> one specific to a sitemap? The base PropertyOverrideConfigurer class
> CocoonPropertyOverrideConfigurer extends from has a set setIgnoreInvalidKeys()
> method to prevent throwing such an exception, but is this feasable to do?
> 
> Ciao
> 

-- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

Re: Property overwriting mechanism

Posted by Giacomo Pati <gi...@apache.org>.
I've debugged a little further on.

I've figured that the method CocoonPropertyOverrideConfigurer#postProcessBeanFactory
is called once during startup and once for each request (is that necessairy to load
and process it for every request????).

The call during startup is processed correctly (to my limited knowledge) as it can
find the bean for the overwriting property values.

But, the beanFactory passed into mentioned method at request time is a different
one and doesn't has the bean in question. So the underlying Spring machinery throws
a NoSuchBeanDefinitionException.

Carsten, is the beanFactory passed into mentioned method above at request time the
one specific to a sitemap? The base PropertyOverrideConfigurer class
CocoonPropertyOverrideConfigurer extends from has a set setIgnoreInvalidKeys()
method to prevent throwing such an exception, but is this feasable to do?

Ciao

-- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

Re: Property overwriting mechanism

Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Leszek Gawron wrote:
> Giacomo Pati wrote:
>> Has this ever been tested or am I doing something completely wrong????
> Judging by the fact that the override configurer was using wrong running
> mode the class probably has never been put under much 'stress'.

I'm not even there to use a running mode with it :-(

Ciao

- --
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.5 (GNU/Linux)

iD8DBQFFUGkTLNdJvZjjVZARAuFpAJ9pEbbJk1LmGjdoVa86TXwux+LGQwCgoyy3
pWmEoft9w0tGpbx3dc7qhbY=
=Nthb
-----END PGP SIGNATURE-----

Re: Property overwriting mechanism

Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> Has this ever been tested or am I doing something completely wrong????
Judging by the fact that the override configurer was using wrong running
mode the class probably has never been put under much 'stress'.

-- 
Leszek Gawron                                    CTO at MobileBox Ltd.