Javarebel actually provides all the JVM reloading tools to you. It's a pretty neat framework that goes a lot further than hotswapping in the JVM. The problem I was having was actually that CodeBehind doesn't provide methods to overwrite the configs for a single changed action. It only allows the full configuration reload. It doesn't look like Convention has that either, from what I can tell.
Ideally, I'd like to be able to code like on Rails, where changes happen immediately. In JavaRebel, right now, I've got Spring migrating individual bean/dependency changes, java code reloading, and Struts doing a full configuration reload. That works pretty well, I was just trying to get rid of the 4 seconds it takes to rebuild all of struts configs. BTW - the JavaRebel plugin uses an OGNL cache clearer. You need that or added variables to your actions won't get recognized in the view anyway (sort of defeating the purpose of configuration reloads for java). On Sun, Dec 21, 2008 at 1:33 PM, Musachy Barroso <musa...@gmail.com> wrote: > I committed my changes, rv#728469. To enable auto reloading set: > > <constant name="struts.devMode" value="true"/> > <constant name="struts.convention.classes.reload" value="true" /> > > @Blake: take a look at the changes, I think you might be able to do > the same thing with CodeBehind, also the ClassLoader classes that I > took from JCI are self contained (after a few mods), so you can lift > them also. > > musachy > > On Sun, Dec 21, 2008 at 11:42 AM, Blake Byrnes <blakebyr...@gmail.com> > wrote: > > Cool stuff. I've been playing with the Struts 2 javarebel plugin to try > to > > get it to load individual configuration changes using codebehind. It's > > nearly impossible to weave into the current setup, so you have to just > > reload the whole configuration. > > The framework will load anything registered as a PackageProvider, but I > > couldn't get it to load Configuration Providers. > > > > On Sun, Dec 21, 2008 at 11:34 AM, Musachy Barroso <musa...@gmail.com> > wrote: > > > >> just for reference, the only way I found to register a > >> ConfigurationProvider in a plugin was registering a Dispatcher > >> Listener, and then adding the ConfigurationProvider to the > >> Configuration manager instace in the dispatcher, not very elegant, but > >> that's all I got. As a side note, I used this plus a ClassLoader that > >> I borrowed from Apache JCI, and now the convention plugin will have a > >> setting: > >> > >> struts.convention.classes.reload > >> > >> which, when set to true, will reload the configuration when a class > >> that has actions change. Like xwork does with the xmls, so the > >> container doesn't need to be restarted when in devMode. > >> > >> musachy > >> > >> On Wed, Dec 10, 2008 at 9:44 AM, Musachy Barroso <musa...@gmail.com> > >> wrote: > >> > Is there anyway to register a new ConfigurationProvider? I thought > >> > that just defining a bean with that type, it would get picked by the > >> > framework and registered. It seems like ConfigurationProviders get > >> > added to the ConfigurationManager "by hand" by Dispatcher. I want to > >> > watch class files from the convention plugin, and reload the > >> > configuration automatically when they change, but I can't do this, > >> > without registering a ConfigurationProvider. > >> > > >> > regards > >> > musachy > >> > -- > >> > "Hey you! Would you help me to carry the stone?" Pink Floyd > >> > > >> > >> > >> > >> -- > >> "Hey you! Would you help me to carry the stone?" Pink Floyd > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > >> For additional commands, e-mail: dev-h...@struts.apache.org > >> > >> > > > > > > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
