Looking around for an easy way to create applications with text GUIs for running over SSH terminals I came across CHARVA. CHARVA’s API copies Swings, it unfortunately is not built on top of Swing but is a copy of Swing. This forces implementers to import classes in the charva.awt and charvax.swing packages instead of traditional awt and swing classes. However, the result is rather nice, at least if you’re looking to run applications off a server on a simple Point-of-Sale or Point-of-Service (POS) terminal that may not even support graphics.
In my case I’m looking into making a simple app that I can use to keep track of passwords, both when I’m at home (regular swing) and when I’m away (at work or similar) and only able to access the application via SSH (CHARVA).
I’ve just had the rather unsettling experience of trying to deploy a new jar file (one I recompiled after some changes). This file were to be deployed on a rather old set up of Java 1.4.2. On first try everything broke with the classic “Unsupported major.minor version 50.0”.
So I went back to the drawing board. I installed java 1.4, and made sure my development Tomcat was running it. Then I did some research and found out how to make Eclipse compile 1.4 compliant code. I started and I got the same error still.
Once I figured out what was wrong I realized I was an idiot (Doh!). The error I’ve gotten wasn’t for any file part of the jar I was trying to deploy but for “index_jsp”. The thing is my Tomcat compiled my JSP:s into class files and never looked at them again until they were changed. I am sure there’s several ways to solve the problem, I just went and deleted the files in the “work”-directory (those pertaining to my Context).
The preferences window for setting source and target versions for Java compilation
Now over to how to make Eclipse code projects to a certain Java version.
There are two values you will want to keep track of. The source version and the target version. The source version tells what version your source code is written in. Whereas the target version tells what version of Java you want your class files in.
If for instance you have a project written in Java 1.4 source style, but you have to run it on a Java 5 you’d set the source version to 1.4 and the target to 1.5. You are now compiling Java 1.4 source into Java 5 class files. Unfortunately you’re not able to do the opposite, compile Java 5 source code into Java 1.4 class files. This is probably due to API incompatibilities, Java 5 has a larger API than Java 1.4.
Now, in Eclipse you have two settings in three places that controls the source and target versions of your compilations. Under Window->Preferences->Java->Compiler (Eclipse 3.4) you’re able to set the versions for the whole IDE.
When you create a new project you’re able to determine what version of Java (source and target you want) and right clicking on a project and choosing Properties->Java Compiler, you have the same dialog as before.
You set the target level in the select box “Compiler compliance level”, and optionally by unchecking the “Use default compliance settings” you’re able to change the target (“Generated .class files compatibility”) and source respectively.
If you experience other problems you may want to “clean” your project(s). Cleaning a project means all compiled files are removed and all source files are recompiled (something the IDE will do by itself when you change compilation versions, but if you want to be sure, you can do it manually). This is done by choosing Project->Clean. In the dialog you can chose to clean all projects or just those you select.
Opening a site Google has listed as spreading malicious software via the browser. In this case the site was the victim of SQL-injections.
What are SQL-injections? How can they affect my site? How does it happen and how can I avoid it?
Your site may already be under attack, but the attacker is only using your site to attack your users! This is done using something called SQL-injections.
Since Firefox (2 and 3) and MSIE 7 started using Google’s (and others) system for blocking sites that produce harmful web pages the problem with SQL-injections have been put on the spot.
What happens is that an attacker hacks a site by placing their own SQL-code into the database of the victim system. A system open to SQL-injections may be attacked in basically two ways. Either the attacker performs a DOS (denial of service) attack. This could be done by deleting all the tables or doing something else harmful to the site, effectively bringing the whole site down.
The other form of attack that can be performed on systems open to SQL-injections is far more sneaky and may not be detected at all by the site owner or the site visitors. This form of attack consists of planting client side browser code in the database making all visitors run client side code that will infect their computer with malware or viruses. This malicious software may do everything from listening in on traffic between the client (web browser) and bank sites, to connecting the client system to a botnet.
Needless to say, attacks using SQL-injections has become a problem not so much for the owner of the originally defunct site as for the visitors to said site. Although users of the web should not underestimate the consequence of a good virus protection, system update policy and secure browsing policy.
Since the owner of the vulnerable site won’t notice any detour from business as usual and neither will most infected clients, nobody is the wiser to the problem.
This is why Google (and others) have started evaluating (and flagging) sites with bad content, and why Firefox and MSIE (and probably others) have started blocking them.
I’ve come across a problem in one of my projects at work. It consists of searching and replacing data in a MySQL server. The data to be replaced is an old URL used in lots of text fields all over the place, it is the customers own site URL but since they moved, they now want all URLs to point to their new location.
Searching the web and checking up the MySQL function database returns the following useful command:
REPLACE(str, from_str, to_str)
It would in my case be used like this:
UPDATE myTable SET theTextField =
REPLACE(theTextField, 'http://the.old.site', 'http://the.new.site');
myTable is the table containing the data I want to replace, theTextField is the exact field in which this data is located. Obviously “http://the.old.site” is the existing information, that I want to replace, and “http://the.new.site” is the information this string should be replaced with.
Very simple, very elegant (well… if you forget about the site URL in the database in the first place…) Now all I have to do is try it out as well. (Expect more reports on the progress of this work!)
