Steffen Foldager

Ranch Hand
+ Follow
since Mar 22, 2001
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Steffen Foldager

Thanks, Chantal
It makes sense. During the first run of the app I could copy the files from the jar to user.dir ("C:\Programme\Java Web Start" on my machine) in some subfolder like this:
C:\Programme\Java Web Start\myApp\config\myConfig1.xml
C:\Programme\Java Web Start\myApp\users\myUser1.xml
(At ( they suggest user.home instead of user.dir, but it makes little difference whether it's one or the other.)
These files will remain in the filesystem if the user "uninstalls" the app through JWS Application Manager. I don't think you can specify an uninstall class in jnlp that could remove the files. But that is not a big problem either.
What is worse is that I have to keep track of all installed files whenever I do an update of the jars so I don't mess up the config folder with old versions.
This implies some sort of update manager that is being run every time the application starts. The advantage with JWS being that the jars are always the latest version and the update manager should only consider files external to the jars.
Of course there are alway muffins if you can live with max. 128k config files.
21 years ago
Hi all.
When making a JWS launched application, what do you do with external files for setup/configuration etc. I want to read, write and create arbitrary files on the file system which implies I use signed jars. (Out of the sandbox). Initially I can put my files in a jar, but I can't modify them or create new files.
The application is "installed" in some JWS cache directory. Is there any way to get this install dir from the Application Laucher? Is this where I put the files? Should I put the files somewhere else, possibly determined by user interaction?
How should I attack this problem?
[ January 31, 2003: Message edited by: Steffen Foldager ]
21 years ago
Java Web Start? Well, there's something obvious that I missed... And I stupid have been wondering all along what Java Web Start actually was. Embarrasing, but I'll have to look into it.
21 years ago
I am looking in to Swing applications exists that can update themselves upon logging in. I suspect they roughly work the following way:
An "updater" contacts the server and gets updating instructions. It then deletes old classes, gets new classes and configuration files via e.g. RMI, installs the new files and reboots the application. And that's it.
The question is:
Is this rougly the way these applications work? Are there any frameworks that could assist me in such a task? Are there any pitfalls that I should be aware of?
21 years ago
I think Arun's idea would work, if you could only know when a login occurs.
When logging in using Tomcat/J2EE BASIC authorization, you don't have any obvious way to know about the login event. As far as I know, that is..
21 years ago
Come on, guys...
I can't figure out whether this question is really stupid, really tricky or if I overlooked something obvious.
Is the following statement true then?
"The only way to implement a logout using J2EE authentication in Tomcat is by forcing the browser to close"
If yes, then the J2EE authentication really is of no practical use (which I don't hope..)
Somebody help me, please
21 years ago
Hi Lars (happy drumming)
My experience with this error when trying to do the same thing is that it means malformed connection string, no service running, service not accesible through firewall. Or it could be something else wich was my case.
You could try to connect using the jdbc thin protocol:
String dbUrl = "jdbc:oracle:thin:@localhost:1521:oors";
// jdbc:oracle:thin:@host:port:Database
String dbUser = "usr";
String dbPassword = "pwd";
Connection con = DriverManager.getConnection(dbURL, dbUser, dbPassword);
[ January 16, 2003: Message edited by: Steffen Foldager ]
[ January 16, 2003: Message edited by: Steffen Foldager ]
21 years ago
Using Tomcat's security feature, how can I change or delete the user credentials without closing the browser window?
In other words: Is there any way at all to implement a logout?
21 years ago
Thanks Tim.
That is a good reason why the authorization is happening outside the web application, I didn't think of that.
But still it doesn't solve my initial problem: I want to be able to log out. Without closing the browser which is currently my only option.
21 years ago
I am developing an application using form-based uthorization in Tomcat 4.0.3.
(My basic problem is that I want to log out, but until then I have another problem first..)
In my web.xml I have defined the login page:

The login page basically consist of the standard
<form name="loginForm" method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="password" name="j_password">
<input type="submit" value="Login Now">
It all works fine. When I try to access web-resource-collections protected by a security-constraint in web.xml I get redirected to login.jsp.
But if I go to login.jsp directly I get this strange behavior:
When entering correct user/pwd I get the error message "Apache Tomcat/4.0.3 - HTTP Status 400 - Invalid direct reference to form login page". But when entering an incorrect user/pwd I get send to the loginError.jsp page. Which means that at least the user/pwd get checked.
So can I or can't I link directly to the login.jsp page and perform a login? Any ideas?
21 years ago
The use of Realms is quite easy.
There is a great description here ( on how to do it. Also includes a mySql-JDBC solution.
21 years ago
Hi Gerald
The getTableCellRendererComponent method of the CellRenderer is actually very dynamic. It is called everytime changes happen to the table (being scrolled, selection changes etc.).
Actually, it is being called that often that I have run into performance issues with the above code (see other thread in this forum). Which is why you should subclass DefaultTableCellRenderer instead.
I'm pretty sure that TableCellRenderer is what you are looking for
[ July 18, 2002: Message edited by: Steffen Foldager ]
21 years ago
What are talking about? Off course I have a *really* *really" fast application
But thanks, you made me realize that I was implementing TableCellRenderer and not subclassing DefaultTableCellRenderer. So what's the difference? Wrt. performance it's quite big, so says the implementation note of DefaultTableCellRenderer (jdk 1.4).

This class inherits from JLabel, a standard component class. However JTable employs a unique mechanism for rendering its cells and therefore requires some slightly modified behavior from its cell renderer. The table class defines a single cell renderer and uses it as a as a rubber-stamp for rendering all cells in the table; it renders the first cell, changes the contents of that cell renderer, shifts the origin to the new location, re-draws it, and so on. The standard JLabel component was not designed to be used this way and we want to avoid triggering a revalidate each time the cell is drawn. This would greatly decrease performance because the revalidate message would be passed up the hierarchy of the container to determine whether any other components would be affected. So this class overrides the validate, revalidate, repaint, and firePropertyChange methods to be no-ops. If you write your own renderer, please keep this performance consideration in mind

So now I subclass DefaultTableCellRenderer instead, and the rendering of the cells is definitely more smooth. Problem solved! Case closed!
21 years ago
I am doing an application that needs Drag&Drop for reordering within a JTable. It's needs to be done with multiple selection, so the use-case is like this:
1) Select a group of rows, spread out over the table.
2) Within the same table, drag the rows to a new position. The rows are moved to new position.
Pretty simple, I should think. I have it all implemented in jdk 1.4.0 and it's working just fine.
But here's the problem: I need to either:
A) Port the above solution to IBM jdk 1.3.1
B) Have really really good reasons (with references) not to do A)
I have tried A for some time and it seems impossible to both have multiple selections and DnD within a JTable in jdk 1.3.1. All my findings on newsgroups shows the same: people having problems but no solutions. Here Georg Kraemer postulates that:
The problem with DnD is that nearly all components which support a SelectionListener have problems when the SelectionListener and the DragGestureRecognizer interfere with each other (am I selecting or dragging?). This applies not only to JTree but also JTable and JTextPane. The only workaround I have found is to disable the SelectionListener for DnD
And I think this is exactly the problem.
So now I'm stuck with B (which I prefere of the two), but I need official references to really really good reasons and I haven't found them.
So, folks, here's my question:
Is it true, is it impossible to do A)??
And if so, have anyone seen any references on the web, in newgroups, in books etc.??
Any help is very much appreciated...
21 years ago
You need a custom TableCellRenderer like this one (taken from a project so it won't work for you, but anyway it's a CellRenderer):

Then you need to associate the CellRenderer with the table like this (constuctor of class MainTable):

Then you need to associate clicks on the header with changes in the TableModel. For all this I recommend this link with lots of examples.
Have fun..
21 years ago