Indeed, the change to jsp is propagated. Still, I dont quite understand the current behaviour:
1) changing a property file inside a scanned directory causes the application to reload within the running jetty instance. But.. such change does not show up on browser refresh. 2) Changing a jsp is propagated at once. 3) Changing a class causes no reload and is not propagated. Even if the app is reloaded, for instance by a change in xml, the change to class code is not visible. 4) Only after a restart of jetty, changes to class code, xml or property files become visible. Does the above sound like what is to expected in a jetty:run ? mraible wrote: > > On Thu, Sep 10, 2009 at 7:13 AM, measwel > <marek_karczew...@yahoo.com.au>wrote: > >> >> ... >> This is probably because Jetty is in the process of reloading the app. >> It's >> usually best to rely on the web framework's hot-reload capability or use >> JavaRebel. That way, you don't have to way for Spring to initialize on >> reload. >> >> For my understanding; please correct me if I'm wrong: >> >> 1) Jetty's hot reload is on application level. It will reload on changes >> in >> xml or properties in the src/main/webapp/WEB-INF directory only. >> 2) It should be possible to use the frameworks (I use struts2) hot reload >> capability. Is this on class level? Any instructions on how to anable it? >> > > I believe it's part of the codebehind plugin, but I'm not certain. > > 3) An alternative is to use java rebel. A tool like that enables hot > reload >> on class level. >> 4) You say 'Because you don't want your app to reload when you change a >> JSP. >> Changing >> and saving a JSP will automatically reload as part of the servlet >> container.' Does this mean that in order to see .jsp changes I have to >> restart jetty with my current set up? >> > > I'm willing to be that if you use the current configuration, change a JSP, > and refresh your browser, you'll see the change. > > Matt > > >> >> >> 2) Changing properties file doesnt seem to have any effect. Is it because >> it >> > is in src/main/resources and this dir is not scanned by jetty? >> > >> > I see the following pattern in POM file: >> > >> > <scanTargetPattern> >> > <directory>src/main/webapp/WEB-INF</directory> >> > <excludes> >> > <exclude>**/*.jsp</exclude> >> > </excludes> >> > <includes> >> > <include>**/*.properties</include> >> > <include>**/*.xml</include> >> > </includes> >> > </scanTargetPattern> >> > >> > Why is jsp excluded? >> > >> >> Because you don't want your app to reload when you change a JSP. Changing >> and saving a JSP will automatically reload as part of the servlet >> container. >> >> >> > >> > What do ** mean in the path? >> > >> >> It's Ant's path syntax and basically means "look in all sub-directories". >> >> Matt >> >> >> > >> > >> > -- >> > View this message in context: >> > >> http://www.nabble.com/speeding-up-development-cycle-tp25365737s2369p25374955.html >> > Sent from the AppFuse - User mailing list archive at Nabble.com. >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@appfuse.dev.java.net >> > For additional commands, e-mail: users-h...@appfuse.dev.java.net >> > >> > >> >> >> >> -- >> View this message in context: >> http://www.nabble.com/speeding-up-development-cycle-tp25365737s2369p25382807.html >> Sent from the AppFuse - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@appfuse.dev.java.net >> For additional commands, e-mail: users-h...@appfuse.dev.java.net >> >> > > -- View this message in context: http://www.nabble.com/speeding-up-development-cycle-tp25365737s2369p25384041.html Sent from the AppFuse - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@appfuse.dev.java.net For additional commands, e-mail: users-h...@appfuse.dev.java.net
