struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Musachy Barroso <musa...@gmail.com>
Subject Re: Patching Struts -- good extension points for reloading action configuration..?
Date Tue, 08 Sep 2009 15:22:26 GMT
couple of notes(in no logical order):

1. you can ignore CodeBehind, which is on the way out, XML and
Convention is what matters
2. The config can be modified at runtime, but it is a PITA, so we just
reload the whole thing when an XML file, or class changes
(Dispatcher.getInstance().getRuntimeConfiguration().reload() or
something like that), it is pretty fast and it will include all the
configuration, XML and Convention. Reloading on every request could be
too much, I haven't tried it.
3. When convention is set to watch files, it will use FileManager to
keep a list of loaded classes, just like the XML configuration does,
ob every request struts check automatically (if devMode is true) if it
need to reload
4. When using the Spring plugin, it can be configured to watch certain
files or directories for changes and reload the configuration(XML and
Convention): http://struts.apache.org/2.x/docs/spring-plugin.html
5. About the packages of loaded classes. Every action mapping has a
reference to the class that will implement the action. What this class
name means is relative to the ObjectFactory being used, so if Spring
is the ObjectFactory the class name could be a bean name. So you could
do something like this a) inspect the runtime config and get the class
name for every action b)use the object factory to get an instance of
the action and get its Class c) use something like:

protected String getJarUrl(Class clazz) {
        ProtectionDomain protectionDomain = clazz.getProtectionDomain();
        CodeSource codeSource = protectionDomain.getCodeSource();
        URL loc = codeSource.getLocation();
        File file = FileUtils.toFile(loc);
        return file.getAbsolutePath();
    }
to get the location where the class was loaded from.
6. I have to run or I will miss the bus :)

musachy

2009/9/8 Sander Sõnajalg <sander@zeroturnaround.com>:
> (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
>



-- 
"Hey you! Would you help me to carry the stone?" Pink Floyd

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message