Hi,
Iīll add my own comments,
Kevin Duffey wrote:
>
> Hi all,
>
> Sorry to post this on the list, but I feel some of you who may have been
> following the discussion Craig, Daniel and I have been having might still
> like to follow along.
>
> So, I have the controller servlet working. A few questions have arised to a
> few posts I have seen you reply to.
>
> First, how do you use a Hashtable? If you already replied to this..my
> apologies. I found out my email program was on all weekend in a crashed
> state and I lost alot of email, nor could I get any, nor could I send. I
> recall you and Daniel both mentioning something about using a Hashtable as a
> lookup table (that could be loaded in from a database or a properties file,
> or xml file..whatever persistence desired) to figure out the action class to
> call?
In my case, I store factory objects in the Hashtable, indexed by
operation names. This factory objects are in charge of creating
instances of the action classes and even though I create one instance
per request now; it will be very easy to modify them to reuse an
instance or create a pool if I need it afterwards. I initialize the
hashatable at init time from an xml file which contains the description
of my action classes and their behaviour. In my case, I added some more
complexity in here because, as I want my controller servlet to handle
various applications, I store a hastable per application. I choose the
appropriate application depending on the suffix.
So "Enroll.do", I first get the application corresponding to the ".do"
suffix and then I got the action factory corresponding to the "Enroll"
operation from the selected application. Then I get the action from the
factory.
> Next, about the threading issues. I talked to one of our developers here, a
> pro with threading, and showed him my bit of code. He concurred with me that
> what I am doing "should" be thread safe. Basically, the ControllerServlet,
> by using the .newInstance() call, it creates a NEW action class for each
> request coming in. Because of this, fields of the class are ok to use on a
> per thread/request basis. You might have meant this in your explanation and
> I just wasn't clear. I did notice you also mentioned if the action class
> uses a bean, multiple requests "could" cause thread problems there if the
> bean contained instance fields as well. But again, the action class should
> normally create this bean...a new instance again, and place it in the
> REQUEST object. If this is the case, is there any reason to worry about
> threading issues?
If you always use a new instance then you are safe, basically because
there is no concurrent access to worry about. Problems appear when you
use the same object from different threads at the same time. Is Craigīs
case, he is using different objects (local variables) in every thread so
thatīs why itīs safe, even though he just uses only one action instance.
> So, if in my action class, I do something like:
>
> public void perform(HttpServletRequest req)
> {
> // do some logic
> ...
>
> // create bean
> MyBean bean = new MyBean();
> bean.setXXX(..);
> bean.setYYY(..);
> req.setAttribute("MyBean", bean);
> setUrl("/forwardToThisPage.jsp");
> }
>
> Now, this is "close" to what I expect to have my action classes do. They
> figure out logic, create a new bean, populate it, set the forwarding url,
> and return back to the controller servlet, which then forwards to the proper
> JSP page depending on the setUrl() call in the action class or if an error
> occurs.
I agree with Craigīs in this one, I also let the Action class (I call it
Operation) to forward itself to the appropriate place. This option
allows me to leave the controller servlet code clean of UI redirecting
code and this allows me to have different Operation classes that behave
differently. For example, in case I want a special Operation that does
not use forward but creates the UI itself (useful for some rare cases).
> So, based on the above, isn't my bean thread-safe as well because its a NEW
> created object for each request? I agree with Daniel in that everything
> should be put in the request scope.
Eummm, not exactly what I said though :). I meant that everything that
has sense just for the request should be put in the request scope. But
there is an appropriate place for every object depending on its usage
scope and, as Craig mentioned, this might be the session scope (put them
in the session) and also this might be the global scope (put them in the
context).
> When using Model 2, you already are
> forced to write the code that gets all the form parameters out of the
> request object when it comes in (part of the action class I
> believe..right?)
Yes, some people tend to use the Model 1'5 because it automagically
populates your beans from the data inside the forms. But thatīs a
personal choice.
>, and thus, by populating the bean and putting it in the
> request, the JSP page will most likely use the bean at the request scope,
> fill in the values of another form (or possibly the same form if say an
> error occured and the page is being redisplayed) so that a subsequent
> request will contain those values where need be.
Yes, the idea is to "communicate" the action class(business logic) and
the JSP(UI view) by putting objects in the request, the session and the
context.
> Alrighty..thats it. Trying to keep these short. Hopefully my above
> explaination of why I think its thread-safe is accurate, but please
> elaborate on why it is/isn't good design/bad design, if its thread safe,
> etc.
Well, most of the issues are not a matter of good/bad design. They
depend mostly on personal choices, experience, goals... Just have a look
at the "JSDK2.2 and security" thread that Craig and I followed, itīs not
a right/wrong question but a matter of your programming style. OTOH,
there are some approaches that work/scale/are mantained better than
others and thatīs the reason why itīs good to discuss them here, so we
all benefit from other peopleīs experiences.
> Also, if you could, is this basically what you are doing (and you too
> Daniel if you read this)?
Basically, thatīs it with some slight changes. But the more you use it
and the more you want to do with it, the more youīll sophisticate/refine
the model.
> Keep in mind I am creating a simple (at this time)
> but definitely deployable working Model 2 layout that I should be able to
> use with other web applications, but that does indeed work with security,
> user-roles (whatever the heck these are), and does the job as you guys use
> it.
>
> Thanks so much for all of your emails. I know its taught me alot and
> enlightened me on a number of topics I was unclear about. I hope its doing
> the same for others reading this ongoing discussion.
I hope so as well. Itīs also useful for us as thereīs no such a thing as
the perfect design and rationalizing it to explain it to others, and
compare it to other viable solutions are very good ways of "revisiting"
your design choices. And it also gives me the chance to see that Craig
and I agree sometimes ;), basically because I learnt most of it from his
posts and followed his recommended readings :).
I hope this helps,
Dan
-------------------------------------------
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
