> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> 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 <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > 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:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
