cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Cocoon Maven plugin - Merging deployer & rcl
Date Wed, 02 May 2007 11:33:49 GMT
Giacomo Pati wrote:
> Reinhard Poetz wrote:
>> Giacomo Pati wrote:
> 
>>> Is it ok to set the path back to what it was or did you had some
>>> reason to change it?
>> some time ago we decided to have all or stuff under META-INF/cocoon. I
>> don't think that this should be an exception, shouldn't it?
> 
> Ok.
> 
>>>> Sure, and I'll do my best to find the missings ;-)
>>> Now, next thing I stumbled over is an exception that says:
>>>
>>> 2007-05-02 12:11:11 [ERROR] btpool0-3 cocoon - Internal Cocoon Problem
>>> org.apache.cocoon.ProcessingException: Failed to process pipeline
>>>         at [TransformerException] -
>>> resource://org/apache/cocoon/forms/resources/forms-field-styling.xsl:86:69
>>>
>>> ...
>>> Caused by: org.apache.xml.utils.WrappedRuntimeException: Could not
>>> find variable with the name of
>>> dojo-resources
>>>         at
>>> org.apache.xpath.operations.Variable.fixupVariables(Variable.java:146)
>>> ...
>>>
>>> Did any change messed up with the variable dojo-resources?
>> Grek, could you comment on this please?
> 
> See my other mail.
> 
> After hopefully fixing my flowscripts and sitemaps according to the new resource accessing
URIs I get:
> 
> java.lang.IllegalStateException: BeanFactory not initialized or already closed - call
'refresh'
> before accessing beans via the ApplicationContext
>         at
> org.springframework.context.support.AbstractRefreshableApplicationContext.getBeanFactory(AbstractRefreshableApplicationContext.java:120)
>         at
> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:687)
>         at org.acegisecurity.util.FilterChainProxy.obtainAllDefinedFilters(FilterChainProxy.java:220)
>         at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:135)
>         at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
>         at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
>         at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:358)
>         at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:231)
>         at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:629)
>         at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:453)
>         at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
> ...
> 
> Now this seems to me that some changes with the RCL prevents third party servlet filters
to access
> the ApplicationContext, or am I wrong?

no, that's my interpretation of the stacktrace too

> Any pointers?

The problem is that when the app context gets reloaded, there is a time frame, 
when the context is not available. At the moment I only have a vague idea how we 
can prevent e.g. the acegi filter from accessing a (temporarily) non-existing 
context.
Maybe we can provide some kind of wrapper for the app context that locks the 
access to the app context in question for the time of reinitializiation.

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Mime
View raw message