Hi,

>One option to consider is storing the connection pool as a servlet context
>attribute.  Go ahead and create it in the init() method of your
>controller servlet,
>then execute:
>
>    ConnectionPool pool = ...;
>    getServletContext().setAttribute("pool", pool);

Agreed if you need to do it this way. But, I thought part of the idea behind
doing all this action class stuff was to allow the action class to "create"
the connection to the logic class, such as a javabean or ejb, and the
javabean or ejb would be responsible for the connection. I assume by
allowing the action class access that the action class does some logic? I
prefer to have the action class do nothing more than it has to..create the
bean, let the ejb or bean logic populate the bean, then forward to the JSP
page to display the results. This way, if you are not using EJB now, you can
have the action class call on a javabean for the logic, that could later be
turned into an ejb and maintain its logic code.

>Now, if you've read my suggestions on the method signature of the
>perform method in
>action classes, you will note that I pass the servlet itself as an
>argument:
>
>    public interface Action {
>        public void perform(HttpServlet servlet,
>          HttpServletRequest request, HttpServletResponse response)
>          throws IOException, ServletException;
>    }
>
>One of the main reasons I do this is so that action classes have
>access to the
>resources of the servlet context.  In particular, from within the
>perform() method
>of an action class, I can call:
>
>    ConnectionPool pool = (ConnectionPool)
>      servlet.getServletContext().getAttribute("pool");
>    Connection conn = pool.getConnection();

Couldn't you just do Connection conn =
servlet.getServletContext().getAttribute("pool").getConnection()? Ofcourse,
it might be best to put a check before actually using it. :)

>and pass the connection on to business logic beans that need it.

Hmm..interesting. I see..your having the connection in one place, instead of
each bean getting the connection. Thus, code-reuse right? Sounds like the
same thing I do with having the forwarding done in the controller servlet,
instead of each action class forwarding. I haven't worked out the details
yet, but thus far I am returning a value from the action class which uses a
hashtable to look up the forwarding page. I know..its not the best approach.
Ideally I want to use an XML file and a parse to return me a DOM and do it
that way. But for now, to get this thing working I am using a hashtable to
do the lookup in and hardcoding the links in the controller servlet init
method.  I believe Craig said returning a value compared to just forwarding
from the action class isn't the way he is doing it. I have said this before,
and so has Craig and Daniel..each person will come up with what they feel is
best for their application. In my case, I like the re-use of forwarding in
the servlet. I know that ALL action classes are going to forward to a JSP
page at some point, so I put that code in one place. Craig makes a good
point here..by placing the "getConnection()" code in one place and passing
the connection on, you don't have to have every logic class get the
connection. Craig, my question is..if you move to EJB which is on a
different tier, you can't pass the Connection (because its not
serializable..right) and why would you want to? I thought EJB would get the
connection. In that case, you said use a stateless ejb, but, is it possible
to direct ALL requests form all action classes to create/use a "single" EJB
controller, that on the EJB side then directs to the proper EJB? In this
way, every action class calls a single EJB again passing say a JavaBean
(specific to each action) to the EJB along with the "name" of the action.
That controller EJB would then get a connection and pass it along with the
JavaBean on to the "action" ejb to do the logic. How about that?




>I use the same technique for other application-wide shared
>resources as I described
>for connection pools above -- store them in the servlet context
>attributes.  As an
>added bonus, I can even refer to these resources in a JSP page:
>
>    <jsp:useBean id="logger" class="com.mycompany.mypackage.MyLogger"
>     scope="application"/>
>
>or in an action class:
>
>    MyLogger logger = (MyLogger)
>      servlet.getServletContext().getAttribute("logger");

Ahh..ok..I was right. Store it in the context and it becomes APPLICATION
scope.

===========================================================================
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

Reply via email to