Peter Delahunty wrote:
> I have downloaded the jswdk-1.0.1 which supports the servlets 2.1 api.
>
> However in the API documentation all the methods in the ServletContext Class
> used for inter servlet communication:
>
> getServlet
> getServletNames
> getServlets
>
> are now Deprecated and there doesn't seem to be any replacements.
>
> My problem is now this.
>
> example:
>
> i have 10 static web pages (which can and will in the future become dynamic
> generated probably template/DB based). I need to keep a log of when these
> pages are seen ( and in the future by who, when i have a session
> implemented.) This why don't want to use the web servers log.
>
The key issue is that you are trying to use a servlet as a shared data storage
object, when that is not what they are designed for. See below for an
alternative approach to your particular requirement.
>
> Solution:
>
> I turn all the pages into .JSP files. then i give them all an identifier eg.
> page1, page2 , page3 etc.
>
> I then create a central SERVLET that maintains a Hashtable that is used to
> cross reference the page key with the URL;
> eg: page1 will return /jsp/page1.jsp
>
> then every jsp page that wants to link to another page goes through the
> SERVLET. They send the key for the page they want.
> eg: page1 has a link to page2 like this: hfer=
> "/servlet/myservlet?dest=page1"
>
> The servlet then looks up the destination in the Hashtable, logs the request
> and redirects to the requested Jsp page. However this is all fine at the
> moment as I don't need inter-servlet communication if I hard code the links
> in the JSP pages.
>
> however I don't want to do this ( normal reasons for not hard coding)
>
> So I want to call a method on the Central Servlet that I can pass in a key,
> it checks if it is valid then returns me back the correct URL.
>
> eg <% myservlet.getURL("page1"); %>
>
> This is were it all goes wrong. To call the public method on the servlet I
> need to get a reference to it. However because of the methods that were once
> used to do this are now gone I cannot seem to do it.
>
If all you want to do is call a public method of a shared object, the simplest
thing to do is make your "central servlet" (or at least the logic of the
getURL() method and its associated data) into a separate object, and store it
as an attribute in the servlet context. Normally, this would be done something
like this in the init() method of one of your servlets (make sure it is
initialized at startup time), where "UrlCalculator" is the class name of the
new Java class you create for this purpose:
// Create and store a URL calculator bean
UrlCalculator calc = new UrlCalculator(...);
getServletContext().setAttribute("calculator", calc);
and then, in your JSP page, you can declare a bean reference to this object:
<jsp:useBean id="calculator" scope="application"
type="UrlCalculator"/>
now, you can call the getURL method of this object in a scriptlet:
<%= calculator.getURL("page1") %>
If you needed to call the getURL() method from within a servlet (like your
"central servlet"), the access would look like this:
UrlCalculator calc =
(UrlCalculator) getServletContext().getAttribute("calculator");
String url = calc.getURL("page1");
>
> Ideas
>
> I have been thinking of perhaps Static methods of non servlet classes
> or JNDI (bit over kill)
>
Static methods of non-servlet classes is a common approach to this problem, and
is often called the "singleton pattern" in discussions. It works, but
potentially exposes your static methods and variables to *all* Java code in
your servlet container, rather than just your own web application. Servlet
context attributes were designed to support shared data storage for a web
application, without exposing that stuff to other apps running in the same
server. Depending on the way your servlet engine implements class loaders, it
can also avoid some class cast exception problems.
JNDI-accessed directory servers (or JDBC-accessed databases) can also be used
for data sharing, and are appropriate when there is too much data to keep
around in memory, or if the data needs to survive longer than your server's
lifetime. The tradeoff for these features is longer access times As you
noticed, it's probably overkill for this particular requirement.
>
> So come on the gurus what is the answer, workaround, alternative ....
>
> cheers in advance..
>
> Ps. I have checked the archives of the mailing list but no joy.
>
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
