Jeanne Boyarsky wrote:David,
First of all, I've given you a cow for asking such a great question. It's clear, interesting and contains all the relevant information.
If I'm understanding the data you want to externalize right, I don't think you need the Parameterized Test Case pattern here. I recommend reading up on it anyway though. It's a good tool to have in your tool box.
That code does look cumbersome. One approach would be to have two arrays. One would contain the two "in" values and the other would contain the 20 "ex" values. Then you could use two for loops to create the field names with the right index and build the list that way.
You picked the best of breed tools.
I see two other things to remark on in your code:
1) The FirefoxDriver is a lot slower than the HtmlUnitDriver in Selenium. If you need to test in a real browser, you have to live with it. But if you are just testing functionality and a "simulated" browser does the job, it is worth considering.
2) In Java, we general throw Exception and not Throwable. The later includes system errors like running out of memory that automatically get thrown.
2) I see in a number of places that you catch an exception and print a stack trace. When this happens, you should fail the test and not proceed silently. You could add a fail statement. But it would be better to remove the try/catch block entirely and let JUnit deal with the error. Conveniently the default behavior is to fail the test and give you a stack trace!
Bear Bibeault wrote:Yes. The container has a well-debugged and performant connection pooling mechanism. You should be using it.
Connection pooling is like security -- it's really hard to roll your own and get it right.
I'm not sure of the details for setting it up for Tomcat7 (my clients are still on 6), so poke around and you are sure to fund instructions.
Bear Bibeault wrote:If you are not using container-managed connection pooling, you're doing it wrong.
Paul Ngom wrote:David,
Do you close your database connection after
usage or any other resource you had opened
in your servlets or classes?
J. Kevin Robbins wrote:Paul, Good point. I'll bet it's exhausting the connection pool. That would explain why existing users can't get logged in either.
David, make sure you have a "finally" block that is closing the connection and the statement.
J. Kevin Robbins wrote:You answered correct, those log files are linked to that instance of Tomcat only. You could access them through the Manager app or an app like LambdaProbe if you can get to that server, but it's probably not accessible over the internet if they have it running at home. At least I hope not. That's a security nightmare and probably in violation of their ISP agreement.
Anuj Sharma R wrote:
Wow so late tonight, and still I get a response!
That is the beauty of being in different time zones - your night is our start of the day :-).
You can see a 'logs' folder typically under your Tomcat deployment folder. There should multiple log files in there. Check for log file with stderr in its name and see if you can find any error/exceptions in there. I don't think you have cleared your logs folder as you were not aware where it was in first place . But in case logs are too big, you should clear those, redeploy the application and then wait for it to happen to decipher the problem from the logs.
Ulf Dittmer wrote:Agree, start by checking out the log files.
UNTIL...I undeploy and redeploy from the Tomcat manager page
Do you really mean "undeploy"? Or just "Stop" and "Start" (which together is the same as "Reload")? It would be a very unusual problem that requires redeploying.
J. Kevin Robbins wrote:The log file may also be called "catalina.out". I'm not sure about version 7, I'm still running 6. The most recent entries will be at the bottom of the log.
Anuj Sharma R wrote:Hi David,
Did you check your Tomcat logs?
Paul Clapham wrote:Here's my opinion: you've got a whole lot of code and it's all untested. And servlets are a really poor testing environment. So why don't you back up a bit -- write a command-line program which tests your database access, to get that working first. Then you can put the working code into the servlet.
Paul Clapham wrote:You don't need the Class.forName line if two conditions apply: (1) you're using Java 6, and (2) the driver is JDBC 4.0 compatible. You should certainly be using Java 6 by now, and the latest version of the driver should certainly support JDBC 4.0, but anyway you should really ensure that both of those conditions do apply.
Paul Clapham wrote:Classpath? Yes... but you posted some code for a servlet, so am I right in assuming that you're running this in some servlet environment like Tomcat? If so then the driver jar should go in the web application's WEB-INF/lib folder.
Paul Clapham wrote:The primary problem was that the driver didn't load. The secondary problem was that you had a NPE elsewhere. It wasn't obvious to you that the secondary problem was because the primary problem had been ignored.
Paul Clapham wrote:Really that catch-block in the PDB class should be throwing a RuntimeException after logging the SQLException; as it's written it basically ignores the SQLException and allows processing to go on until something else fails. You noticed already how hard it is to track down the reason for the secondary failure, right?