SourceBeat Author Blogs

JBoss and Specification Compliancy

David Whitehurst — Wed, 02 Jul 2008 16:25:38 GMT

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

Matt Raible — Tue, 24 Jun 2008 19:25:16 GMT

From the LinkedIn Engineering Blog:

Bumper Sticker started as a small experiment in August, 2007. Facebook had released their development platform while we were hard at work on our own. We were curious to experiment and discover some of the characteristics of an application platform built on a social network and to see what, if any, learning we could apply to our own efforts. After noticing that professional and business-related applications weren't flourishing in the Facebook ecosystem, a few of our Product folks put their heads together while out for a run; one engineer, one week, and a few Joyent accelerators later, Bumper Sticker was born.

We'd be lying if we said that anyone was prepared for the kind of success Bumper Sticker has had since then - though we should have expected it, given the excellent Product team here at LinkedIn. Here's a quick snapshot of Bumper Sticker statistics at this moment: Read More »

The "biggest Rails app in the world" claim comes from this video.

In addition to having a kick-ass RoR team at LinkedIn, we also do a lot with Java and love our Macs. Why wouldn't you want to work here?

If you find a gig you like, or simply have mad programming skills, contact me and I'll see if I can hook you up. And yes, we are hiring at LinkedIn Denver.

Optimizing Tapestry 4 for development

Warner Onstine — Fri, 02 May 2008 16:07:40 GMT

New blog post on Optimizing Tapestry 4 for development.

Continue Reading on BlackBox.

Synchronizing nodes using wasadmin script

Sunil Patil — Fri, 16 Nov 2007 19:07:07 GMT

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

James Goodwill — Wed, 06 Jun 2007 21:20:00 GMT

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

Matt Filios — Wed, 30 May 2007 14:59:04 GMT

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

Chris Maki — Tue, 06 Mar 2007 16:33:44 GMT

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

Jonas Live — Mon, 29 May 2006 13:39:02 GMT

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

Krishnan Anantheswaran — Mon, 01 May 2006 07:00:00 GMT

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

Scott Delap — Wed, 19 Apr 2006 05:00:00 GMT

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

Bill Dudney — Fri, 07 Oct 2005 19:22:12 GMT

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

Matthew Porter — Fri, 20 May 2005 01:17:56 GMT

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.