All the things you mention, of course, are real problems that need to
be solved. They are, however, I think, not formidable or even
particularly challenging and have known solutions which are
provisionally good enough for discussion. When you think that the one
HaD class stands in for the entire IoC framework, this option, to my
way of thinking, has serious merit. Anyway, an example that I am
using is the following interface App with an implementation AppImpl
and an AppHotFactory as indicated. When creating an AppImpl object,
the code is
App app = AppHotFactory.getInstance(null);
When updating an AppImpl to new solution, the code is
AppHotFactory.loadAppImpl();
When updating an existing AppImpl object to the new AppImpl.class, the code is
app = AppHotFactory.logAppImpl(app);
The interface is:
public interface App
extends Serializable {
public String getName();
public Set getPermissionNames();
public Map getPermissionTypes();
public void setName(String name);
public void setPermissionNames(Set permissionNames);
public void setPermissionTypes(Map permissionTypes);
public String toString();
}
The implementation is whatever you want it to be. And, the AppHotFacotry is:
public class AppHotFactory {
private static ClassLoader appClassLoader;
private static Class appClass;
public static synchronized App getInstance(App existingApp) {
// Startup implementation
if (appClass == null) { loadAppImpl(); }
// Factory
App newApp = null;
try {
newApp = (App)appClass.newInstance();
} catch (InstantiationException ie) {
System.out.println(ie.getMessage());
ie.printStackTrace();
} catch (IllegalAccessException iae) {
System.out.println(iae.getMessage());
iae.printStackTrace();
}
// Copy state when going to a new implementation.
if (existingApp != null) {
transferState(existingApp,newApp);
}
return existingApp = newApp;
}
public static synchronized void loadAppImpl() {
try {
appClass = new URLClassLoader(new URL[]{new
URL(SiteConstant.DEPLOY)}).loadClass("com.crackwillow.app.AppImpl");
appClass.newInstance();
} catch (MalformedURLException mue) {
System.out.println(mue.getMessage());
mue.printStackTrace();
} catch (ClassNotFoundException cnfe) {
System.out.println(cnfe.getMessage());
cnfe.printStackTrace();
} catch (InstantiationException ie) {
System.out.println(ie.getMessage());
ie.printStackTrace();
} catch (IllegalAccessException iae) {
System.out.println(iae.getMessage());
iae.printStackTrace();
}
}
private static synchronized void transferState(App existingApp, App newApp) {
newApp.setName(existingApp.getName());
newApp.setPermissionNames(existingApp.getPermissionNames());
newApp.setPermissionTypes(existingApp.getPermissionTypes());
}
}
Works like a charm. More later.
On Sun, 28 Nov 2004 17:54:30 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On Sun, 28 Nov 2004 15:36:27 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> [snip]
>
>
> > With hot deploy, instead of switching the implementation and the name
> > of the implementation class, e.g. ColonSeparatedMovieFinder for
> > DatabaseMovieFinder, you just have an implementation called
> > MovieFinderImplementation (or whatever you want, e.g. X) and a
> > MovieFinderImplementationHotFactory for getting object instance
> > implementations of the MovieFinder interfaces. Conceivably, in fact,
> > you can give people differing implementations with the same name by
> > simply putting them in different directories: no problem. This means
> > that the code can be dynamic and alterable at will and that there need
> > be no changes anywhere if you don't want there to be other than
> > dumping the new MovieFinderImplemenation.class in some directory
> > somewhere.
>
> Within a single JVM (such as a servlet container), the only way to
> have different versions of the same fully qualified class name is to
> use different class loaders, which loads the different versions from
> lots of different places. That sounds like a pretty significant code
> management issue that any hot deploy strategy like what you describe
> would need to deal with.
>
> On the other hand, you're going to need individual class loaders to
> solve a different aspect of "hot deploy" as well ... recompiling an
> existing implementation class to modify its behavior (instead of
> trying to switch to a new one). There is no ClassLoader.unloadClass()
> method in Java, so the only way to "throw away" an old class is to
> throw away the class loader that contained it (and hope that the rest
> of the application doesn't have any pointers to the old class or any
> instances created by it, which would cause a big memory leak).
>
> That's what a servlet container does, for instance, when you reload an
> app -- it throws away the old context class loader and creates a new
> one. It's not a perfect solution, but it's not an easy problem,
> either.
>
> Craig
>
>
> Craig
>
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
