Giacomo Pati wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
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.
Sounds kinda complicated. Where is would such a thing be located in the code?
I've had some more thoughts about this and I believe that we don't need to go
that far. We only have to make sure that all servlets, filters and listeners
that we inject are being rewritten so that they get wrapped by their
"Reloading*" equivalents, e.g. see the dispatcher servlet:
<servlet>
<servlet-name>DispatcherServlet</servlet-name>
<display-name>DispatcherServlet</display-name>
<description>Cocoon blocks dispatcher</description>
<servlet-class>org.apache.cocoon.tools.rcl.wrapper.servlet.ReloadingServlet</servlet-class>
<init-param>
<param-name>servlet-class</param-name>
<param-value>org.apache.cocoon.servletservice.DispatcherServlet</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Carsten added the code that rewrites a web.xml in order to use the shielding
stuff, see org.apache.cocoon.maven.deployer.WebApplicationRewriter.shieldWebapp.
It shouldn't be too difficult to use it for our purpose too.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
