struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Barefoot" <Joe.Baref...@motiva.com>
Subject RE: reloading ApplicationResources
Date Tue, 01 Oct 2002 17:13:48 GMT


> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Tuesday, October 01, 2002 9:56 AM
> To: Struts Users Mailing List
> Subject: RE: reloading ApplicationResources
> 
> 
> 
> 
> On Tue, 1 Oct 2002, phpsurf wrote:
> 
> > Date: Tue, 1 Oct 2002 11:20:04 +0200
> > From: phpsurf <phpsurf@ifrance.com>
> > Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> > To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> > Subject: RE: reloading ApplicationResources
> >
> > > This is ***not*** an issue that Stuts can solve by itself 
> ... successful
> > > resoluation depends totally on the capabilities of the 
> application server
> > > you are using for development.
> > >
> > partly disagree with that : it's a good thing to let the 
> container do its
> > job, and try to focus on Strus' job, but we could have in 
> 1.1 a facility
> > (the one that was in 1.0) for manualy reloading the conf, 
> without having to
> > reload the entire webapp which is usualy a lot longer !
> > I'm not even talking about something fully automatic here ...
> >
> >
> 
> Supporting this wouldn't help you in the very common case 
> where you are
> recompiling the classes in your webapp.  It would also cause 
> *all* Struts
> based applications in production to slow down, because Struts 
> would have
> to synchronize around all reads of the data structures storing the
> configuration information.

No, no necessarily, as I mentioned previously on this topic.  If you want to be able to easily
reload your configuration in development, you either "freeze" the servlet controller so that
it rejects all requests while the configuration is being reloaded, or you make a deep copy
of the Hashmap(s) containing configuration data and use those while the new configuration
is being loaded.  In either case, you can achieve dynamic reload of configuration files without
having to synchronize access.  As it is unlikely that you would be doing this in production,
saying that this is too much overhead is a red-herring argument. 

b.t.w., I'm not clamoring for this to happen or anything (don't need it), just making a point...that
there's more than one way to skin a cat. ;)  The container ability to reload a web application
takes care of this, IMO.

peace,
Joe


> 
> > > I use Tomcat 4.1 for all of my app development efforts.  
> Among other
> > > things, this lets me take advantage of the dynamic 
> application deployment
> > > and reload faciliites of Tomcat, as outlined in:
> > >
> > >   
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/manager-howto.html
> > >
> > > and
> > >
> > >   
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/appdev/index.html
> > >
> > > (both of which are available from a standard Tomcat 
> installation.)  It's a
> > > total waste of time talking about what *Struts* can do to 
> improve this
> > > situation; the real key is to take advantage of the general web
> > > application development and debugging support that your container
> > > supports.
> >
> > Another point: about the reload facility of the container: 
> before reloading
> > a webapp, or simply some classes definitions, weblogic 6.1 
> (which is the
> > container I use) swaps its memory. the problem, is that 
> many of the static
> > objects placed in memory by Struts are not serializable, 
> which makes the
> > webapp crash as soon as a reload tentative happens !
> > If you have any idea to investigate about that, I'll be 
> interested ... :)
> >
> 
> Containers that impose the Serializable requirement on 
> anything other than
> session attributes are doing so on their own -- there's nothing in the
> platform specifications that talks about that.  If this gets 
> in your way,
> I'd suggest using a different container (at least for development).
> 
> 
> Craig
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:struts-user-help@jakarta.apache.org>
> 
> 

--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message