Hi,
>If you follow the packaging principles in the 2.2 servlet spec,
>you will have a
>servlet context per web application, that can run essentially
>independently of all
>other applications running in the same container. For all
>servlets packaged within
>that app, getServletContext() returns the same ServletContext
>instance -- the one
>controlling that application. That's why you can use servlet
>context attributes
>(in JSP they are application scope beans) to share information
>between the servlets
>and JSP pages that make up an app.
Ok..this I figured was accurate. I wasn't sure if he meant the context I get
is available to ALL applications running in the container. So, there isn't
anything that can be shared among applications, right?
I actually haven't got the 2.2 spec because we are still using the 2.1 spec
with JSP 1.0. With the amount of work I got, I haven't had time to really
look into it much. Hopefully soon we will move to it. The hard part is
finding an app server or servlet engine that conforms to this.
>In my code, its the action class that knows where it wants to go
>next, not the
>action servlet. However, I made a mistake in my first app, and
>used hard coded
>names of the JSP pages to be forwarded to -- not very nice when I wanted to
>rearrange my page names and had to go modify all the action classes.
I have seen this posted a few times now. I am trying to imagine how to do
this. First, if I put stuff in an XML file, dont I have to write my own XML
parser to read the xml file, parse out the specific class action name (from
the form), the action class to call, and a list of forwarding URLs depending
on logic in the action class? What is wrong with using a property file for
this..or is that considered bad now that XML is here?
Second, it seems in the way of performance it would slow things down. I
mean..one of the uses of this container/servlet stuff is that you should be
able to update classes without having to restart the server, right? So if
you do this, but the XML file is read in only once, is there some way to
re-read it each time you make a change? Do you provide a hook or something
so that you can tell the controller servlet to reload the XML file, or do
you do like an app server where you start a thread in the init method that
say every 1 minute checks if the time/date stamp has changed from the
previous time/date stamp..and if it has, reload it? I am curious if there
is actually a way that during the course of a day if on our site we find out
something is wrong, we do a code change..if we will ever be able to upload
the changes without shutting down our site..which basically kicks off all
the transactions going on at that moment..very bad!
>Now, I tend to add a public method in my controller servlet that
>can look up actual
>page names from a logical name (as someone else in this thread
>recommended). This
>is yet another Hashtable (or HashMap :-) that is configured in the
>init() method,
>either from servlet init parameters or from an XML file.
See my prevous paragraph! :) I would like to use this, but am unclear at
this time the "preferred" way to go about this.
>I agree with Daniel here. Some have likened Action classes we've
>been talking
>about to the "command" pattern in the GoF design patterns book.
>You can also think
>of them as "adapters" -- they translate between the HTTP format (request
>parameters) to the model format (bean properties). Passing the
>HttpServletRequest
>object on to your bean (be it an EJB or a JavaBean) would bypass
>this, but (much
>worse IMHO) it ties your bean to being used *only* in a servlet
>environment.
Exactly my thoughts..which is why I was thinking the action class is an
adaptor to say, the EJB that does the actual logic. Thus, the Action class
does really nothing other than turn a request into a bean or EJB, and that
bean or EJB does the actual logic with this data, and returns data back to
action class (via the bean most likely).
Again I dont know EJB and how it works into the action classes yet, so if
you dont want to reply to this one..thats fine, but I am curious..does the
action class create an EJB object over the network and populate the EJB with
the request data, or does it always create a simple JavaBean (the same one
used by the JSP page for displaying purposes maybe) and pass that bean on to
the EJB, and the EJB then gets/sets properties in that bean, and sends that
bean back to the action class which forwards to the JSP page?
>You
>really want your business logic (the "model" beans) to be
>independent of whether
>you're running inside a servlet container or a Swing-based GUI
>app, or an CORBA or
>RMI based server, or ...
Yep! Again..my agreement. I thought the idea of using EJB, a separate logic
layer is that you could tie in outside GUI/Views to it...using a network
connection they could tie directly into your logic, but not necessarily
through a web page.
Makes me think instead of saying Action, it should be Adaptor!
On this note, I would love to hear your response on this. We definitely will
be goint towards EJB, but probably not for another 6 months or so. Until
then, what we do now is use JSP/JavaBeans (converting our site still) in the
Model 1 form. Even as I convert to this Model 2 approach, should the
JavaBean that is created by the adaptor Action class and the request
parametes are read into it ALSO do the logic? I dont think so, because what
happens when you move to EJB? Plus, my thinking is that the JSP/JavaBean
should be nothing more than a simple class that has get/set methods, with no
logic in it at all. What we are doing now is we have this package called
sessions. Our current site, still using servlets for everyting, will create
a NEW session object, set its properties, and that session object contains
the logic, so the servlet calls on the session to do the logic. If the
session object is used on mutli-page forms, then we stick that session
object into the HttpSession to keep it alive. So, is this the right approach
to take? In that, I mean as I convert to the Model 2, should my Action
classes still create these session objects, store them in the HttpSession,
and then when we move to EJB these session objects would become the EJB
objects. I apologize..I mean classes in this case. Its screwy here because
our main code has some sessions with logic, some servlets with logic, some
other stuff with logic..its a nasty code base we have. But in trying to work
with others to clean it up and make it more stable, we want to ready it for
EJB use. So I just wanted anyones input on if the right way is have the
Action class still do what the servlets are doing now, and the JSP pages
only use a JavaBean that the action class fills in from the session
data/logic, to be displayed, so that when we move to EJB, we simply convert
these session package/classes to EJB somehow, and we are "almost" done,
other than whatever is involved in connecting the Action class to them.
Thanks.
===========================================================================
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
