Re: force reload of individual class files
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]
Re: force reload of individual class files
Leon Rosenberg [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: 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). thanks much. i do understand it better now, is there any other special setup to make sure that tomcat persists sessions across restarts? (e.g. context.xml pararms) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: force reload of individual class files
matador wrote: Leon Rosenberg [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: 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). thanks much. i do understand it better now, is there any other special setup to make sure that tomcat persists sessions across restarts? (e.g. context.xml pararms) Nope. For more info read http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/manager.html particularly http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/manager.html#Restart%20Persistence Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: force reload of individual class files
On 9/23/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: given a change to class file(s), does anyone know a hack workaround to force tomcat to reload * just those files *. I know about restarting the app from the console and context.xml. but i cannot afford to knock users off in the middle of their sessions just to reload a few minor class files. 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. btw, i think bea has this feature. Previous generations of containers created new class loaders to load a servlet, distinct from class loaders used to load other servlets or classes used in the servlet context. This could cause object references within a servlet context to point at unexpected classes or objects, and cause unexpected behavior. The requirement is needed to prevent problems caused by demand generation of new class loaders. So probably an old BEA weblogic or something, but not if it's confirm with 2.3. Btw, Java WebServer 2.0 (the sun thing that was reference implementation before tomcat 3) had this functionality too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: force reload of individual class files
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]
