Re: Reloading the mountableServlets map in DispatcherServlet
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
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
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
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
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:, 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
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
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
Re: Reloading the mountableServlets map in DispatcherServlet
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
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
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
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
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
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:, 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
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
