To compile or not to compile?

That is the question... I had a conversation with a few guys from our local Java Users Group about PHP, Ruby, (scripting languages in general) vs. compiled languages. I have a background in both so I had some strong opinions and thought I'd jot some of them down.

First off, I am of the opinion that scripting (dynamic) languages and compiled languages have their own respective places in programming. There are good and bad languages out there and whether or not they are compiled doesn't enter that argument. People calling scripting language users "hacks" is ridiculous. This is most likely coming from someone having done compiled language development all their career. The one time they tried scripting something, they got bit by the loss of type safety or could not "refactor" or something along those lines. We mock that which we don't understand...

The fact is, scripting languages give you more flexibility, but with that comes responsibility. I worked in a group that did scripting for Web stuff and we had TONS of code, no IDE (just vi) and had successful "deployments" all the time. You have to know what you are doing when you start messing with a scripting language code base. Now if you start mucking with some code written in Java, you can use an IDE to help you along the way. I think it much easier to get your feet wet in Java once you understand OO due to the great IDE's out there that will help you. But once you get going with PHP or Ruby... you can fly, and your development becomes more agile due to the flexibility an interpreted language gives you.

I write code in a few languages, compiled and dynamic... and the bottom line is: the code you write is really just a dumbed down human version of instructions, it's documentation. A compiler (at some point) interprets your mess and sometimes through more conversions finally makes something the computer can understand. You can't argue which is better unless you are talking about a specific problem domain with all else equal.

Happy coding!

Trying new setup…

So I heard about NginX and figured I'd give it a try. The setup for NginX (pronouced engine X) was a breeze. I have a few Mongrels running behind it and things seem to be going pretty well at the moment. I still would soo much like to see a nice packaged server solution for Rails running in a multi-threaded environment. YARV, hurry up! :)

Benefits of Ruby

For me, one of the real benefits so far is getting me back into the C world... I've been away for some time doing Java mostly so it's fun to get back into the swing of things.

I've just recently found the YARV project. From what I have seen so far, it appears to be working toward a multi-threaded version of Ruby which makes me very happy! Ruby is a very cool language and serves a good purpose. Rails is wonderful for getting things off the ground soo quickly... but in today's web world, non-thread safe languages pose a few barriers.

These barriers can definately be overcome (and are everyday) but the web is a multi-threaded world... if YARV does push Ruby into the MT way of things, I think it will only serve to boost the already crazy swirl surrounding the Ruby/Rails phenomenon.

The right place at the right time…

I had to replace the glass in one of my patio doors so I went up to Home Depot like any other average "think I'm a handy man" joe would do to try to buy a replacement. They don't carry replacement panes in stock, of course, so I had to order one which would run me approx. $96 dollars and would not come in for another 6 to 10 biz days.

We put up with the broken glass patiently awaiting the arrival of the replacement which eventually came in. I get the glass home, removed the broken piece and begin to lift the replacement into place... you can see it coming can't you... it didn't fit!!! It was too big! I was extremely upset to say the least. I took the "no good to me" glass pane back to Home Depot where I argued with the service department about who's fault it was and finally got my money back.

I decide to try my luck with Lowes which is farther from my house. I mentioned the situation to folks at the door department and asked what my options are... he replied "could be very good". Apparently someone had ordered a replacement pane for their patio door but had ordered the wrong size as well. I walked out of there with the replacement for $20!!!

I wonder if the person who's glass I got went to Home Depot and bought the pane I ordered... nice way to save some money! :)

So what’s this Ruby thing all about…

OK, I've broken down and am looking into the Ruby thing.

First thoughts, love the syntax, great to be back in scripting environment again after years away, love gems (cpan rip-off but very nice), hate the fact that Ruby is not thread-safe... yet???

In all, Rails is what brought me to this. I like the way things are convention over configuration...

I've only just started, have some ideas I want to try out... we'll see, just having fun for now... ;)

Disable Cert Validation for LDAP and HTTP over SSL

Have you ever been developing something requiring a connection to a development server over SSL? Was the server not under your control? And you had either an invalid, corrupt or possibly no cert at all to add to your trustStore?

We won't go into why this scenario may occur... but I know there are quite a few people out there asking how to bypass the cert validation for HTTPS and LDAP over SSL (LDAPS) connections.

The place to start is the SSLSocketFactory and more specifically the TrustManager you use.


In the sample reference file "BlindSSLSocketFactoryTest.java" we establish connections to HTTPS and Active Directory via SSL (LDAPS) servers without valid certs by using our own SSLSocketFactory. We need to come up with a SSLSocketFactory that will use a TrustManager list we specify as an alternative to the SSLSocketFactory that will be used by the JVM.

Our socket factory will create a real SSLSocketFactory using an X509TrustManager created as an anonymous inner class with methods designed to simply fall down on the job when asked to validate certificates. All of our implementations of the SocketFactory's methods will in turn call the created SSLSocketFactory's methods. To use this class when connecting to an Active Directory server over SSL, we simply have to specify the "java.naming.ldap.factory.socket" property in our ldap context environment.

The example below is taken from the main method of the BlindSSLSocketFactoryTest class:

[sourcecode language="java"]
boolean validateCert = false;

// ... clipped ...

// our environment
Hashtable env = new Hashtable();
// complete URL of Active Directory/LDAP server running SSL with invalid cert
String url = "ldaps://:636";
// domain is the Active Directory domain i.e. "yourdomain.com"
String domain = "";
// the sAMAccountName (i.e. jsmith)
String login = "";
String password = "";

env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, url);
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, login + "@" + domain);
env.put(Context.SECURITY_CREDENTIALS, password);

if (url.startsWith("ldaps") && !validateCert) {
env.put("java.naming.ldap.factory.socket", BlindSSLSocketFactoryTest.class.getName());
}

try {
LdapContext ctx = new InitialLdapContext(env, null);
System.out.println("Successfull bind to " + url + "!");
} catch (AuthenticationException e) {
System.out.println("The credentials could not be validated!");
} catch (NamingException e) {
e.printStackTrace();
}[/sourcecode]By using our "blind" SSLSocketFactory, we will be bypassing the cert validation when connecting to the Active Directory server.

Another use for our handy little class is to bypass cert validation when connecting to an HTTPS server. Another example from main method:

[sourcecode language="java"]
// host name of server running SSL with invalid cert
String host = "";
int port = 443;// modify this if other than default port.

try {
SocketFactory sslFactory;
if (validateCert) {
sslFactory = SSLSocketFactory.getDefault();
} else {
sslFactory = BlindSSLSocketFactoryTest.getDefault();
}

SSLSocket s = (SSLSocket) sslFactory.createSocket(host, port);
OutputStream out = s.getOutputStream();

out.write("GET / HTTP/1.0\n\r\n\r".getBytes());
out.flush();
System.out.println("Successfull connection to " + host + ":" + port + "!");
} catch (IOException e) {
e.printStackTrace();
}[/sourcecode]As the security zealots will tell you, the best practice is to get a valid certificate and install it in your trustStore using the keytool and I agree with this. But that being said, some of the scenarios described above still may occur during development and if you have a tight deadline to get a prototype out the door, this class/code may help. Corrupt certs from servers you don't manage can be painful when trying to get the other party to move on something that is not deamed mission critical in development.

So take this code, create your own BlindSSLSocketFactory class (don't be lazy and just plug this in!!!) and let me know if it works for you. (click here to download)

Comments welcome...

Housebreaking your Tomcat

If you have written a servlet or a single JSP, it is almost guaranteed that you have used Apache's Tomcat Server. Whether you use it for development, to run intranet applications, or to serve your production needs... Tomcat is ready and willing to step up to the plate.

There are many different ways to manage your Tomcat instance, but for a great "Web 2.0" interface with lots of bells and whistles, take a look at Tomcat Probe.

Tomcat Probe is the ultimate tool to manage and monitor your Tomcat instance. Lightweight web user interface, killer features, no-fuss installation and weekly updates. Tomcat Probe gives you total control over live Tomcat instances and applications.

The interface provides for the management of deployed webapps, JSP's within apps, and data sources. You can view all kinds of stats for threads, charts for traffic information, download log files, call the garbage collector and much more. All of this with a great looking interface.

Even if you don't have a need to use this tool, it is worth a look.

Web Services in minutes with Apache Axis

Have you ever worked on a project that has been successfully deployed for some time only to have the topic of integration creep into the picture late in the game? Lucky for us there is an easy and efficient way to deploy Web Services for integration literally within minutes! If you've been faced with such a situation or are simply curious, please read on!

I recently ran into this scenario and can tell you the documentation will take you longer to produce than the actual implementation! We'll be using Apache's Axis project to implement our Web Service.

Apache Axis is an implementation of the SOAP ("Simple Object Access Protocol") submission to W3C.

For this blog entry, we'll assume you have a pre-existing web application with certain functionality you would like to expose. We'll also assume we only need to get a string representation of the current time on the server (yes, very simple... but how many times do you want to see "Hello World!"?)

Let's get started, download the latest version of Apache's Axis project located here (get version 1.3.) Unzip the file you downloaded and copy the jar files from axis-1_3/lib to your application's WEB-INF/lib directory (don't need to copy any libraries you already have of course.) Put the following entries in your application's web.xml file:

[sourcecode language="xml"]


org.apache.axis.transport.http.AxisHTTPSessionListener




AxisServlet

Apache-Axis Servlet


org.apache.axis.transport.http.AxisServlet




AxisServlet
*.jws



wsdl
text/xml


xsd
text/xml
[/sourcecode]Create a file named MyWebService.jws in the root dir of your web application (along side index.jsp or index.html) The contents of this file should be:

[sourcecode language="java"]
import java.util.Date;
public class MyWebService {
public String getTime() {
return new Date().toString();
}
}[/sourcecode]
OK, take a deep breath... your done. Now you obviously want to test this, there is plenty of documentation for Axis to help you write your own unit tests. But in my case, the primary integrating system was written using PHP 5 and planned to use PHP's new soap extension. (Be careful here, PHP 5's soap extension is not compatible with Axis 1.2 only 1.3!)PHP can integrate with this service VERY easily as well, to test I got the latest for PHP 5 and wrote the following:
[sourcecode language="php"]
$serviceWsdl = "http://localhost:8888/" .
"test/MyWebService.jws?wsdl";

try {
$client = new SoapClient($serviceWsdl);
echo "The time returned by the server was: " .
$client->getTime();
} catch(SoapFault $fault) {
echo "there was an issue : \n" .
" faultcode: $fault->faultcode\n" .
" faultstring: $fault->faultstring\n";
}[/sourcecode]
That was it... my PHP script printed the time in "toString" format from my server.Now for the disclaimer, each application will have it's own requirements for integration. Although Axis is a great tool for Web Services, it should not be viewed as the magic hammer for all jobs. There may not even be a need for Web Services written using SOAP as mentioned in a blog entry by Luis Perez.That being said, I believe Apache's Axis project is a great way to get your application out there with Web Services quickly and efficiently.