I think this is best solution. Imagine you have class A and class B. B holds an instance of A. Now you force B to be reloaded. Should A be reloaded too? What happens with the instance of A in B? Is it duplicated? C is holding an instance of B, so must C be reloaded (and all existing objects which refer to B reinstantiated) now?
You don't need to restart the server to get your changes live, you can force it to reload the whole application, which, in case of tomcat, your users wouldn't even notice (as long as ALL your beans in session are serializable). On the other hand, for "major fixes" on large production systems, you can't afford to deploy a class and relay on servers reloading behaviour, you have then a release process with testing and quality management, so it's not an issue. regards Leon P.S. the JSPs are reloaded intime. If you really "need" to hot-redeploy your classes, you can patch tomcat and supply your own classloader policy, using a separate class loader for each and every servlet / component / class will allow you to reload the classes but will also lead to abovementioned inconsistences. On 9/24/05, jimbo-black <[EMAIL PROTECTED]> wrote: > Leon Rosenberg <[EMAIL PROTECTED]> wrote in > news:[EMAIL PROTECTED]: > > > On 9/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > wrote: > > > I think it's forbidden by the spec. > > > > SRV.3.7 Reloading Considerations > > Although a Container Provider implementation of a class reloading > > scheme for ease > > of development is not required, any such implementation must ensure > > that all servlets, and classes that they may use, are loaded in the > > scope of a single class > > loader. This requirement is needed to guarantee that the application > > will behave as expected by the Developer. > > > > > > > ah i see, that would make sense. but it seems strange that this sort of > thing is accepted as the norm. i would think that its a common requirement > and that a lot of developers would get sick of restarting the server to get > some minor bug fix into production. > > does anyone have a workaround? > > btw, i moved to storing my name-value pairs (used to be props files) in the > db for this very reason. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
