Ken Robinson

Ranch Hand
+ Follow
since Jul 25, 2002
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ken Robinson

The Startup Servlet will work, however if you are using Servlet Spec 2.3 or later, I suggest using the LifeCycleEvents.
As a Startup Servlet will probably never be used as a servlet once loaded, it is not as 'clean' as it could be. The LifeCycleEvents exists for this purpose and this purpose only.
Read more about it here
17 years ago
I do not totally understand the first question, but I can answer the second.
Before you forward via the RequestDispatcher, you can put object in the Request object.
Request.setAttribute(key, value) puts an object in the request. In your JSP, you can get the object out using the <jsp:useBean ...> tag as well as the JSTL <req:attribute...> tag or any other JSP tag written for this purpose.
Check out the book Java Server Pages, 2nd Edition by Hans Bergsten from O'Reilly, it is very good.
17 years ago

Originally posted by Tony Alicea:
A typical app server has to service many requests per unit time. It would not be practical to have a pool of that many servlets around or conversely to slow down the processing of requests by making them wait for THE servlet to be free.

A question on a seperate front.
Is this not exactly how STRUTS, via a pool of Action instances, works?
17 years ago
Instead of using the JSDK2.1 by itself, I would recommend getting the J2EE1.3.1 instead. J2EE includes everything in the Servlet API and is more current (Servlet Spec 2.3).
Next I would get Tomcat (4.1.12 I believe is current) from This is a free webserver that implements the 2.3 spec.
Finally, I would become familiar with the directory structure of the Web ARchive (.war file). ANY J2EE server (Tomcat, WebLogic, WebSphere, JBoss) MUST support this. The .war file and it's structure define exactly what you are looking for and more. The location of static file, config files, servlet classes and anything else required are predermined. This not only standardizes practices, it ensures that your app is portable since the structure is supported by each server. You will not get that portability coding to the 2.1 spec implementation.
[ October 04, 2002: Message edited by: Ken Robinson ]
17 years ago
Just a quick guess, try executing a 'commit' every so often. If Oracle believes that the data has not been committed, it may keep the cursor available for rollback purposes.
17 years ago
What you can do for this may depend on if both tables are in the same DB, what DB you are using and where you are willing to put the code (Java side or DB side).
If both tables are in the same DB, I personally would write a Stored Procedure in the database to do this. The DB would take parameters in, check if you want to move the field and then move the field. Depending on your preference, you can either return a flag to tell the Java program the logic worked or throw an exception back to the calling client (java) if it did not work (and this is an exception condition in you app).
I use Oracle where I am working right now. I usually wrap all of my DB inserts in stored procs. If a condition of the insert is not met, I simple throw an exception back to the calling program. Putting the logic in the stored proc allows the same logic to be used from anywhere (Java, VB, Unix) that may call the proc.
I would not use a Servlet for this. Since you want the communication to originate at either end, a stand alone server would be best.
There are a number of ways to do this. The quickest (just from what I have done) would be to write both the applet and server as RMI servers. Although they are both servers, they would act as clients to each other. The applet would connect to the server (which is on the same machine as the web server that servered the applet), which once it registers the client, connected to it as a client. Since each side now has a connection open RMI, they can call methods on each other at will. When the server gets an indication that one client has clicked on a day, it can notify all clients of this event.
18 years ago
As mentioned above, I would not expect the container to invalidate the session exactly on x number of seconds.
Most likely the container checks for timed out sessions once every X minutes. I would consult the docs of the server you are using to see if you can adjust this, or at the very least see if you can determine the value.
18 years ago
Common practice is to have a Servlet place the bean in an object available to the JSP Page (Request, Session, Context). Usually the Request is used. Once the page is rendered, the Request goes out of scope. Once it goes out of score, all beans placed in it go out of scope. The beans will not stay in memory for long.
The alternative is to create a bean pool type object that recycles the beans.
18 years ago
While EJBs can be Local, they are really meant to run in a distributed world. As Connection objects cannot be passed from machine to machine, the Connection must be created in the same VM as the EJB, which is why the EJB container usually handles the Pooling.
Depending on how you've implemented your JDBC code, you may have an easy work around. If you've placed all the JDBC code in classes other than the EJB, you can just not use the EJBs. I usually create three sets of classes, one class for the data coming/going to/from the database, one class that holds all SQL and methods for creating the data beans via the SQL (usually only static methods that require a Connection as a parameter) and one set of classes that are the EJBs. The EJB remote/local interfaces usually miror the static SQL methods, without the need for a Connection object. The EJB gets a Connection from the pool and calls the static method in the DataAccessObject, returning the DataBean. If you implement this, you can cut out the EJBs, handle Connection creation yourself (from servlet, thick client) and just use the DAO/DataBeans.
Hope this helps and good luck.
This is an issue where there is no silver bullet. The way to go is dictated by the project, deadline and conditions.
If you inherit a project where all the code is JDBC Queries, the code works and there are no performance problems, then there is really no reason to change. However, if there are performance problems, moving the SQL Code to an SQL Server is a much better option, give the time exist.
There are a few things you can do with the first problem. What I would suggest is to utilize the <context-param> element in the web.xml file.

In the above, you can of course assign the Key and Value Strings to whatever you like. The description is optional, but makes reading the web.xml a bit easier.
What happens is that the server automatically loads these parameters for you and makes them available in the ServletContext for you. Since you are loading a Properties file, this provides the same exact functionality. Simple use the ServletContext.getInitParameter(String key) method. This method takes the value in the <param-name>element as it's arguement and returns the value in the <param-value> element.
Using this method, you have a very easy and standard way for all components of your web app to get to these parameters without having to worry about any sychronization issues.
The second problem can be solved in a number of ways. If you are using Servlets all throughout your app, just get a handle to the ServletContext in the init method. Keep it as a member var so that you will not have to get the ServletContext for each call. Depending on how often you need this, you could also just get the getServletContext() method, which is part of the javax.servlet.GenericServlet class, inherited by every servlet created.

Hope this helps.
18 years ago
First, I would suggest NOT putting a file generated by your app in the WEB-INF directory. This directory's purpose is to allow the web app/container access to files needed for configuration while keeping them off limits for incoming web request. Keep in mind, if you deploy a .war file and the container does not unpack the .war, you may get an error when writing to that directory. Remember, the method name is getResourceAsStream. There is not createResourceAsStream type method. I'd suggest setting a Context Parameter as the file location and creating is somewhere on the disk not within the public HTML directory of the server you are using.
A ServletContext object is just an object. Any class you write can take a reference to it in it's constructor or method calls. Simply pass it in as a init parameter to your object or as an arguement in a method call.
18 years ago
It should also work if the FilterMapping is the same as the ServletMapping.
The spec dictates the rules for mapping and are as follows:
1. The container will try to find an exact match of the path of the request to the
path of the servlet. A successful match selects the servlet.
2. The container will recursively try to match the longest path-prefix: This is done
by stepping down the path tree a directory at a time, using the �/� character as
a path separator. The longest match determines the servlet selected.
3. If the last segment in the URL path contains an extension (e.g. .jsp), the serv-let
container will try to match a servlet that handles requests for the extension.
An extension is defined as the part of the last segment after the last �.� char-acter.
4. If neither of the previous three rules result in a servlet match, the container will
attempt to serve content appropriate for the resource requested. If a "default"
servlet is defined for the application, it will be used.

These are directly from the 2.3 spec. Of course, Filters are still new, so there may be issues. Play with the mapping and see what works for the server you are using. I've played with it in Tomcat and had no problems, but I only tried a few specific test.
18 years ago