SourceBeat Author Blogs

AJP (8009) to HTTPS (8443) is supposed end in HTTPS

2008-08-20T16:52:08Z

I'm writing this blog post because I have a problem that is becoming a real pisser. I've used Apache and the AJP connector with Tomcat many times and now I'm getting HTTP ultimately from the 8443 connector. My 8009 connector redirects to port 8443 and if I call the URL using the colon 8443 I get the page HTTPS correctly. When I call the URL without port numbers and the /cas virtual, it uses the AJP/1.3 connector on 8009 because the page comes up beautifully with one problem. That is the content is HTTP (plain text).

My buddy, the CISCO expert here showed me Wireshark (damn fine Windows application) that allowed us to look at all this Apache reverse proxy, AJP, Tomcat, JBoss traffic and sure enough he showed me my password (HTTP).

I'm really stumped. This was working prior to multiple domains and virtual IPs. I usually don't "trust" certificates when I'm doing implementation work but I assumed that I had accepted the certificate some time ago and forgot all about the HTTPS. Also, with all the proxy business going on, I don't pay much attention to the browser address bar anymore.

So now I'll back up and begin to simplify. If anyone has seen this before please let me know. If it didn't work, I could understand this, but when I know that TCP traffic is going thru the 8009 and 8443 ports, I can't understand why I never get asked to accept the certificate? Bear in mind too that there's a lot of overkill here that I can't reduce or simplify for security reasons.

Signed, Stumped in the weeds here in NC

EhCache Project Busy this Summer

2008-08-11T03:12:31Z

The EhCache project appears to be having a very busy summer. EhCache 1.5.0 (a major new version) was released on July 12th. In addition, a new (SOAP-based) EhCache Server was released at the end of July. You might ask yourself why you'd need such a beast. I think Greg explains it best:

Why am I doing this? There are lots of theories that have made their way on to the ehcache mailing list. The prosaic truth is that a large US corporate using ehcache for their Java apps on 200+ servers also wants to use it for their C++ apps. And they are prepared to sponsor development. The Web Services API lets them do it. That's it.

As to the larger question of how interesting this is to the world at large, my view is not very. However having to jump through all the hoops to get a server infrastructure done, I thought that the world at large may be interested in a RESTful, resource oriented ehcache server.

The next day, Greg announces EhCache for JRuby on Rails. A few days later, RESTful, resource-oriented caching becomes available in ehcache-server.

I guess this helps answer the question about OSCache vs. EhCache. OSCache hasn't had a release in over a year and EhCache is pumping out new releases and new products. Well done, Greg!

At LinkedIn, we use EhCache for many of our caching needs. However, it's likely we'll be moving to Memcached in the future. Since I'll be part of the team that implements Memcached, it'll be interesting to see which one performs better.

Portlet Filters

2008-08-09T03:03:42Z

The Java Portlet Specification has introduced concept of Portlet Filters based on Servlet Filters. The basic concept remains the same that Portlet Filter allows you to do some pre and/or post processing for every request. Note one important point that unlike servlets portlet specification defines 4 different phases for handling user request and as result it defines 4 Filter interfaces that you can use.

ACTION_PHASE : If you want to perform filtering during action phase then you should implement class implementing javax.portlet.filter.ActionFilter interface
RENDER_PHASE : If you want to perform filtering during render phase then you should implement class implementing javax.portlet.filter.RenderFilter interface
EVENT_PHASE : If you want to perform filtering during event handling phase then you should implement class implementing javax.portlet.filter.EventFilter interface
RESOURCE_PHASE : If you want to perform filtering during resource serving phase then you should implement class implementing javax.portlet.filter.ResourceFilter interface

Optimizing Tapestry 4 for development

2008-05-02T16:07:40Z

New blog post on Optimizing Tapestry 4 for development.

Continue Reading on BlackBox.

MD5 Comparisons with Jakarta Commons Codec

2007-06-06T21:20:00Z

So I recently found myself needing to take a set of files with a matching MD5 digest and determine if the files and the digest match. If you have not used MD5 digests before, here is the Wikipedia definition describing what they are and how they are used.

Anyway, I had to write an automated process that would look for a set of files and compare those file to the included MD5 digest. I started with the Java MessageDigest, but it just seemed to be more of a pain in the ass than anything. So, I browsed around for an alternative and found the Commons Codec DigestUtils. It was too easy. The DigestUtils includes the method DigestUtils.md5Hex(byte[] data). It was exactly what I needed. To use it all I needed to do was:

Read the file that was suppose to match the MD5 digest.
Run it through the String DigestUtils.md5Hex(byte[] data) method.
Compare the generated MD5 String to the MD5 String included in the mathcing MD5 digest file.

Here is a simple example of how this works.

First, to make this example work we need a simple file that will be used to generate a digest and a tool to generate the digest itself. I am on a Mac, which includes the md5 application. On Linux there is an equivelent application, md5sum. I don’t have access to a PC, but there is a utility md5sums that looks easy enough to use.

So, if have the following file:


    A simple file to be run through the digester.

and we call this file, test.txt. To generate an MD5 digest from this file, we would do the following:


    md5 test.txt > test.md5

This would generate an MD5 digest file that (depending upon you digest tool) would look something like the following:


    MD5 (test.txt) = 5c87da642b2286cfb6ac8e0ad0d8e036

Note: This file is what would be included with the test.txt file in something like a zip or a tar.gz. When you received the file containing both of these files, you would uncompress them and perform the next comparison.

The String, 5c87da642b2286cfb6ac8e0ad0d8e036, is the actual digest. The next thing we need to do write a class that will read in the same file and generate an MD5 digest to compare. I have a simple FileUtils class that will do this for you.


    package org.gs.util;

import org.apache.commons.codec.digest.DigestUtils;

import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.io.FileInputStream;

public class FileUtil {

    public static byte[] readFile(File file) throws IOException {

        InputStream is = new FileInputStream(file);

        byte[] bytes = new byte[(int)file.length()];

        int offset = 0;
        int numRead = 0;

        while (offset < bytes.length &&
            (numRead = is.read(bytes, offset, bytes.length - offset)) >= 0) {

            offset += numRead;
        }

        is.close();

        return bytes;
    }

    public static boolean isFileValid(String file, String digest) {

        try {

            byte[] buffer = readFile(new File(file));

            String md5sum = DigestUtils.md5Hex(buffer);

            return md5sum.equalsIgnoreCase(digest);
        }
        catch (IOException e) {

            throw new RuntimeException("Unable to process file for MD5 comparison.", e);
        }
    }
}

As you can see, there are only two methods in this class. The first takes a File and returns its contents as a byte array-pretty simple. The second method, isFileValid(), is where the DigestUtils are actually used. It takes the name of the file to be digested and the digest it is being compared to. In this case the values are testData/test.txt and 5c87da642b2286cfb6ac8e0ad0d8e036.

It begins with a call to the previously mentioned readFile() method.


    byte[] buffer = readFile(new File(file));

The version of the DigestUtils.md5Hex() method we are using requires the value to be a byte array. After we have the byte array, we invoke the static md5Hex() method. This method returns a hex String representation of the generated MD5 digest. If you step through this code with a debugger, you would see the value:


    5c87da642b2286cfb6ac8e0ad0d8e036

returned from the md5Hex() method. The final line, exlcuding the catch block, returns a boolean value indicating whetther the passed in digest is equal to the digest generated when md5Hex() creates a digest from the file.

To test this code, I put a simple unit test together.


    package org.gs.util;

import junit.framework.TestCase;

public class FileUtilTests extends TestCase {

    public void testIsFileComplete() throws Exception {

        String digest = "5c87da642b2286cfb6ac8e0ad0d8e036";
        String file = "testData/test.txt";

        assertTrue(FileUtil.isFileValid(file, digest));
    }
}

This test takes the digest value generated by the utility, md5 or md5sum, and the path to the file used to generate the digest and passes them to the FileUtils.isFileValid() method. In this instance our test will obviously pass with no troubles.

I hope this helps.

TechStars: Technology Freeform Discussion

2007-05-30T14:59:04Z

I had the pleasure of being invited to participate in last night's "Geek-out" founders-only session last night in Boulder. David Cohen and I had never met prior to last night, but I had read about TechStars months ago through Brad Feld's blog and pinged him to see if I could help out at all. With my background running various software companies, he thought I might add some value in this session. I hope I did not disappoint.

Ten companies were chosen, and twenty-six founders are involved in this summer-long syncubation (yes I just made that word up but could not think of the exact way to put it into one word what TechStars does) effort. Companies from California, Seattle, Colorado and even Sweden are represented, and based on my two-plus hours with these people I am quite impressed with the choices.

We began with basic ideologies around platforms and technologies, from PHP to .NET to Java to Ruby. Most of the development right now is being done in Ruby, with some Java and PHP. One company is doing their work in .NET. We went through the ins and outs of each of the technologies. The reason Ruby seems to be the platform of choice seems to be the ease of learning curve as well as the ability to quickly prototype. We of course then got into the discussion of scalability and performance, which is where Ruby has gotten dinged the most in the past. There seems to have been some improvements in that vein recently, but it is still an issue. I did not get a chance to understand what each company is all about, but my guess is that most are in the consumer, social-networking space. This area is white-hot and some really cool ideas are flying around right now. Unfortunately this is not really my forte, with most of my background being in the B2B space.

Overall, it was a really cool experience. Being around such passion and energy on top of outstanding technical knowledge is a kick in the pants. A jam session for geeks, if you will. Thanks for having me, David.

JPA 101 on The ServerSide

2007-03-06T16:33:44Z

Welcome to my blog, well my old blog anyway. If you just landed here from TheServerSide link you can reach me on my new blog page here. As you can see in my last post I got fed up with JRoller not working and moved over to Blogger.

If you are interested in any of my posts about JPA, you can search this blog otherwise I'll see you over at my new blog.

If you are interested in purchasing this book, you can find it here at SourceBeat.com.

Thanks for stopping by.

Dropping JOSSO

2006-05-29T13:39:02Z

Few weeks ago, I announced that we were choosing JOSSO for SSO. We changed our mind, the lack of documentation of JOSSO made us evalute another product : CAS. After some weeks of test, we found CAS more clean, easiest to install and with a much better documentation !

Stéphane TRAUMAT

Second post

2006-05-01T07:00:00Z

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Fusce interdum. Vivamus vel nibh vel magna convallis tincidunt. Suspendisse accumsan, tellus a egestas laoreet, arcu ligula blandit neque, ut consectetuer neque risus sed urna. Quisque euismod. Fusce feugiat mollis mauris. Vivamus ligula dui, auctor vel, dictum nec, viverra aliquam, elit. Nulla facilisi. Suspendisse molestie hendrerit felis. Vestibulum sodales gravida ipsum. Sed sit amet nibh. Integer at elit ut augue faucibus vehicula. Sed velit orci, lobortis in, tempus vel, vulputate congue, nisl. Donec mauris.

Nunc facilisis, ligula ullamcorper ullamcorper varius, ligula felis faucibus quam, ut faucibus felis quam dignissim turpis. Vestibulum eget purus nec orci elementum ullamcorper. Nam rhoncus accumsan mi. Cras eleifend. In non odio et sapien imperdiet rutrum. Pellentesque pulvinar, pede id molestie dictum, orci nisl facilisis neque, vitae vestibulum elit magna eget dui. Morbi id justo. In id magna. Nam est. Curabitur at urna. Fusce pulvinar. Quisque ornare magna vitae erat. Fusce vitae quam. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Curabitur enim libero, aliquet ac, interdum id, tincidunt luctus, risus. Vestibulum eu urna. Aliquam erat volutpat.

Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Suspendisse potenti. Nulla facilisi. Donec nunc tortor, elementum in, aliquet et, lobortis quis, nulla. Sed sollicitudin mauris sit amet mi. Proin dapibus vehicula tellus. Vestibulum eu ipsum ut nunc blandit rutrum. Nulla lacinia enim quis nunc. Praesent ut ipsum sed ligula porta suscipit. Maecenas eget diam lobortis odio eleifend lacinia. In nulla dolor, molestie nec, rhoncus vitae, cursus id, nulla. Nam ut purus vitae ipsum luctus pellentesque. Proin commodo ante ac erat. Fusce sed nibh. Etiam at orci vel nisi rhoncus accumsan. Praesent id sapien vitae libero ultrices pretium. Sed odio. Phasellus est. Sed ac leo.

And that is just some dummy text for checking out the look and feel of the blog. Real entries to follow later.

Another Positive Desktop Java Live Review

2006-04-19T05:00:00Z

Joshua M. Marinacci (the author of Swing Hacks) had some nice things to say about Desktop Java Live yesterday:

"I've been coding Swing for close to ten years and I've never seen a book on Swing that tackles the topic in such a sensible and easy to understand fashion. Instead of going through the technologies or being an annotated reference guide, Desktop Java Live takes you through how to build a real application. In each chapter he discusses the development issues an application programmer will face in real life. The chapters on validation, binding, and threading were very useful, especially since so few books ever address the topic. For anyone who plans to build a real Swing application, this book is a must have."

VisualStudio committers vs. Eclipse committers

2005-10-07T19:22:12Z

While at OJ.X on Thursday I had the great privilege of getting to spend some time with Mike Milinkovich. Since MS was there too he wondered out loud how many people MS had working on Visual Studio. Well Rick LaPlante (a General Manger for MS) was also at the show. While I was doing some research on him I found his blog and a very interesting post here. From these numbers it looks like MS has about 432 people involved in the Team Foundation Server which I guess is a big part of but not all of the next version of Visual Studio. Anyway that is a huge team compared to the 60+ committers on Eclipse.

Interesting indeed...

Yes its been a long time, life, new job have been getting in the way of my time to spend on Eclipse.

Maven Out, Ant+Ivy In

2005-05-20T01:17:56Z

For the past year or so, we have been using Maven for our projects. In fact, the builds for the book were based upon Maven, and I even included a small tutorial in Chapter 2 since the documentation for Maven isn't very good. While this worked very well and Maven also built our IntelliJ project files, I couldn't handle another three to four hours upgrading the library files and their associated conflicts each time a new release of one of our core libraries (WebWork, Spring, Hibernate, Sitemesh, JRobin) happened. Plus, I always felt like we could never accomplish anything complex without delving into Jelly.... something I never want to do again.

Luckily, about the time I was planning to do another update, Jason Carreira mentioned on the OpenSymphony admin mailing list that he would really like to start using Ivy for the builds. After spending 10 minutes seeing the demonstrations, Ivy passed the test. Despite needing to do a hundred other things, I spent a few hours over the past week getting rid of Maven from our internal software builds and implementing Ant+Ivy.

Today, I spent about 15 minutes converting the book builds to Ant+Ivy. Now, I just need to go back and fix Chapter 2 (sorry, Craig, Craig, and Amy)!

Many thanks to Jason for his help and constant pestering of questions. In addition, the folks on the Ivy forums were absolutely amazing with support, even when I had problems with my basic configuration file that was completely my fault.