You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2007/03/14 00:24:04 UTC
Reloading the mountableServlets map in DispatcherServlet
After more than two days of debugging, many thanks go to Torsten and Carsten who
helped me to track down the problem, I found out, why the reloading classloader
plugin doesn't propertly reload the Spring application context:
The problem is that the DispatcherServlet contains a map of all mountable
servlet services. This map is initialized in the init() method of the servlet
and will never be reloaded. These servlets have a reference to the first Spring
app context and every reset remains without effect.
The simplest solution that I could think of is adding a check whether the system
runs in dev mode. If true, the code, that collects information about all
available servlet services, is executed every time when the service() method is
called. As this doesn't seem to be expensive I think it's at least not the worst
option.
All other solutions would either make the DispatcherServlet dependant from the
ReloadingClassloader stuff or vice verca. But maybe it's only to late here and I
overlook a simple solution.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Reloading the mountableServlets map in DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz napisał(a):
>
> Grek,
>
> I've had some time today and found the reason why the rcl doesn't work
> for you. You are using cocoon-servlet-service-impl-1.0.0-M1 and not the
> latest version from SVN that I had to fix in order to get Spring context
> objects reloaded.
>
> While Carsten and I were walking through the code, he also changed
> things in the cocoon-core modules but I'm sure if this was really
> necessary to get the rcl stuff working.
>
> The best way to test the RCL stuff is trying it out in
> cocoon-rcl-plugin-demo.
>
Argh, What a silly oversight. I remember you warned me about it before
and I ensure that right versions are used for a while. However, I've
been giving it a try so many times that I had to forgot to check
dependencies this time.
I'll check it again just after my GSoC proposal is finished.
--
Grzegorz Kossakowski
Re: Reloading the mountableServlets map in DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz napisał(a):
>> Grzegorz Kossakowski wrote:
>>
>> Grek,
>>
>> I've had some time today and found the reason why the rcl doesn't work
>> for you. You are using cocoon-servlet-service-impl-1.0.0-M1 and not
>> the latest version from SVN that I had to fix in order to get Spring
>> context objects reloaded.
>>
>> While Carsten and I were walking through the code, he also changed
>> things in the cocoon-core modules but I'm sure if this was really
>> necessary to get the rcl stuff working.
>>
>> The best way to test the RCL stuff is trying it out in
>> cocoon-rcl-plugin-demo.
> I'm ashamed. cocoon-rcl-plugin-demo works perfectly on Linux with Java6.
> After correcting the dependencies, block created from archetype works
> too. I could even add new methods and use them :)
> I'm really sorry for wasting your time :-/
no problem :-)
> Now, I would like to ask you for opinion on what should we do in order
> to avoid similar situations. Should docs of cocoon-rcl be changed
> explaining what are the correct dependencies? Or should correct them in
> archetypes? Or both? :)
As soon as we release the modules, the problem will be gone. I've also updated
the docs with a comment saying that one has to use latest
cocoon-servlet-service-impl.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Reloading the mountableServlets map in DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz napisał(a):
> Grzegorz Kossakowski wrote:
>
> Grek,
>
> I've had some time today and found the reason why the rcl doesn't work
> for you. You are using cocoon-servlet-service-impl-1.0.0-M1 and not
> the latest version from SVN that I had to fix in order to get Spring
> context objects reloaded.
>
> While Carsten and I were walking through the code, he also changed
> things in the cocoon-core modules but I'm sure if this was really
> necessary to get the rcl stuff working.
>
> The best way to test the RCL stuff is trying it out in
> cocoon-rcl-plugin-demo.
I'm ashamed. cocoon-rcl-plugin-demo works perfectly on Linux with Java6.
After correcting the dependencies, block created from archetype works
too. I could even add new methods and use them :)
I'm really sorry for wasting your time :-/
Now, I would like to ask you for opinion on what should we do in order
to avoid similar situations. Should docs of cocoon-rcl be changed
explaining what are the correct dependencies? Or should correct them in
archetypes? Or both? :)
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Reloading the mountableServlets map in DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz napisał(a):
>> Another cause might be that I had to comment the rcl modules in
>> trunk/tools/pom.xml in order not to break the build for everybody. In
>> the case that you haven't changed this yourself for you own build, you
>> won't get new artifacts installed.
>>
>> If I have some time this weekend, I will provide a snapshot release
>> and put it on a public Maven repo. Otherwise go to cocoon-rcl-wrapper
>> and cocoon-rcl-plugin base dirs and install both modules from there.
>>
> Oups... There is a little problem with providing necessary information
> because I have no access to my computer during this weekend. However
> I'll try to set up everything on the computer I'm writing this mail from
> and reproduce this problem. If wasn't able to do this I'll give you all
> data on Monday.
Grek,
I've had some time today and found the reason why the rcl doesn't work for you.
You are using cocoon-servlet-service-impl-1.0.0-M1 and not the latest version
from SVN that I had to fix in order to get Spring context objects reloaded.
While Carsten and I were walking through the code, he also changed things in the
cocoon-core modules but I'm sure if this was really necessary to get the rcl
stuff working.
The best way to test the RCL stuff is trying it out in cocoon-rcl-plugin-demo.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Reloading the mountableServlets map in DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz napisał(a):
> Another cause might be that I had to comment the rcl modules in
> trunk/tools/pom.xml in order not to break the build for everybody. In
> the case that you haven't changed this yourself for you own build, you
> won't get new artifacts installed.
>
> If I have some time this weekend, I will provide a snapshot release
> and put it on a public Maven repo. Otherwise go to cocoon-rcl-wrapper
> and cocoon-rcl-plugin base dirs and install both modules from there.
>
Oups... There is a little problem with providing necessary information
because I have no access to my computer during this weekend. However
I'll try to set up everything on the computer I'm writing this mail from
and reproduce this problem. If wasn't able to do this I'll give you all
data on Monday.
--
Grzegorz Kossakowski
Re: Reloading the mountableServlets map in DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> Grzegorz Kossakowski wrote:
>> Gosh, I have bad news :(
>> It does not work for me, when I change something in the class I see this
>> printed on console:
>> 2007-03-14 13:34:32.657:/:INFO: Closing Spring root
>> WebApplicationContext
>> 2007-03-14 13:34:32.658:/:INFO: Loading Spring root
>> WebApplicationContext
>> 2007-03-14 13:34:33.043:/:INFO: Apache Cocoon Spring Configurator
>> v1.0.0 is running in mode 'dev'.
>>
>> But changes are not visible after refreshing the page. Am I missing
>> something?
>>
>> PS. I did svn up both for cocoon-rcl and commons-jci.
>
> Have you update cocoon-servlet-service-* too and run cocoon-rcl:webapp
> form your block's base directory?
> If yes or if it reloading still doesn't work for you, please activate
> logging in log4j.xml by uncommenting the two existing logging categories
> (jci, rcl) and setting them to DEBUG.
> Then (re)start Jetty and call http://localhost:8888, change
> MyGenerator.java, wait 3 seconds, do a page reload again and send the
> log file to me directly.
Another cause might be that I had to comment the rcl modules in
trunk/tools/pom.xml in order not to break the build for everybody. In the case
that you haven't changed this yourself for you own build, you won't get new
artifacts installed.
If I have some time this weekend, I will provide a snapshot release and put it
on a public Maven repo. Otherwise go to cocoon-rcl-wrapper and cocoon-rcl-plugin
base dirs and install both modules from there.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Reloading the mountableServlets map in DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz napisał(a):
>> Grzegorz Kossakowski wrote:
>>> Reinhard Poetz napisał(a):
>>> I'm not up-to-date with RCL stuff so I'm going to ask little ignorant
>>> question. What exactly have you fixed and how it makes development
>>> easier?
>> You can develop your C22 application (incl. Java sources!) without any
>> restarts. The problem till yesterday was that the reload of the Spring
>> application context didn't work. Although the classes where reloaded
>> in the classloader correctly, Spring used the initial application
>> context which was created at the servlet container startup.
>>
>>> I'm curious especially about reloading classes without running
>>> Cocoon inside the IDE, does it work now?
>> yes, it works now. The normal "hot code replace" of your IDE is only
>> able to change code of already existing methods. In contraxt, the
>> commons-jci reloading classloader that I use allows every possible
>> change: deleting classes/methods, removing classes/methods, creating
>> new classes/methdos.
>>
>
> Gosh, I have bad news :(
> It does not work for me, when I change something in the class I see this
> printed on console:
> 2007-03-14 13:34:32.657:/:INFO: Closing Spring root WebApplicationContext
> 2007-03-14 13:34:32.658:/:INFO: Loading Spring root WebApplicationContext
> 2007-03-14 13:34:33.043:/:INFO: Apache Cocoon Spring Configurator
> v1.0.0 is running in mode 'dev'.
>
> But changes are not visible after refreshing the page. Am I missing something?
>
> PS. I did svn up both for cocoon-rcl and commons-jci.
Have you update cocoon-servlet-service-* too and run cocoon-rcl:webapp form your
block's base directory?
If yes or if it reloading still doesn't work for you, please activate logging in
log4j.xml by uncommenting the two existing logging categories (jci, rcl) and
setting them to DEBUG.
Then (re)start Jetty and call http://localhost:8888, change MyGenerator.java,
wait 3 seconds, do a page reload again and send the log file to me directly.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Reloading the mountableServlets map in DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz napisał(a):
> Grzegorz Kossakowski wrote:
>> Reinhard Poetz napisał(a):
>> I'm not up-to-date with RCL stuff so I'm going to ask little ignorant
>> question. What exactly have you fixed and how it makes development
>> easier?
>
> You can develop your C22 application (incl. Java sources!) without any
> restarts. The problem till yesterday was that the reload of the Spring
> application context didn't work. Although the classes where reloaded
> in the classloader correctly, Spring used the initial application
> context which was created at the servlet container startup.
>
>> I'm curious especially about reloading classes without running
>> Cocoon inside the IDE, does it work now?
>
> yes, it works now. The normal "hot code replace" of your IDE is only
> able to change code of already existing methods. In contraxt, the
> commons-jci reloading classloader that I use allows every possible
> change: deleting classes/methods, removing classes/methods, creating
> new classes/methdos.
>
Gosh, I have bad news :(
It does not work for me, when I change something in the class I see this
printed on console:
2007-03-14 13:34:32.657:/:INFO: Closing Spring root WebApplicationContext
2007-03-14 13:34:32.658:/:INFO: Loading Spring root WebApplicationContext
2007-03-14 13:34:33.043:/:INFO: Apache Cocoon Spring Configurator
v1.0.0 is running in mode 'dev'.
But changes are not visible after refreshing the page. Am I missing something?
PS. I did svn up both for cocoon-rcl and commons-jci.
--
Grzegorz Kossakowski
Re: Reloading the mountableServlets map in DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz napisał(a):
> Grzegorz Kossakowski wrote:
>
> You can develop your C22 application (incl. Java sources!) without any
> restarts. The problem till yesterday was that the reload of the Spring
> application context didn't work. Although the classes where reloaded
> in the classloader correctly, Spring used the initial application
> context which was created at the servlet container startup.
Thanks for explanation.
>
> yes, it works now. The normal "hot code replace" of your IDE is only
> able to change code of already existing methods. In contraxt, the
> commons-jci reloading classloader that I use allows every possible
> change: deleting classes/methods, removing classes/methods, creating
> new classes/methdos.
>
Wow, so I cannot wait any longer to test it! :)
Will report results soon.
--
Grzegorz Kossakowski
Re: Reloading the mountableServlets map in DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz napisał(a):
>>> There is a startup time stamp in the Spring application context
>>> http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/context/ApplicationContext.html#getStartupDate()
>>> maybe you can use that.
>> The simplest solution that I could think of is adding a check whether
>> the system runs in dev mode. If true, the code, that collects
>> information about all available servlet services, is executed every
>> time when the service() method is called. As this doesn't seem to be
>> expensive I think it's at least not the worst option.
>>
>> thanks, I've introduced a check and committed the change. The RCL
>> stuff now works for me :-)
>>
> I'm not up-to-date with RCL stuff so I'm going to ask little ignorant
> question. What exactly have you fixed and how it makes development
> easier?
You can develop your C22 application (incl. Java sources!) without any restarts.
The problem till yesterday was that the reload of the Spring application context
didn't work. Although the classes where reloaded in the classloader correctly,
Spring used the initial application context which was created at the servlet
container startup.
> I'm curious especially about reloading classes without running
> Cocoon inside the IDE, does it work now?
yes, it works now. The normal "hot code replace" of your IDE is only able to
change code of already existing methods. In contraxt, the commons-jci reloading
classloader that I use allows every possible change: deleting classes/methods,
removing classes/methods, creating new classes/methdos.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Reloading the mountableServlets map in DispatcherServlet
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz napisał(a):
>> There is a startup time stamp in the Spring application context
>> http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/context/ApplicationContext.html#getStartupDate()
>> maybe you can use that.
> The simplest solution that I could think of is adding a check whether
> the system runs in dev mode. If true, the code, that collects
> information about all available servlet services, is executed every
> time when the service() method is called. As this doesn't seem to be
> expensive I think it's at least not the worst option.
>
> thanks, I've introduced a check and committed the change. The RCL
> stuff now works for me :-)
>
I'm not up-to-date with RCL stuff so I'm going to ask little ignorant
question. What exactly have you fixed and how it makes development
easier? I'm curious especially about reloading classes without running
Cocoon inside the IDE, does it work now?
--
Grzegorz Kossakowski
Re: Reloading the mountableServlets map in DispatcherServlet
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz skrev:
>>
>> After more than two days of debugging, many thanks go to Torsten and
>> Carsten who helped me to track down the problem, I found out, why the
>> reloading classloader plugin doesn't propertly reload the Spring
>> application context:
>>
>> The problem is that the DispatcherServlet contains a map of all
>> mountable servlet services. This map is initialized in the init()
>> method of the servlet and will never be reloaded. These servlets have
>> a reference to the first Spring app context and every reset remains
>> without effect.
>
> Use OSGi ;)
hehe :-)
>> The simplest solution that I could think of is adding a check whether
>> the system runs in dev mode. If true, the code, that collects
>> information about all available servlet services, is executed every
>> time when the service() method is called. As this doesn't seem to be
>> expensive I think it's at least not the worst option.
>> All other solutions would either make the DispatcherServlet dependant
>> from the ReloadingClassloader stuff or vice verca. But maybe it's only
>> to late here and I overlook a simple solution.
>
> There is a startup time stamp in the Spring application context
> http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/context/ApplicationContext.html#getStartupDate()
> maybe you can use that.
thanks, I've introduced a check and committed the change. The RCL stuff now
works for me :-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Reloading the mountableServlets map in DispatcherServlet
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
>
> After more than two days of debugging, many thanks go to Torsten and
> Carsten who helped me to track down the problem, I found out, why the
> reloading classloader plugin doesn't propertly reload the Spring
> application context:
>
> The problem is that the DispatcherServlet contains a map of all
> mountable servlet services. This map is initialized in the init() method
> of the servlet and will never be reloaded. These servlets have a
> reference to the first Spring app context and every reset remains
> without effect.
Use OSGi ;)
> The simplest solution that I could think of is adding a check whether
> the system runs in dev mode. If true, the code, that collects
> information about all available servlet services, is executed every time
> when the service() method is called. As this doesn't seem to be
> expensive I think it's at least not the worst option.
> All other solutions would either make the DispatcherServlet dependant
> from the ReloadingClassloader stuff or vice verca. But maybe it's only
> to late here and I overlook a simple solution.
There is a startup time stamp in the Spring application context
http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/context/ApplicationContext.html#getStartupDate()
maybe you can use that.
/Daniel