Harry Wood

Yeah 'ps.setBinaryStream' worked for me.

...and for reading the blob back again I used:
Blob aBlob = resultSet.getBlob( "MY_BLOB_FIELD_NAME"); byte[] theBytes = aBlob.getBytes( 1, (int)aBlob.length() );
Trying to use 'resultSet.getBytes' seemed to work, but it always came back with 86 bytes of useless poo (???)

Probably all depends what JDBC driver you're using though.

Thanks for your help everyone. I think I've cracked it, in a roundabout sort of way. As always, the solution has raised new problems, which I'm slowly puzzling through.

GridLayout (as Rachel suggested) and also BoxLayout seemed to fit the bill, but the problem I was having with both of these, was that they seemed to be spacing my components out horizontally, but...

...actually I was confusing myself. The components are JPanels, which in turn contain JButton component. I forgot to set the width on the JPanels, and so they were expanding themselves to take up the available space, while the JButtons (visible) were fixed width. Hence the annoying horizontal centered spacing effect, was resolved by setting the widths. Is there a way to tell a JPanel to choose the smallest possible width? (contract around my JButton, rather than expanding to the layout grid cell width). Currently I've told the JPanel's preffered width to equal to the JButton's preferred width, but it seems to want to make a few pixels of padding, which I dont want. Is there a container padding setting?

The other problem was with verticle centering. I fixed this by putting all my components within another JPanel, then telling the outer panel to be FlowLayout(FlowLayout.LEFT), so that the inner panel was placed in the top left (easier/better way of doing that?)

I'm fairly new to this LayoutManager stuff, and its driving me nuts. This should be easy enough.

I want to arrange rectangular components side-by-side. The width of each component is the same, and remains fixed. The number of rectangular components (and therefore the total width) will vary dynamically.

I want to do this inside a scroll-pane. When there's lots of them, they will go off the edge, resulting in a horizontal scroll-bar (not flowing). When there's only a few, they should be left justified, still butting up against each other, with space on the right.

Simple enough right? But no matter which layout manager I try, it always does some centering, and spaces them out, instead of keeping them up against each other. Very frustrating.

It think there must be some error ocurring during normal execution of your java code. Take a look in the console (in internet explorer go to tools menu -> sun java console) to see if there's any Exceptions being reported.

We have an applet which spews debug information (such as error stack traces) to standard out. This can then be viewed in the sun 'java console'. But the information is also being written to a file in the user's profile space.

(USER'S PROFILE)\Application Data\Sun\Java\Deployment\log\plugin142_02.trace

Now in some cases the applet is going haywire and spewing an exception stack trace repeatedly. This all goes into the file, and actually fills the user's profile space!

Obviously the repeated exception throwing is something we need to track down and fix, but I was a bit surprised that applet was able to have such a destructive effect. Maybe it's because it requires extra security permissions (for other reasons), and so it's allowed to do this. Or maybe any applet could do the same damage in this way.

Anyway... Anyone know any tricks with the windows java plug-in, to help with this problem. Ideally I should be able to limit the size of the trace file, so that it only stores the latest 1000 lines added.

I have a JTable where the user is allowed to select rectagular areas. I want to prevent the rectangular selection ever going over the leftmost column. Well in fact it doesn't matter if the user drags a rectangle over this column, but I don't want a click on single cell in the leftmost column to remove the previously selected rectangle.

I am going to try to do this by storing the selection state after every change (ListSelectionListener.valueChanged), and then immediatly reverting any changes which include the leftmost column. But this really seems like a ugly workaround. Anyone know a better way of preventing selections in one particular column.

In general it seems quite difficult to take control of rectangular selections in a JTable. The ListSelectionModel is really designed for Lists after all. Maybe someone has alternative implementations, or a wrapper class which makes this easier. Wishful thinking perhaps.

Any suggestions much appreciated.

Do you have the .java files?
If so, it's probably best to delete to .class files. JBuilder (and other IDEs) will typically show you your java files, and will compile them, and organise the .class files for you, in a seperate hidden location. Just place your .java files all together in your project, and you should be able to get it to compile.

If you don't have the original java files you could just tell JBuilder that these class files are an 'external library' which is needed to compile your project. I think it's in 'project properties' -> 'paths' -> 'Required Libraries'

Alternatively you might like to try decompiling the class files. After all you want to get back your original source code right? This sounds complicated, but actually its a very easy thing to do. Just download DJ decompiler, and open your class files into it, to retreive the original java.

Which of the Collections should I be using in the following situation?

I have a bunch of Strings, each with an assoctiated int ID.

I want it to have ordering. i.e. I add items in a particular order, and then retreive them in that same order (this rules out Hashtable)

I could create a diddy little class with two member variables: int ID, and the String. Then I add instances of this class to a Vector (or ArrayList). However this is such crappy little class definition, for such a common problem. I dont want to clutter my project with a new class definition. I mean what do I call a class containing just an int and String? Is their built in java class for a pair of Objects perhaps.

A second approach would be to make two Vectors. One for the ids and one for the Strings. This is clearly not best practice, since the values could become missaligned, if I add to one Vector, but forget to add to the other for example. But for such a simple thing, I am tempted by this bad approach

My problem is that this chunk of code should really look and feel very very simple, and yet I dont see a java Collection which caters for it.

What examples are you working from?
Are you sending serialised java objects in a HTTP request from applet to servlet?
This is what I do in my code:

url = new URL(jspURL, "my.package.structure.servlet.ServletName"); URLConnection urlconnection = url.openConnection(); urlconnection.setDoInput(true); urlconnection.setDoOutput(true); urlconnection.setAllowUserInteraction(false); urlconnection.setUseCaches(false); urlconnection.setRequestProperty("Content-Type", "application/x-www-form-urlencoded"); //Stream for sending the HTTP request ObjectOutputStream objectOutputStream = new ObjectOutputStream(urlconnection.getOutputStream()); objectOutputStream.writeObject(requestObject); //Send request object objectOutputStream.flush(); //Stream for receiving the HTTP response ObjectInputStream objectInputStream = new ObjectInputStream(urlconnection.getInputStream()); responseObject = objectInputStream.readObject(); //Read response Object objectOutputStream.close();

The last three lines are to receive a response from the servlet. In my case this is also serialised java objects. Are you saying you don't want to receive a response? Maybe you could just drop these last 3 lines. Not sure.

Thankyou bear. You nudged me in the right direction, and now my login servlet is working like a dream.

I will describe how what I did, for the benefit of others.

It turns out that the servlet generated from the JSP does work correctly, in exactly the same way as the JSP. I was being stupid and looking at the wrong URL while testing it.

I only noticed this while doing as you suggested and checking if I was dealing with the same session object. I did this by doing a toString on both the session object and the bean object, to compare the object IDs. (Is that what you meant? Probably there is some better way to test this)

You said it was harmless but unnecessary to set the bean back to the session with the session.setAttribute("icClient", icClientBean); line. So I tried taking this out. In fact I had suspected this already, and had tried it before.

The resulting effect is that the login servlet works, and re-logs-in sucessfully after going to a 'logout.jsp' (which does session.invalidate). But then it breaks in the other two cases: if the session is destroyed because the server is re-booted, or if the session times out.

Then it ocurred to me that these two cases are where the bean is null and therefore must be re-created. So the fix which nailed this problem was to set the bean back to the session, only at the top in position shown here:

synchronized (session) { icClientBean = (com.inconcert.xml.sax.IcClientBean) session.getAttribute("icClient"); if (icClientBean == null) { out.print("Beans.instantiate <BR>\n"); icClientBean = (com.inconcert.xml.sax.IcClientBean) Beans.instantiate(this.getClass().getClassLoader(), "com.inconcert.xml.sax.IcClientBean"); session.setAttribute("icClient", icClientBean); //<-- HERE } }

So it seems 'harmless but unnecessary' was not entirely correct. Calling session.setAttribute("icClient", icClientBean) was actually breaking the connection. In the absence of this call at the bottom, the connection persisted correctly. (something to do with serialisation?)

However it is necessary to make this call at the top, if the bean was found to be null in the session. Which seems obvious now that I look at it

I can't believe it finally works just by moving that line. Thanks for your help with getting to the bottom of this!

When writing the servlet myself I looked at the servlet code generated from the login.jsp, and decided these are the bits I need for getting the bean from the session. (Note the logic to create a bean instance if it is not already present in the session)

synchronized (session) { icClientBean = (com.inconcert.xml.sax.IcClientBean) session.getAttribute("icClient"); if (icClientBean == null) { out.print("Beans.instantiate <BR>\n"); icClientBean = (com.inconcert.xml.sax.IcClientBean) Beans.instantiate(this.getClass().getClassLoader(), "com.inconcert.xml.sax.IcClientBean"); session.setAttribute("icClient", icClientBean); } }

Lower down I just do this to set the object back to the session if I've managed to make a connection.

session.setAttribute("icClient", icClientBean);

After that I tried adding a test which pulls the bean out into a different variable, and check if it it's still connected. It is.

But if I open the next JSP in the same browser, the bean object is retreived, but is no longer connected.

So I was thinking maybe there's something I'm not understanding about 'session.setAttribute'. The generated servlet does not do this in fact. At least not directly. It winds up its operations with a '_jspxFactory.releasePageContext' (internal JSP engine tricks which presumably includes setting the bean back to the session)

but even if 'session.setAttribute' is not behaving as expected, how is it possible that running the generated servlet code (complete with _jspxFactory.releasePageContext) as a servlet, does not have the same effect as running the JSP?

I also saw
java.sql.SQLException: Io exception: Broken pipe
or sometimes
java.sql.SQLException: No more data to read from socket

I did manage to make the problem go away, but my fix is not very clean and efficient.

I'm working with an old JDBC version which doesn't provide 'DataSource' connection pooling, so I'm having to use DBConnectionBroker from javaexchange.com to connect to Oracle

This worked fine most of the time, but then DbConnectionBroker started returning dead connections, which cause the above errors when I run queries.

The trick is to detect dead connections before DBConnectionBroker returns them for use. It already has a 'housekeeping thread', which should find these dead connections, and reestablish them. It runs the checks every 20 seconds. Before it called connection.createStatement to see if the connection was still alive, but I found with oracle JDBC this test was not enough. It was allowing createStatement on a connection object which was dead (and destined to cause an error later)

I changed it so that it actually fires a query, to be absolutely sure the connection is alive:

stmt = connPool[i].createStatement();
ResultSet rset = stmt.executeQuery("SELECT SYSDATE FROM DUAL");

Although this must be a pretty fast query for the oracle server to cope with, it also an unnecessary query, which it is firing it every 20 seconds. So this seems like a bit of an ugly inefficient solution. Anyone have any better ideas for detected dead connection objects?

Weird problem, and difficult to describe.

I'm trying to create a servlet which behaves in exactly the same way as an existing JSP. The JSP uses the special (JSP only) 'usebean' command.

I will have to explain what the bean is.
I have a web-app containing JSPs and a bean class, supplied as a vendor product (TIBCO InConcert ICWeb) which I am customising. The IcClient bean maintains a connection to an external system (InConcert). Calling the method 'isConnected' on this bean, tells us if the user is logged on.

The 'login.jsp' supplied in the web-app is working fine. It contains a 'usebean' command, and calls an initialisation method on the bean to set it up. All subsequent JSPs will find that the bean's 'isConnected' method returns true. The connection inside the bean is persisting between requests.

Now I need a servlet which does exactly the same thing. I tried writing this myself, so that it does the following:

checks if the bean object is allready in the session.

...if not it creates a new instance.

Calls the bean's initialisation method to make a connection.

Writes the bean object back to the session.

This is not working. All the above steps execute fine, but when I navigate to another page, the bean's 'isConnected' method returns false.

For weeks I have been scratching my head, trying to figure out why this is not doing exactly the same thing as the JSP.

Today, out of desperation, I abandoned my own servlet code, and took the servlet class which my webserver generated from 'login.jsp'. I renamed this and put it in with my servlet package, but still the servlet is behaving differently to the JSP, and 'isConnected' winds up as false.

DB connection pooling JSPs/servlets
Surfing the internet on the topic of database connection pooling left me a little bit confused, because there are two different approaches. There is a whole chapter in the O'reilly book "Java Server Pages" which clarifies this nicely (get it from safari.com)

Here's a sumary:
You can either use a JDBC 2 DataSource object, which means the webserver manages the connections, or you can have a java class which manages connections. JDBC 2 Datasource approach should be your first choice. It involves putting a <resource> tag somewhere in your web server configuration. This is web server specific, and is not supported by all web-servers. I am having to use the static class approach. I am using DbConnectionBroker from www.javaexchange.com There's a different one from here here: http://www.webdevelopersjournal.com/columns/connection_pool.html Either way you should construct the manager/broker class in your servlet/JSP init method.
For the connection itself, you should always get --> use --> release a connection for every request (i.e. in the 'doPost' method). Don't get a connection in the init method, and Dont keep a connection as a session variable, or in a bean. It might seem like a good idea, but it isn't.

Yahoo uses a big applet, but it's difficult to tell how the applet communicates to the server. Yahoo also used to offer a plain HTML version of the chatroom. Not sure if it still does.
The normal approach is sockets or RMI, but it is also possible to send HTTP requests from an applet back to the server. You can even send serialised java objects over this connection. Works quite well actually. The HTTP requests go through firewalls no problem (looks like normal browser traffic to the firewall), but it will require the applet to be signed (and new users have a big ugly security warning message, where they have to 'trust' the applet)
Plain HTML based chat rooms are possible. here's a good example: http://chat.nme.com/ Look at the HTML headers to see how the refreshing works. Really this is not what the technology was intended for. Imagine what's happening in your webserver log files, when every chatter is refreshing so often. It's not a scaleable approach.
Also from past experience, you should give careful consideration to whether you really want a chatroom on your site. If your site doesn't get many visitors, then a chatroom will only serve to underline that fact, since it will always be empty! Start by implementing discussion forums. If these start to get really lively (100s of users and 2 or 3 new posts every minute) then it's worth having a chatroom.