All this says, if I understand you, and I am fairly sure I do, is that if you change some class and have no way to reload it, without the container reloading then you have a problem unless you do something about it. That is to be expected.
So, if you are going to change a class and there is not a way to hot deploy that class, you need to do something else. That, however, does not say anything about the efficacy and the reasonableness on whatever basis an architect might decide of using some hot deployment. This is not a case that does not work with the "scheme".
This is simply a case where a class is replaced without a possibility of hot deploy. That has nothing to do with hot deploy working where you code for it. The "scheme" is unrelated to this problem. This is merely like the case where I make one class serializable and another is not serializable. That is not a failure of the "scheme" of serialization and does not make serialization "half-assed".
Maybe I am not seeing something, but I don't think so in this case. A solution that does not pretend to or need to solve all problems is still useful for its intended purpose. Right?
At 11:38 PM 5/2/2004, Craig McClanahan wrote:
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]
