struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: Way to reload struts Action classes in WebLogic8.1
Date Mon, 03 May 2004 06:38:43 GMT
Michael McGrady wrote:

> This is more of a passing interest of mine, so I will pursue a bit 
> more, if you continue an interest.  I have an application that needs 
> to do this from afar on multiple and untrackable sites.  So, the 
> bouncing the server idea just won't work for me.  I need this to 
> happen without exchanging classloaders, and probably without fiddling 
> with the classloader API.  So, this is my thought: that you have 
> multiple dependencies is not important so long as they all obey the 
> "pattern" we were discussing, i.e., 1., 2., and 3.  So, any 
> application framework that provided reloading only to the requisite 
> classes, those that followed this "pattern" would not be "half-assed" 
> at all but would be fully workable.  One might even use a tag 
> interface, e.g. Reloadable, to identify which classes had this sort of 
> independence.  If all classes were created and were loaded on this 
> sort of structure, there would never be a need to bounce servers, 
> etc.  That, I think, is a very workable solution, and another reason 
> why using interfaces is so important in designing architectures.  
> Whew!  That may be false but it sure is ambitious.  ///;-)

OK, let's be very clear about a use case that doesn't work with your scheme.

A very common design pattern for Struts-based apps is to have a "setup" 
action that preconfigures a form bean, followed by a submit to a 
"process action" that performs database transactions on behalf of that 
very same form bean class.  What happens in your approach when you 
recompile the form bean class to add a new property, because you need to 
add a new field to the corresponding input form?  That's right ... 
recompiling the action classes is not sufficient, because the old copy 
of the form bean class continues to persist.

This kind of thing happens so often that, unless you can solve it, any 
solution that deals only with reloading Actions is going to meet my test 
for "half-assed", because the fine points of what is reloadable and what 
is not is going to be totally lost on most developers.  And your 
solution doesn't solve it.

If your container can't do a reload fast enough, then get a new 
container.  I'm not interested in Struts pretending to be a container 
when there is no way to solve all the necessary problems.  That would be 
a tremendous disservice to all Struts users.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message