(sorry about my mail client sending out the half-ready mail.. anyhow..
> If you are working on a JRebel plugin, feel free to start a thread on the >> dev mailing list as we can give you some pointers on where to look. We >> already have a builtin class reloading/configuration reloading mechanism >> that could give you some integration ideas. > > > > Hi! As i received this feedback from one Struts JIRA's report I submitted earlier, I am gladly taking the advice and dropping an email to your developers list : ) I'm working on a Struts2 plugin for a product called JRebel (formerly know as JavaRebel -- http://www.zeroturnaround.com/javarebel/), which implements runtime class reloading for Java, removing the need for any redeploys. As I want the plugin to co-operate with Struts in a way that after changing *ANYTHING* in the Struts project, simply pressing F5 in the browser would let you see your changes (exactly as if the application was actually redeployed), i need to patch Struts in a way to reload it's action mappings at certain moments. I think I kind of managed to achieve it when the actions are configured with the traditional Xml configuration (i just monitor these certain files for changes, and tell Struts to reload all the configuration when any of them has changed), the annotations-based action-mappings configuration seems to be far more tricky. Namely, as i really can't (for performance reasons) monitor *all* the classes and reload the whole configuration after *any* of them has changed in any way (this would mean a full reload after basically any developer's movement..), i would need to somehow intelligently find out about the packages where the actions *could* be found. Now what is cumbersome is that sometimes you use the actionPackages filter parameter (in the older plugin), sometimes you use a special set of rules to describe where the actions can be found (packages named "actions", etc.). I really don't want to re-implement this whole logics of finding potential packages where the Struts action classes *could* be placed in. So, maybe anyone can drop a line about ... 1) .. whether there exists a good place somewhere in the framework code that i could patch or read with Reflection API to get to know about the packages where the action classes could be. DefaultConfiguration#getPackageConfigs() maybe looks something like what I'm looking for, but I'm yet to investigate whether it will actually give me the java packages where the actions could potentially be (even if there currently is none! -- i want to monitor all the places where the user could potentially *add* an action class at any given moment). RuntimeConfiguration#getActionConfigs() also looks like something useful.. can anyone comment on this? 2) .. and whether the performance issue I'm worrying about (reloading the action mappings) is something to worry about at all.. How slow will it get if i have a really-really big Struts app for example? Maybe it's blazing-fast even for large apps, and i could quite naively reload the config on *every* request? It's hard for me to estimate, as i don't have anything else to play with than the demo applications provided with the Struts2 source code distribution, and they are still not that big. (I'm never actually developped a Struts web-app myself : p) Cheers, Sander