Author Blogs

SourceBeat authors provide additional support and information through their respective weblogs. Click on an entry's title to view the full content of a posting.

Recent Blog Entries

JBoss and Specification Compliancy
View Original Entry · David Whitehurst

I recently had a request to turn on JBoss remoting for a remote test team to do performance monitoring. I'm still asking what they plan to monitor.

Anyhow, the exact need was for a URL just like the one that WebLogic 9 provides for Hewlett-Packard's Sightscope JMX Monitor. Well, that URL doesn't seem to exist for JBoss. Immediately I start with the questions. I need answers.

Are you planning on writing client software to use RMI through port 1099? I think we turned that port off. Do you need the namespace for the JNDI string to access the context for RMI access? As the questions are being asked, I'm realizing that this has more and more to do with fact that HP Sightscope, a monitoring tool (very expensive) is available to my client and the goal is to use the software that we have if possible. And, for that matter, just because it monitors another J2EE server, BEA's WebLogic 9 doesn't mean we just hook up the leads and let the measurements begin.

After some initial irritation, I took the challenge to learn a little more about the fact that I knew (many versions ago) that JBoss never implemented JMX in a manner that made it easy for other vendors to inspect their MBean server. Java Specification Request (JSR)-160 Java Management Extensions (JMX) Remote API was written to satisfy this very need. An API was needed to provide hooks into Java processes, classes, threads, et al. This way server vendors can implement this API thereby providing hooks for remote control and monitoring of application servers. The initial specification and several versions thereafter have provided room for interpretation of this specification. JBoss does comply with this specification, however, their implementation does not provide connectors for JMX-compliant management applications to use. JBoss does, however, provide it's own JMX console application with every server download.

While the public may discuss concerns that JBoss does not provide connectors for JMX specification-compliant management of its server, I want my next statement to be very clear and well understood. JBoss does comply with JSR-160. Their adherence to the spec is defined by the following statement taken from the spec itself, "The RMI connector is the only connector that must be present in all implementations of this specification.". That is exactly what JBoss provides.

JBoss provides access to the server context via the Java Naming and Directory Interface (JNDI) (context-by-namespace) and by using the server context, Remote Method Invocation (RMI) is available to Java clients. The MBean server implemented at BEA for WebLogic is probably very different. And, I assume that their implementation allows for remote access and monitoring using JMX-compliant management applications. The public should understand that the JBoss MBean server design may or may not have been a strategic decision.

JBoss did release a product years ago called JBoss Remoting to simplify the issue of control and management of the server. Why would JBoss add another protocol to the Java EE plethora such as existed RMI, EJB, and Web Services? Maybe they want to keep server monitoring within their ownership. They do not owe us anything. Their source is open and as long as it remains open, my guess would be that they won't play well with others. Thank you JBoss. It's good for business.

The answer to my initial question, "can JBoss be setup to support monitoring using HP Sightscope? No.

LinkedIn has the Biggest Rails app in the World
View Original Entry · Matt Raible

Optimizing Tapestry 4 for development
View Original Entry · Warner Onstine

Synchronizing nodes using wasadmin script
View Original Entry · Sunil Patil

Yesterday we were facing problem that if you try to call wpsconfig.sh with non admin user then it throws permission denied error. So i had to write this jacl script


set dm [$AdminControl queryNames WebSphere:type=DeploymentManager,*]

$AdminControl invoke $dm multiSync "true"

MD5 Comparisons with Jakarta Commons Codec
View Original Entry · James Goodwill

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
View Original Entry · Matt Filios

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
View Original Entry · Chris Maki

Dropping JOSSO
View Original Entry · Jonas Live

Second post
View Original Entry · Krishnan Anantheswaran

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
View Original Entry · Scott Delap

Author Blogs

Recent Blog Entries

Author Blogs

Giving Back