Hi,
Kevin Duffey wrote:
>
> I will do the same..snip where needed for bevity.
>
> >but just forward to
> >the appropriate JSP and let this page get the "previous" results
> >from the session.
> >But the are all pretty much a matter of taste so use what you
> >like, just be sure
> >that you have
> >your own reasons to do it the way you are doing it.
>
> <snip>
>
> Daniel, are you saying that specific "non-dynamic" jsp pages should ALL go
> through the controller? I thought I was clear on this from what Craig said
> before, but I am not sure if I understand you right. I have a number of > JSP
> pages (infact, everything "will" be a JSP page, except the header.inc and
> footer.inc, which are included "inline" with every JSP page to display the
> same consistent look and feel on every page). My question is..do ALL links
> on every page even to static pages go through the controller? I am using > the
> Model 2 we have been feverishly talking about only for forms..thats it.
> Links on the "footer" (text links) that lead to such things as About our
> company, Help, Overview, etc..those are all direct links to the JSP pages
> themselves. Some of those pages may have a form on them..which the form
> action is set to the .do action name. Is this all acceptable behavior? Or > do
> you send ALL requests through your controller servlet?
Let's see. I'm not saying that every link should go through the
controller and if you have "non-dynamic" jsp pages (I guess they are JSP
for a specific reason) then I see no point on using the controller for
them unless you foresee that they might become dynamic in the future. I
was just saying that I would use the controller even with links to
dynamic pages (which you might consider forms with get method and
hardcoded parameters). The only case when it might not be needed, is
when you just wanted to show information stored in the session or the
application scope. That's not a pretty usual case and I just said that I
might even use the controller(doing nothing) as a bridge for link
coherence's sake and to isolate the links from future changes where I
might want to do something in the controller for this pages. But that's
not a must or a recommended approach. I said it was my choice and that
each developer should make its own decision based on his own reasoning.
I know mine is not always the standard one ;).
> <snip>
>
> >I just need
> >to reload the configuration an that's it. And it's also easier to
> >"read" an "debug"
> >than having to
> >check inside Java classes. Somebody also suggested using a
> >database to store the
> >workflow
> >and retrieve the JSP to forward to from the DB on every request
> >after performing
> >the request.
> >In our case, we tried not to complicate things so much for
> >performance reasons and
> >because
> >we thought the workflow shouldn't be so dynamic and complicated as
> >to require a
> >database backend.
> >But I admit that in some cases where the app. is very big and
> >workflow is difficult
> >to grasp, it would
> >be quite helpful to use this DB to debug easily 404 Errors or
> >"Which actions use
> >this JSP page?" queries...
> >But hardcoding workflow in any kind of java class (actions, beans,
> >even special
> >classes just dedicated to that)
> >.... I wouldn't recommend it for mantainability's sake.
>
> How do you reload the .xml file while the server is running, say in the
> middle of the day with 100's of users on your site? My main reason for
> asking this is how does the JVM unload and reload classes that have > changed,
> without affecting the current users using them? I assume you mean that the
> configuration itself is reloaded and doesn't require any specific classes > to
> be reloaded. If thats the case, how do you change the workflow? My best
> guess is that you can change, say the JSP page a specific result would
> forward to or the specific action class used from an Action name, but > thats
> about it. If you could elaborate on how you can change workflow in what
> ways, that would be great. Thanks.
As Craig mentioned in other postings, reloading action classes in
runtime is not that trivial so I was not talking about "runtime
reloading". I agree with Craig in that a controlled stop/update/start is
usually more healthy for sysadmin's hearts. On the other hand, if you
are fast enough, configure the system to answer a meaningful error
message and your container has persistent sessions, it shouldn't be too
bad. If your changes are so radical that your current users might be
seriously affected(JSP pages no longer used, functionality/security
changed...) then you'd better performed a controlled process where you
make sure the users have all logged out before you start the update
process. One of the future topics where I want to work in our framework
is to add the feature where you can notify the users of a maintenance
pause, let them log out while new users are not allowed to log in, and
then you can start the update process when all of them have logged out.
You might try to get fancy with classloaders, but you would still have
problems with current users, so I can't think of a better way of
handling it. Real runtime reloading/update of changes is, for me, like a
myth as it sounds like trying to mantain/fix planes while they are
flying ;).
So yes, I was talking about changing the configuration.
Dan
PD: Oh, I just checked the "on the fly" update of classes in my
enviroment and it "works". What it does it detecting that there's a new
class (even though it is an action class) and reloads the controller
servlet again. I haven't checked if user sessions survive this reloading
but I guess they do, otherwise it could be dangerous more than helpful
:). Note: WinNT, Resin1.1
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
===========================================================================
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
