Trusting any “secure” host

Posted on January 23, 2010 by Jesper Udby

My main concern is developing server-side JAVA-applications: J[2]EE applications.

When working with hobby-projects, I’m often faced with situations where I need to call other “third-party” applications over HTTP, in order to obtain some information important to me in specific situations.

It is not uncommon for local/public organizations to publish sensitive information over HTTPS where the SSL-certificates are not signed by some known issuer.

Also when working with SSL in test-setups, one usually don’t spend time and money on “real” certificates, but uses self-signed certificates.

This is generally not a problem as I as a user can select to accept “invalid” certificates, when contacting a host that I trust.
Contacting hosts with invalid certificates using a browser is not a problem: one just accepts the invalid certificate or import the unknown issuer into the trust-store.

When contacting those hosts using JAVA, one is faced with a SSLHandshakeException:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1611)
	at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:187)
	at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:181)
	at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1035)
	at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:124)
	at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
	at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1112)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1139)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133)

Continue reading →

Posted in Java | Tagged , , | Leave a comment

Writing JDBC code: resource cleanup and exception handling

Posted on March 29, 2008 by Jesper Udby

No matter how nice an ORM tool used in the project, CMP, Hibernate or JPA, You will eventually have to start writing “low-level” JDBC code. Most often for performance reasons, sometimes just to utilize some database-vendor-specific feature.

Or calling stored procedures…

I’ve written lots of “low-level” JDBC code – most done in the days of 1.0..2.1 EJB CMP where some fastlane pattern was often necessary to deal with complex queries.

Most “query” code looks familiar to the sample below:

Connection con = null;
PreparedStatement ps = null;
ResultSet rs = null;
try {
	con = getConnection();
	ps = con.prepareStatement(sql);
	//... set parameters
	rs = ps.executeQuery();
	while (rs.next()) {
		//...handle result
	}
} catch (SQLException e) {
	//...exception handling
} finally {
	if (rs != null) {
		rs.close();
	}
	if (ps != null) {
		ps.close();
	}
	if (con != null) {
		con.close();
	}
}

This particular piece of code has always been a nuiscance to me, for the following reasons:
Continue reading →

Posted in Databases, Java | Tagged , | 1 Comment

The “changing the database” experience

Posted on June 17, 2007 by Jesper Udby

I have been involved in Enterprise JAVA projects since 1998. Almost all projects have had an RDBMS “behind” it, mostly Oracle and DB2.

All the projects have been some custom defined application often based on existing infrastructure, and the database vendor and version has been predefined from the beginning.

Still, there has almost always been a more or less explicit demand that the application being developed should be easily ported to another database vendor. Until now, this has never happened to me; I have never been in a situation where the customer suddenly decides to change their entire database infrastructure from one major database vendor to another.

Except for one situation: I was involved in a project where we were developing a version-2 of an existing application. The original application was based on Microsoft tools and databases; the new application was to be based on J2EE and Oracle.

The demand that the application should be easily portable to another database basically has the following impact on the development:

  • Use a good, preferably a standard-, ORM tool can help hide technical details about the database integration, and can enable you to write your queries in an “abstract query language”.
  • Minimize the use of native SQL, vendor specific database features, stored procedures, triggers and user defined functions. They will have to be portable and a database specialist is often needed. Some features in one RDBMS might not have comparable features in other RDBMS’.
  • Hard coding SQL in the application is forbidden – all SQL must be in configuration files external to the code to ease translation.

Of course, if the application is a general component or a product to be used by many different customers or users, the demands on the database integration is even harder – you can only rely on the most basic features common to all the supported databases.

There are other good reasons for points mentioned above, but in this article I’m taking the perspective of creating applications that are easily ported to other databases.

In the following I will discuss some of the experiences that I have had with a recent project, where we ported the entire persistence layer from Oracle to PostgreSQL.

Continue reading →

Posted in Databases, Java | Tagged , , , , , , , , , | Leave a comment

Real world distributed transactions in J2EE – Not ?

Posted on June 16, 2007 by Jesper Udby

I’m on this project where we develop a component. This is a J2EE component, it has its own database and it does some mainframe communication. This component is to be deployed on a WebSphere application server, version 6.1 (WAS).

The component is to be used by a specific J2EE application. This application is to be deployed on an Oracle Application Server (OC4J) – possibly version 10.1.3.1. The application also has its own database…

Transactions are really important to this component. The “local” database has to be “in sync” with the mainframe, and we are taking care to have 2-phase commit (2PC) between the component, the database and the mainframe. Note that the mainframe is allowed to rollback a transaction during transaction completion.

Transactions are really important to the entire application; the application database, the “component local” database and the mainframe has to be “in sync”. Basically the global transactions are started in the application, propagated over the component into the mainframe and back…

Now, everything except the mainframe is Java and J2EE so the question about how to have the different subsystems participate in global distributed transactions should have an obvious answer: use session beans and RMI/IIOP.

Right?

Continue reading →

Posted in Java | Tagged , , , , | Leave a comment

Why I love PostgreSQL

Posted on May 22, 2007 by Jesper Udby

Now, I’ve written some ranting about why I hate MySQL, now it is time to write about another Open Source RDBMS, PostgreSQL.

In this blog I am going through why I think PostgreSQL is a great database – comparable with the most advanced commercial database products.

I have worked mostly with DB2 and Oracle in my professional life. Although DB2 and Oracle are quite different, there are a lot of features they have in common, that you get to expect from a professional database.
Then when I started looking at MySQL some years ago, I got quite surprised to find that it lacked most of the data-integrity features that you would expect any decent RDBMS to have, and that the SQL dialect and supported data types were quite different from the ordinary.

As a freelance developer and an OSS enthusiast, I wanted a serious Open Source RDBMS and somehow found PostgreSQL. This was back when it was a version 8-beta something. The first PostgreSQL version to have a native windows install.

I will start with repeating some of the perhaps-obvious features that PostgreSQL has:

  • Lots of native data-types: integer types, arbitrary precision numeric types, time-, date- and timestamp types (with or without time zone), network types, geometric types, Booleans, arrays and user defined types. With no “surprises” in the implementation.
  • Views.
  • Triggers, stored procedures, user defined functions.
  • Transactions; 2 out of 4 standard isolation levels supported.
  • Indexes; on any column type and functional indexes…
  • Sequences…
  • Table spaces.

And worth mentioning, most of the features have been core features since the beginning.

Generally, compared to most other non-OS RDBMS in the market, PostgreSQL looks most like Oracle – if you are using Oracle already, switching to PostgreSQL is almost a no-brainer, unless you use partitioning or other Oracle specific features.

Now, I’ve written an entry called “Why I Hate MySQL” and I will start this entry trying to do a 1-1 comparison between the entries…

Continue reading →

Posted in Databases, Open Source | Tagged , , , | 7 Comments

An Open Source encounter

Posted on May 14, 2007 by Jesper Udby

I really like Open Source software. I use it a lot: Linux, apache, postfix, amavis-new, clamav, openSSL, openLDAP, PostgreSQL, PHP are just a few of the OSS products I have on my servers.

When developing JAVA, I use Eclipse, Ant, JUnit and heck even Java 🙂

OSS is actually very important for be, being a Freelance I/T consultant, it allows me to play with features, technologies and implementations, in an effective manner, without having to pay a lot in license fees!

I’m not a big committer. Not that I don’t want to, but usually when I hit a bug or a poorly implemented feature, I either accept it or code around it.

Only 3 times since I started using OSS for the first time in about 2002 have I been in a situation where I had something to contribute with:

  1. Some missing Locale handling in Struts. I was just about to submit a patch when I discovered someone else had done just that a few days before.
  2. A bug in Stripes – also related to Locales – rendering some of the features useless if the Locale does not contain a valid country code. This was somewhat accepted by Tim Fennel and made it into version 1.4.
  3. A serious performance problem in Hibernates WebSphere transaction adaptor. This I fixed and submitted as a patch and then the story being told here is about to begin.

Apart from that, I try to contribute with helpful comments when I see someone report a problem I’ve seen and possibly solved myself. At least to let the other users know there are others with the same problem.

Does it make me a bad person? I think not – I’m no more different than 99.99% of all other OSS users.

This blog entry (or article) is meant as a warning to anyone who considers making a contribution to a major open source product.

The conclusion

To start with the conclusion – here’s what I’ve learnt from trying to “do the right thing” and submit a patch to an OS project:

  1. Don’t expect to be treated with any respect at all, unless you are already a known committer – “one of the guys”.
  2. If you do commit anything, expect that you are to be considered the maintainer of the feature from that point on.
  3. Expect to have your name and personal email specified as author of source and comments that you have not written.
  4. Be aware that when you submit anything, the project owner can do with it as he pleases; even break the implementation, and still call the bug fixed…
  5. Be aware, that if you do not agree with the King of the project, he can call you anything he likes, telling that you are being spiteful and things that are worse.

Continue reading →

Posted in Java, Open Source | Tagged , | Leave a comment

Why I Hate MySQL

Posted on December 30, 2006 by Jesper Udby

MySQL databases have been offered by most web hosting companies for a couple of years. This is the main reason I still have to deal with this product, which claims to be an “enterprise ready” relational database.
Unfortunately these companies chose MySQL and did that when MySQL was a pile of crap (pre-5 versions).

Now, they are stuck with antiquated versions (4.0.x) and no reasonable upgrade paths.

In the following, I’m going a little into details about why MySQL, at least in pre-5 versions, in my point of view is NOT to be considered a serious database product.

NOTE: When I refer to “MySQL” in the text below, I generally mean pre-5 versions and typically 4.0.x versions. Flame me – but this is what is offered to me by several hosting companies…

Continue reading →

Posted in Databases, Open Source | Tagged , , , | 1 Comment