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.

Craig


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to