struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander S├Ánajalg <>
Subject Re: Patching Struts -- good extension points for reloading action configuration..?
Date Tue, 08 Sep 2009 13:35:10 GMT
(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.

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 --, 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)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message