ansaurus

Question

Answer 1

A:

Have you tried stepping through this with a debugger?

From the code posted it looks like maybe uid is being passed in as null at the top of the method.

You also shouldn't store passwords as plain text in the database, you should use a salted one-way hash of the password instead.

Paolo 2010-01-07 12:04:28

hey i tested the code removing those securerandom class call.i just passed a string value in double quoteslike "sample"and it worked.means the problem is with the securerandom class.i think the value is going as an integer in a string value field so database server is sending exception.plz give me some code to generate random string alternatively

Robin Agrahari 2010-01-07 12:09:36

Answer 2

A:

The problem you have is not related to random gen of number. You might take a look at you DB connection parameters, at the sql request you are trying to execute, ... But please, be more specific "I'm getting NPE" is not a question :)

Olivier 2010-01-07 12:05:04

Answer 3

+1 A:

There are several problems playing a role here.

First the root cause of the NPE:

java.lang.NullPointerException
    at org.tranql.connector.jdbc.ConnectionHandle.connectionError(ConnectionHandle.java:103)

This is clearly a bug in the TranQL JDBC driver. There was some unexpected null pointer during the ConnectionHandle#connectionError() method so that it was unable to handle the actual connection error. To fix this particular problem (so that you don't get a NPE, but a more clear and driver-specific SQLException), either upgrade the driver or replace it by a more decent one (I've never heard of TranQL before).

As to the real cause of the whole problem; judging from the stacktrace it look like that there's no means of an active connection. Judging from the non-threadsafe code it look like that the preparedStatement was already used before and has somehow implicitly been closed / detached from the connection.

At least it clearly boils down to the non-threadsafe and non-resourceleak-safe JDBC code you have there. The normal JDBC idiom is that you should always acquire and close the Connection, PreparedStatement and ResultSet in the shortest possible scope. Thus, already inside the very same (non-static!) method block. The statement and resultset should never be shared among threads. The connection can be, but you shouldn't take it in your own hands. Use a decent connection pool API for this, e.g. C3P0.

Here's an example according the ideal JDBC idiom:

public String recoverPassword(Long userId, String answer) throws SQLException {
    Connection connection = null;
    PreparedStatement verifyAnswer = null;
    ResultSet resultSet = null;
    String newPassword = null;
    PreparedStatement resetPassword = null;

    try {
        connection = database.getConnection();
        verifyAnswer = connection.prepareStatement(SQL_VERIFY_ANSWER);
        verifyAnswer.setLong(1, userId);
        verifyAnswer.setString(2, answer);
        resultSet = statement.executeQuery();

        if (resultSet.next()) {
            SecureRandom random = new SecureRandom();
            newPassword = new BigInteger(130, random).toString(32);
            resetPassword = connection.prepareStatement(SQL_RESET_PASSWORD);
            resetPassword.setString(1, newPassword);
            resetPassword.setLong(2, userId);
            resetPassword.executeUpdate();                          
        }
    } finally {
        // Always free resources in reversed order.
        if (resetPassword != null) try { resetPassword.close(); } catch (SQLException logOrIgnore) {}
        if (resultSet != null) try { resultSet.close(); } catch (SQLException logOrIgnore) {}
        if (verifyAnswer != null) try { verifyAnswer.close(); } catch (SQLException logOrIgnore) {}
        if (connection != null) try { connection.close(); } catch (SQLException logOrIgnore) {}
    }

    return newPassword;
}

Note that I hinted the userId to be a Long. You really don't want to have String ID's in both your code and datamodel. You can find more information, hints and other examples about writing solid JDBC code here.

That said, the following part of the stacktrace

at com.ibm.lims.LimsHandler.recoverpassword(LimsHandler.java:940)
at org.apache.jsp.recoverpasswordresult_jsp._jspService(recoverpasswordresult_jsp.java:78)

implies that you're writing raw Java code in a JSP file using the old-fashioned scriptlets. To save future maintenance and debugging problems, I would strongly recommend you not to do so, but just use a Servlet class for that.

BalusC 2010-01-07 12:10:52

sorry sir.i m creating the connection fine.i m calling another class for connection and another class for creating instance of that connection.the problem is with the secure random class

Robin Agrahari 2010-01-07 12:19:26

The exception doesn't tell that. this is also not an excuse that your JDBC code works fine. You've declared connection and statement `static`. It will work if you work alonely in a testenvironment, but this is really **major trouble** in a multi-user environment. Also, you're clearly using `ResultSet#setString()` for new password, so it really doesn't matter if it is actually an integer or a string. Besides, judging from trace, you work at/for IBM? Don't you have mentors over there? I would really consult them and have them to review your code.

BalusC 2010-01-07 12:21:47

ansaurus

tags:

views:

answers:

problem generating random no in java

related questions