At 11:40 PM 5/2/2004, Craig McClanahan wrote:
Michael McGrady wrote:
Isn't it true, Craig, that this is not a problem for hot deploy of the classes that do this. If you have other classes that do not do this, then they cannot be hot deployed. But, what difference does that make? If someone wants to hot deploy them, they can redesign the class. The more I think about it, the less of a problem this seems to be. Am I missing something here?
Most containers (but no guarantees, since it's not in the specs) will know how to pick up a new class that has never been compiled before. No container that I know of lets you selectively replace classes that have already been loaded into the class loader, because Java's class loader API doesn't support unloadClass() or replaceClass().
Solving 1% of the problem doesn't help -- it only misleads people. See my response in the other thread for a very common Struts use case that doesn't work with your approach.
In the other thread I responded to the idea that the use case doesn't work. That use case is not supposed to work. Making one class hot deployable is not supposed to make all classes hot deployable. Personally, I don't see a good reason not to make an entire framework hot deployable. This could be done fairly easy and without doing the framework any injustice that is obvious. All you have to do is to provide the proper interfaces which is probably a good idea for lots of reasons and cannot really hurt for any reason I know of and then you can easily employ class factories using a new classloader for each hot deploy. That would for a game application, for example, provide a 100% solution unrelated to the container.
The key, and maybe you are not seeing this is part of the solution, is to load the implementation with the following being true:
1. Do not have the client (container) reference the implementation that needs to be replaced. Otherwise you will have to bounce the client (container).
2. Have the client (container) reference only a base class or an interface. If you change base classes or interfaces, you would still have to bounce the client (container), but that is not a problem.
3. Have the implementation class's classloader delegate to the client (container) classloader. Presumably this means that the client (container) would be using the system classloader.
4. Make sure that a number of things happen with a hot deploy by a class factory: (a) get the state of the old implementation and add it to the new one, so the client (container) must make the state of the original object available to the factory and (b) the client (container) must drop any old references to the old implementations both to save resources and to use the new version, these objectives are achieved by passing the old implementation into the factor and returning the new one with the same reference as the old one.
5. If you want to hide things from the client (container) as well, give the client (container) a forwarding proxy to the actual object, giving the factory the control of swapping the object at any time without either the knowledge or agreement of the client (container).
Here "container" might be "framework". Yes?
Taking this whole approach is not specific to Struts, but (if it is actually useful) would have general applicability. It sounds like what you're designing is a specialized sort of servlet container that knows how to support some limited subset of hot deploy -- plus a design paradigm for building applications for it that requires you to replace any persistent reference to another object with a lookup in a cache of some sort (so that you're not pointing at an object based on an obsolete implementation class). This can have pretty dramatic impacts on code readability and performance, but presumably someone will find it worthwhile. I wouldn't personally be willing to live under the restrictions such a design paradigm implies when building apps.
But it is still totally out of scope for Struts.
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
