--- "Kevin A. Burton" <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > So what patterns do developers follow when the want > to deploy webapps with > singletons that have support for reloading? > > Kevin
You have a couple of basic strategies for having 'part' of your application persist as (a) loaded class(es) through the reload of other classes during run-time. One strategy is to save and restore your loaded state based on life-cycle events (servlet destroy() and init()) or using a ServletContextListener (if you are using a Servlet 2.3 compliant container). Before a web app is reloaded, it must be destroyed so you can use this opportunity to save the state, perhaps as a serialized object for speed, and then on reload you can check for the presence of persisted state information and use maybe a semaphore of some sort (i.e. a date threshold or a flag) to indicate whether you want to load it instead of going through your normal initialization routine. Restoring using serialized objects can often be much faster than a full startup going through a complex initialization cycle. The negative with this route is that it may require considerable rewriting of your application. Also, if you serialize data in classes that get modified, make sure you use a Serial Version ID and follow the rules for safely upgrading classes for serializable objects. See the serialization API docs for details and tips. Alternatively, and _possibly_ much simpler, you could place the classes that must persist through the dynamic reload of others into the 'shared' or 'common' classloader space so that they are not reloaded except on application server restart. This will force those classes to be loaded by the parent class loader of the web application classloaders and so will remain loaded and be referanceable from the objects created by the classes loaded by the web-app class loader. However, the reverse is not necessarily true. That is, objects created from classes loaded by the 'shared' or 'common' class loader can not 'see' the classes loaded by the child webapp class loader. This could be a problem if the long-lived part of your application tries to use classes only loaded by the web-app loader. This can be prevented in design by using interface classes that do not get reloaded and only referencing dynamically reloaded class implementation objects through those long-lived interface classes. Another potential negative about this strategy is that the classes loaded in the 'shared' or 'common' areas are visible to other web applications. That may be an issue if you are sharing use of the tomcat server with other applications. So either strategy MAY require significant rewrites to your application, depending on how your code is designed. Good luck, Mel Dr. Mel Martinez Extreme Blue/Cambridge IBM __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
