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
--------------------------------------------------------------------
