Costi Ciudatu

Don't worry, it's just a typo: you apparently wrote actionPreformed instead of actionPerformed.

Your servlet would need to benefit of the new "Comet" model / async support, so that it will simply push data to the clients as soon as it's available. Alternatively, the classical (but only "almost"-real-time) solution would be to poll the servlet via AJAX once every few seconds and see if anything has arrived. The servlet itself will simply register as an observer for the service I was talking about (that will handle both sync and async communication over the socket) so that it will be notified of any new messages and it will be able to push them (or serve them) to browsers.

For the business tier async communication you could also have a look at some JMS implementation and make use of a message queue, if you'll find this suitable.

You can implement this with both servlets and even JSP. But this is not the kind of work that a servlet (not to mention JSP) is usually supposed to handle.

Try to consider having all this stuff hidden in some service component. At a minimum, keep all the logic that handles communication over the socket in one class that is used by the servlet.

public class SocketConnector { public Data getData() { // create or reuse a socket... // fetch your data.... } public void sendCommand() {} /* ........... whatever your needs are ........... */ }

public class YourServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse resp) { SocketConnector connector = new SocketConnector(); req.setAttribute(connector.getData()); // forward to jsp for rendering getServletContext().getRequestDispatcher(yourJspPath).forward(req, resp); } }

One step further with the decoupling would be to define a "DataService" interface that would expose the getData() / sendCommand() /... methods and make the SocketConnector class implement that interface. The servlet will only make use of the interface (without knowing anything about the actual implementation, so that you will be able to change your business tier without touching the servlet): For this you can make use of some dependency injection container (Spring, EJB 3, ...) or simply have a factory method returning the actual implementation.
public interface DataService { Data getData(); void sendCommand(); /* ........... whatever your needs are ........... */ }
public class SocketConnector implements DataService { public Data getData() {} public void sendCommand() {} /* ........... whatever your needs are ........... */ }
public abstract DataServiceFactory { public static DataService createDataService() { return new SocketConnector(); } }

The above servlet in this case will look like this:

public class YourServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse resp) { DataService dataService = DataServiceFactory.createDataService(); req.setAttribute(dataService.getData()); // forward to jsp for rendering getServletContext().getRequestDispatcher(yourJspPath).forward(req, resp); } }

As you can see, your servlet doesn't even import the SocketConnector anymore, so you can switch the actual data provider without any modification required in your servlet. Just have the DataServiceFactory return some other implementation.

With a framework like Spring (and maybe making use of Spring MVC), you don't need the factory and you can simply "inject" your service into the controller.

You're right... I think I've only used scriptlets once a few years ago...
So, let's assume the ${year} is set as a request attribute...

Your year goes from 100 years ago until now.
For each such year, you're printing the "100 year after" year. Your output probably starts with now and goes 100 years in the future.
Try this:

<%int year = Integer.parseInt(simpleDateformat.format(date));%>

<c:forEach var="i" begin="0" end="100">
<option value="<cut value="${year - i}"/>"><cut value="${year - i}"/></option>
</c:forEach>

I was not aware that c:forEach has any problem with decrementing, and I'm not really able to test that right now.

But as a simple workaround (in case you won't get the proper solution), you can just have some i counter incremented (the traditional way from 0 to 100, and inside the foreach block use (currentYear - i) for year (so you'll just emulate the decrementation).

If you only need to see if an Employee is present in your collection, you don't need to overwrite contains(), just rely on its behaviour: overwrite equals() and hashCode() in your Employee class and contains() will return correctly. Also, in this scenario, you don't really need a List; a Set -- HashSet, for instance, would be more suitable.
But if you need to actually refer to that Employee instance, you would definitely need a Map<ID, Employee> -- a HashMap or (if you want the order to be preserved) a LinkedHashMap. Make sure your ID type overwrites equals() and hashCode() and that it's immutable (as Campbell pointed out).

The container doesn't need to instantiate a bean just because you deployed it. It may very well lazily instantiate one when you look it up / inject it in some client.

I beat you to it, apparently, as when I realised my first post was useless I actually checked the ubuntu tomcat configuration just to make it up.

/**
* Increases the capacity of and internally reorganizes this
* hashtable, in order to accommodate and access its entries more
* efficiently. This method is called automatically when the
* number of keys in the hashtable exceeds this hashtable's capacity
* and load factor.
*/
protected void rehash()

The JavaDoc says it all. Besides, you can only invoke this method if you extend from Hashtable, since it's protected.
Most likely, you'll never need to deal with it (or even know of its existence).

On ubunbu, it seems like the webapps directory is under: /var/lib/tomcat6/webapps.
Actually, /var/lib/tomcat6 is set as CATALINA_HOME by the init script.

Is that /usr/share/tomcat6/webapps created by you (no such directory is created when the package is installed) ?

First try with your 8080 port (or whatever your Tomcat is listening on), since the "It works" message seems to come from your Apache web server (not tomcat !).
You seem to have some proxy configured in Apache, but most likely not the way you want it.

This is a class loading issue. Since the two .wars are deployed in the same container, they'll each be provided with their own class loader but they both inherit from a common one.
If you want to keep a single instance of your singleton class for all the components you deploy, you should include that in the common/parent class path and exclude it from your .war/WEB-INF/lib.
In tomcat, you should put the jar containing your singleton in your ${TOMCAT_HOME}/lib (or common/lib, shared/lib) directory so that it will get inherited by everyone.

Note that if you have the "Singleton" class in each war, you will not only get two instances of the singleton, but also two distinct classes: you'll get a ClassCastException when trying to pass it from one .war to the other, even if it's apparently the same class -- it's not, since a class definition is relative to its class loader.

I'm not sure if I understood your actual question: is it something like: "how to make use of the variables passed to the constructor in the getResultSet() method, so that once created, a dbQuery instance can return the result by simply calling getResultSet() -- with no parameters ?"
If so, I'll try to answer this question alone and just remind you that a class can hold state as instance variables.
Therefore, you can keep the queryTerm you get in the constructor and the Statement you are creating as instance variables
(I'm just pointing out a solution for your particular concern, assuming I got it right, as storing a Statement as an instance variable is a... "second best" practice, so to speak)

public class obQuery { private String queryTerm; private Statement statement; public obQuery(String queryTerm, String obName, String queryURL) throws SQLException{ this.queryTerm = queryTerm; this.stmt = .......... ............. } public ResultSet getResultSet() throws SQLException { return stmt.executeQuery(queryTerm); }

Again, as Mohamed pointed out, there is a lot to reconsider about your code, but I'd say let's clarify them one at a time...

The java.util.Properties class javadoc states that:

A natural line is defined as a line of
characters that is terminated either by a set of line terminator
characters (<code>\n</code> or <code>\r</code> or <code>\r\n</code>)
or by the end of the stream. A natural line may be either a blank line,
a comment line, or hold all or some of a key-element pair. A logical
line holds all the data of a key-element pair, which may be spread
out across several adjacent natural lines by escaping
the line terminator sequence with a backslash character
<code>\</code>.

Therefore, try:
#### Lead Export File Content ###
EXPORT_HEADER=LEADID,CREATED_ON,DATE_TIME,ADAPTOR, FIRST_NAME,LAST_NAME,ADDRESS,CITY,STATE,ZIP_CODE,\
EDUCATION_LEVEL,DEGREE_OF_INTEREST,INFODEGREE,PROGR AM,INFOPROGRAM,INFOAREACODE1,INFOPHONE1,\
INFOAREACODE2,INFOPHONE2,BEST_TIME_TO_CALL,E-MAIL, ARE_YOU_AFFILIATED_WITH_THE_US_MILITARY,\
ARE_YOU_INTERESTED_IN_RECEIVING_FINANCIAL_AID,INFOCAMPUS,REM OTE_ADDR,INFOVENDORID,INFOUNIQUEID,CID,UID,AFID