Reusing ResultSet object in Servlets.

[Led Estonilo]

Good day, I have a problem with my code, im a student testing things with servlets and stuff.
the following code is a class which handles querry in a database. I like to put this to a separate class so
that i can reuse this code. the problem is when i Try to test my code, it throws a
NullPointerException. it may sound like a newbie question but can I pass the Statement Object
to JSP or other classes

    
Class sampleClass extends HttpServlet{

private ResultSet rs;

public void setRs(ResultSet theRs){
rs = theRs;
}

public ResultSet getRs(){
return rs;
}

public void querryNow(String querry){
Object MyObjCon = getServletContext.getAttribute("someAttribute");

Resultset rs;
Connection con;
Statement stm;


try{

com = (Connection)MyObjCon;
stm = con.preapareStatement();
rs = stm.executeQuerry(querry);

setRs(rs);

}catch(SQLExeption err){
// error handling..

}
}

this is where I try to re-use the previous code

    
SampleClass doQuerry = new SampleClass();
ResultStatement rs;
String querry = "Select * from someDbase";

try{
doQuerry.querryNow(querry);
rs = doQuerry.getRs();

while(rs.next()){
out.println(rs.getString("SomeColumnName"));
}

}catch(SQLException err){
out.println("<p1>"+err+"<p1>")
}

well it compiled without errors but when i tried to run it, it
throws NullPointerException. Is my Idea possible? Did I forget
something important?

[Bauke Scholtz]

Apart from the problem, the design is awful. You shouldn´t be storing expensive resources as connection, statement and resultset as an instance variable. You should be acquiring and closing them in the shortest possible scope. You should map the results of interest to a collection of data transfer objects and use it instead. Lookup the DAO pattern.

Regarding to the NullPointerException: well, just read the stacktrace. The line number of the 1st line points to the line where it is been caused. Lookup that line in your code and find out which object references are possibly null while it is been accessed/invoked. If found, fix it accordingly by just instantiating it or by adding a nullcheck.

[Led Estonilo]

Bauke Scholtz wrote: You shouldn´t be storing expensive resources as connection, statement and resultset as an instance variable.

ohh thats the reason everytime My mentor wants to querry a database he usually retype line 15-30 again and again. looks like i need to review what I learned back then

Regarding to the NullPointerException: well, just read the stacktrace. The line number of the 1st line points to the line where it is been caused.

 rs = doQuerry.getRs(); 

is causing the NullpointerException,

If found, fix it accordingly by just instantiating it or by adding a nullcheck.

try to do that. I tried setting rs = null; or I dont know what im doing? (QQ im still a newbie)

the design is awful.

yes it is...

anyways Thank you very much for the reply, ill look up the DAO pattern and try to test some stuff.

[Bauke Scholtz]

Led Estonilo wrote:

 rs = doQuerry.getRs(); 

is causing the NullpointerException,

If found, fix it accordingly by just instantiating it or by adding a nullcheck.

try to do that. I tried setting rs = null; or I dont know what im doing? (QQ im still a newbie)

Uhm. The value of rs is irrelevant, it is anyway going to be overriden by the outcome of doQuerry.getRs().

The only reference which can be null here is doQuerry. If it is null, then invoking getRs() would throw NullPointerException. Simply because "null" doesn't have such a method.

[Ben Souther]

I like to make sure that my persistence objects have no idea that they're being used in a web application and that my web classes have no idea
how the persistence objects work.

A simple litmus test for this is to see if any of your classes import both javax.servlet.* and java.sql.*.
If any do, then you don't have a good separation of concerns.

[Led Estonilo]

Bauke Scholtz wrote:


Uhm. The value of rs is irrelevant, it is anyway going to be overriden by the outcome of doQuerry.getRs().

i mean the rs variable from the sampleClass not from where the code will be used. but i think i get it a little.


thanks for the information about the resources that can be wasted from my previous design.
Im still looking at the DOA pattern and I hope I can create a better design

Ben Souther wrote:A simple litmus test for this is to see if any of your classes import both javax.servlet.* and java.sql.*.
If any do, then you don't have a good separation of concerns.

uhmmm :?: what do you mean? seperate java.servlet.* and java.sql.* and create two seperate class which handles different jobs?

[Ben Souther]

Led Estonilo wrote:
seperate java.servlet.* and java.sql.* and create two seperate class which handles different jobs?

Yes.
Your classes that interact directly with the database should not require a servlet container to run.
You should be able to test them from the command line, or from test scripts.
Down the road, you should be able to re-use them from a non-web interface without having to change them.

Likewise, your web classes, (servlets, filters, JSPs, listeners, etc) should not need to import any of the java.sql classes or packages.
If you're looking into DAO as Bauke Scholtz suggested, you will learn how to do this.