Kevin Duffey wrote:
> 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?
>
Not within the servlet API itself. You can use the old standby approaches like
Singleton classes, as long as you load those classes from the system classpath (so
they are visible to all the apps), or you can share information in a database or
other external resource.
>
> 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.
>
Well, err, umm, (not to toot my own project's horn too loudly :-) you could use
Tomcat <http://jakarta.apache.org>, (either standalone or connected to
Apache/IIS/NES). There's also a few others around that already implement servlet
2.2/jsp 1.1 -- a quick starting point would be the vendor list on JavaSoft's site:
<http://java.sun.com/products/servlet/industry.html>.
> >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?
>
There are lots of XML parsers around ... nobody should feel the need to write their
own (unless they enjoy it, of course).
Property files are fine for simple stuff like this. If you want to represent more
complex configuration information than a 1-to-1 mapping, XML becomes lots more
useful because you can record hierarchically related information.
>
> 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!
>
When your servlet is reloaded, the init() method will get called on the new
instance. If you are loading your config information there (the usual case), it'll
get reloaded again.
You could write a background thread to watch for changes in the config file itself,
but it seems easier to me to just "touch" (the Unix command) the class file of your
servlet, and auto-reload takes care of everything else.
Java has design limitations on how you can do class reloading that pretty much
force a servlet container to throw away your entire app and reload it. Some
(many?) servlet containers make some attempt to save your sessions if you are
storing Serializable objects.
On the other hand, on-the-fly changes to a production application would give most
sysadmins I know a heart attack :-). They tend to prefer controlled shutdowns,
installing new releases, and controlled startups.
>
> >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).
>
And then the controller can choose save additional data (if needed) as request or
session attributes, then forward to the appropriate JSP page for the next
interaction with the user.
>
> 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're probably going to get tired of hearing this, but its another "different
strokes for different folks" issue. There are people who use each of the design
styles you've suggested.
>
> >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.
>
Same issue applies to logic that is embedded inside a "plain" JavaBean (how do YOU
know it's not using the network for something under the covers?).
>
> 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?
IMHO: Action class should read the request parameters, call setXxxxx methods on
the business logic beans, and (if needed) some sort of invoke() or perform() method
to tell the bean to "do it's thing". Same design model for JavaBeans business
logic beans or EJB business logic beans.
In no case should the business logic bean know that it is being invoked in a
servlet environment (quick test -- does your business logic bean import from
javax.servlet.*? It should not).
> 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.
>
One approach to consider -- implement your business logic in plain JavaBeans now,
then reimplement in EJBs later -- but do it "behind" the API of the existing
JavaBeans so that your action classes don't have to change.
There's lots of good architecture suggestions, among other places, in Sun's
"BluePrints" manual on J2EE app design, at <http://java.sun.com/j2ee/blueprints>.
The sample application you can download with the J2EE SDK is also very instructive.
>
> Thanks.
>
Craig
===========================================================================
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
