>>> "Rob L'Estrange" <[EMAIL PROTECTED]> 24-Mar-01 4:43:12 PM >>> >1. Does anyone know of a JSP/servlet engine >provider who's product has the ability to detect >changed support classes/beans and reload them >dynamically (that is, without restarting the web >server)? Or, is there a way of eliciting this behaviour >from current products that we're overlooking? Are you talking about service providers or software providers? Any container conforming to API 2.3 should do auto-reloading if it's asked to. Whether individual ISPs providing servlet engines to their customers turn that feature on or not is another question. >2. Does anyone have any thoughts on whether this >behaviour would actually be implementable by a vendor? >Does anyone think that this behaviour would >actually be undesirable? If there are issues that would >make it difficult (one thing I can think of is that due to >ongoing references to instances of the class in question See the 2.3 spec. >(from the session or application attributes lists, for >example) that this may make reloading of the class a >problem; does anyone have thoughts on that?), is there >are way that the behaviour could be flagged to be turned >on in the dev environment but turned off in the live >environment? At least the multiple dev server restarts could >be avoided. The trouble is the problem of class mismatch is exacerbated in the development environment. So it's probably not best there. Reloading (of anything) works best when there are only small, incremental, changes to a webapp. >Note that we're NOT talking about the ability to >dynamically reload changed JSP's or servlets. We're >talking about the ability to dynamically reload >changed support beans/classes. The stuff about reloading in the spec talks about reloading war files and not about individual jsp or servlet classes. Any element contained within the WAR file that changes during the lifetime of the server should be reloadable. So if you ship support classes or jar files inside the WAR file the container *should* try and reload them. The spec is very clear that a container *should* try to maintain session data across reloads. The way this is achieved is by serialization though, so if you have a non-serializable object in your session you're not going to get a result. One way to handle that is to override or wrap non-serializable objects going into the session so that they have some way of serializing enough data so they can try and recreate themselves. For example you might wrap a ResultSet with a class that writes out the following details pertaining to the ResultSet: - the JDBC driver - the connection's url and username and password - the SQL statement that created the result set and then use that to recreate the ResultSet when the object is deserialized. Nic Ferrier ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
