> This is the crux: when I take away the JDBC calls everything works
> fine except for the session persistence between server reboots. I
There are some problems in the code, including in the JDBC, but I don't know
if they cause your trouble.
> Imports not shown... no compile problems....run time errors like
> objects returned null; Typically the select component of JSF gets a
> null enumeration.
...
> /**
> * This class provides methods to interact with the session. Its
[quoted text clipped - 18 lines]
> HttpSession session)
> throws InvalidParameterException{
Crazy indentation and the lack of braces on 'if' blocks make for difficult
code to read.
Use logging instead of System.out.println(). (Even if you use println() for
debugging, it should be to System.err, but logging is much, much better.)
I'm just going to delete the superfluous System.out.println() lines. They
really don't belong in a Usenet listing anyway.
> if (value == null) {
> System.exit(0);
You said you're using JBoss? Don't use System.exit() in an application
container like JBoss or Tomcat or whatever.
> }
>
> String sessid = (String)session.getId();
You don't need to cast a String to a String.
> UserContext ucon = (UserContext)
> session.getAttribute(FrameworkConstants.UserContextKey);
> String uid="";
> if (ucon != null)
> uid=ucon.getUid();
> String uname="";
Indentation and braces - confusing when they aren't right.
> if (ucon != null) uname=ucon.getStrUserName();
> if (uname == null) uname="";
> if (!sessid.equals("notset") && uid !=null && !uid.equals("")) {
> Connection conn = null;
[quoted text clipped - 7 lines]
> String url = "jdbc:mysql://localhost:3306/jsfsession";
> Class.forName ("com.mysql.jdbc.Driver").newInstance ();
You only need to load the JDBC driver once per application run, not repeatedly
on every single freaking connection, and never need to instantiate it explicitly.
> conn = DriverManager.getConnection (url, userName,
> password);
> ps = conn.prepareStatement("update session_tbl set val=?,
> datestamp=NOW() where keyid=? and sessid=?");
> ps.setString(3, sessid);
> ps.setString(2, key);
> ByteArrayOutputStream baos1 = new ByteArrayOutputStream();
> ObjectOutputStream oout1 = new ObjectOutputStream(baos1);
> oout1.writeObject(value);
> oout1.close();
Luckily for you, ByteArrayOutputStreams don't close.
> ps.setBytes(1, baos1.toByteArray());
>
> int r=ps.executeUpdate();
>
> ps.close();
> if (r==0) {
> ps = conn.prepareStatement("insert into session_tbl (sessid, uid,
> keyid, val, uname, datestamp) values (?, ?, ?, ?, ?, NOW())");
> ps.setString(1, sessid);
> ps.setString(2, uid);
> ps.setString(3, key);
> ByteArrayOutputStream baos2 = new ByteArrayOutputStream();
> ObjectOutputStream oout2 = new ObjectOutputStream(baos2);
> oout2.writeObject(value);
> oout2.close();
> ps.setBytes(4, baos2.toByteArray());
> ps.setString(5, uname);
> ps.executeUpdate();
How come you don't check for the return value of this execution?
> }
> ps.close();
[quoted text clipped - 3 lines]
> System.err.println ("Cannot connect to database server"
> + e.getMessage());
You ignore this error after logging it. does you r log show any errors?
BTW, errors other than inability to connect will trigger this catch block.
Also, your error message is extremely weak; it would never help anyone in
operations track down an error.
As you might have seen for yourself by now.
> }
> finally
[quoted text clipped - 16 lines]
> }
> } //if
Now suddenly you switch to a whole different functionality inside the same
method. Consider refactoring - it'll make bugs like yours easier to solve.
> try{
>
> //checks if the key is null or empty. Throws an exception if
> it is.
> if(null == key || "" == key){
Don't compare Strings with ==, use equals(). This test might be letting an
empty String through to the following logic. Would that cause your error?
> Object [] values = new Object[1];
> values[0] = "key";
> throw new
> InvalidParameterException("InvalidParameterException",values);
This exception is from the java.security package - probably not the right
package. What's wrong with java.lang.IllegalArgumentException?
That would be the normal choice.
> }//end-if
Huh? "//end-if"? The block is only three lines long - did you think people
would forget?
> if(null == session){
> Object [] values = new Object[1];
[quoted text clipped - 7 lines]
> }catch(RuntimeException ex){
> throw new InvalidParameterException(ex);
Since java.security.InvalidParameterException is already a RuntimeException,
and the only one that will be thrown by the try block, you are rethrowing the
original exception wrapped in another instance of the same type of exception.
Why catch-and-rethrow at all? You could just let the exception through.
The java.lang.IllegalArgumentException. Of which InvalidParameterException is
a subtype. From the java.security package, when this isn't a security error.
> }//end-try-catch
> System.out.println("leaving set attribute");
> }//end setAttribute
You aren't doing a very good job of checking for or handling the various
SQLExceptions that could occur in your JDBC code. One of them might be
triggering the behavior you see.

Signature
Lew
soup_or_power@yahoo.com - 27 Mar 2008 18:38 GMT
> soup_or_po...@yahoo.com wrote:
> > This is the crux: when I take away the JDBC calls everything works
[quoted text clipped - 211 lines]
>
> - Show quoted text -
Lew, thanks for your comments. Some of your comments apply to the
legacy code. My code snippets are JDBC only. The Jboss+JSF is set to
store the session variables in the HTML as hidden elements. Apparently
it will only put the UI info in the hidden vars. The null exception is
happening when rendering the HTML page. Looks like Windows XP is not
the right OS to test this code. I will have to find a linux box to do
more testing. Sigh!
soup_or_power@yahoo.com - 27 Mar 2008 20:07 GMT
Looks like the code walk helped me. All I had to do was move the
session.setAttribute(...) in the setAttribute method to precede the
JDBC calls. I still don't know why it fixed other than a hunch.
Logically no matter what happens in the JDBC, the try-catch-finally
should pan out and the next try-catch block that embeds the
session.setAttribute(...) should be executed. BTW, there are no return
statements in the method and the key=="" code has been there for a
long time. So don't think that is the problem. Any comments are
welcome. Thanks!