At 4/18/2000 10:53 AM -0700, Kevin Duffey wrote:
>Hi,
>
> >Let's assume that the Hashxxx you use to store your list of
> >request URIs is
> >stored as an attribute of your servlet context. Then:
> >
> > HashTable uriList = (HashTable)
> >servlet.getServletContext().getAttribute("urilist");
> >
> >Since you can get & set attributes this way into your servlet context (and
> >the servlet we are talking about here is your controller servlet),
> >then you
> >could easily write an action class that reloads this object from your xml
> >configuration file; thus achieving dynamic reloading. Naturally, the uri
> >used to do this (ReloadConfig.do) would be part of your admin area with
> >security restrictions....
> >
> >Just a thought,
>
>A good one indeed.
>
>
>Interesting too. My worry is..what if you do it during the day? Two
>scenarios come to mind..I am sure there are more. One is..you add a new
>action, and add the <action..> tags to the xml config file. Through your
>admin .do action, you reload the xml file, like you said..using the servlet
>context to store the Hashset (Sorry..set for me. ;). I agree with Craig
>too..in passing the THIS as the Servlet to pass on to every action. This is
>what makes your Admin possible..passing the servlet to gain access to the
>context. So, in Scenario #1, you would simply reload the xml file, and it
>would just "add" the new actions..and they should be ready to be used even
>while your server is running during the day. The only thing to worry about
>is somehow making sure requests don't come in during the process of
>replacing the Hashset config information..thus it might be more plausible to
>use a Hashtable for this?
>
>Scenario #2 is you modify an existing action. This might mean the .java
>source, or you may change an existing action to point to a new action class.
>The problem in my mind is how do you do this while users are using your
>actions at the same moment? You don't want to lose their session
>information, or have them submit a request while the server is
>"re-initializing", or they may end up seeing some nasty error messages, and
>lose their info too. So what is the course of action to reload modified and
>new actions (classes, xml config, etc) while maintaining current sessions?
>
>Thanks.
Well, it seems to me that in either case you are only accessing one object
instance (your Hashxxx object). So adding a new object to it would make
that new action (.do) immediately available to all users. Replacing the
attributes associated with a specific requested URI (e.g.
RegistrationStepTwo.do) would seem to be a very fast process. E.g. here's
the code I use to load the configuration file:
ActionObjectWrapper obj = new ActionObjectWrapper();
obj.theRequestUri = requestUri;
obj.theClassname = className;
obj.theTargetPage = targetPage;
uriList.put(requestUri, obj);
Where ActionObjectWrapper is:
public class ActionObjectWrapper {
public String theRequestUri;
public String theClassname;
public String theTargetPage;
public Action theObject = null;
} // ends inner class ActionObjectWrapper
So, again, replacing a single action object (and it's associated data) is
quick and painless. But what if you are making broad changes that affect a
workflow, for example, which affects many classes and default target
pages?? One possibility might be to ignore this and allow your error
handling to kick in when users make requests for actions/pages that are no
longer supported. It seems to me that creating a whole new Hashtable object
and replacing it in the servlet context
with servlet.getServletContext().setAttribute("urilist", uriList);
would not solve this problem; since users currently actively involved in a
specific workflow might be "orphaned." I guess, if you need to modify the
app that radically, then some sort of controlled shutdown/startup might be
better....
Just my 2c.
Mike
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
