Below are some typical benchmarks that provide insight into the performance of OS X based systems as run by the xMac.

Geekbench

This is the result with the 32-bit trial version of Geekbench. This benchmark is focused around CPU/RAM measurement. This result is faster than every 4-core Mac ever made. Only super-expensive 6/8/12 core Mac Pros are faster.

Cinebench

The next benchmark is an indicator of graphics crunching potential. 51.30 FPS is a pretty good result. For comparison, the score for a 6-core 2010 Mac Pro with an ATi Radeon 5770 is 34.37 FPS. Strong performance on this benchmark means that many Mac games (such as World of WarCraft) will run well.

Performance on this benchmark is about 3 times what I get with an nVidia GTX 285.

Xbench

The last result is for Xbench, which is the spiritual descendent of NXBench. Unlike Geekbench and Cinebench, the emphasis of this benchmark is overall system throughput as a whole, including disk speed, Quartz rendering, etc. For comparison, the benchmark for a 6-core 2010 Mac Pro with ATi 5780 is 288. The xMac’s SSD drive helps enormously on this test.

This benchmark is the grandaddy of OS X benchmarks. The thread part of the test hangs on Lion, so the thread test was disabled for this benchmark.

Completed build showing all components in place (video card is hiding behind cables and PSU). Click for a much larger image.

Note: This isn’t meant to be a tutorial on how to assemble a PC from scratch. There are plenty of articles on the web and “how to” books at your local Barnes & Noble that cover that. Rather, this is just my list of notes regarding my xMac build.

The main thing to remember is that building an EFiX compatible computer to run Mac OS X is the same as building any other PC. When building an xMac of your own, simply make sure you use a motherboard and video card from the EFiX hardware compatibility list (HCL).

It’s a great idea to post your proposed build over in the EFiX forums and ask the experts if your build will be 100 percent compatible. Just list all your components and then check the forum later to see if anyone raises a red flag.

While assembling my system I made a few modifications of the case to keep the system quiet. Some people regard the typical tower system as “quiet” (e.g., you’ll see typical stock cases described as “quiet” in user reviews). But to my ears many tower cases with stock fans sound like hair dryers. With that in mind, let’s discuss how to keep things cool and quiet.

Cool And Quiet

If you’re not annoyed by fan noise then you can skip this section.

The Dao of Cool PCs

Heat is a major enemy of computer components. Your CPU will automatically throttle itself down in high heat situations, but a video card may simply fry itself. Also, the various chips on your motherboard may fry themselves if the ambient temperature in your case gets too high. I’ve personally slowly cooked a video card through insufficient airflow in my case. Let me tell you, shelling out another $250 to replace a baked video card really sucks…especially when one more fan in the case might have saved it.

Therefore a case should have plenty of airflow. Most cases solve this by having a few fans (usually 2 or 3) that run at pretty high speed (usually 1500~2000 RPM). That’s enough to cool most basic builds, but it’s also enough to provide a pretty steady fan noise from your case.

We can do better than that. Specifically, we can get better airflow into the case while reducing the background hum. Let’s look at the fundamental ways to tame a loud system:

1. Replace the cheap fans that normally come with a case — use high quality aftermarket fans instead (good brands to consider are NoiseBlocker, ThermalRight, and Nexus)
2. Slow down the fans so they rotate at 1000 RPM or less (ideally, 800 RPM or less) using cheap and effective inline resistors or a Fan Mate
3. Select a case that uses large fans because large fans have a more pleasant lower-pitched noise
   • 92 mm, 80 mm fans, and smaller have an annoying high pitched whine
   • A case that uses only 120 mm fans or larger is ideal (or even better…only 140 mm or 180 mm fans)

Here’s a shot of the side of the case. You can see the top “blowhole” fan that blows air up and out of the case above the center of the motherboard.

The Apple logo is centered on the side. It's just a sticker that came with an OS X upgrade disk.

BTW, the aftermarket fans and in-line resistors I used are linked in the previous article in this series.
Remember that it’s important not to sacrifice cooling for the sake of quietness. Achieving a quiet system that burns out its video card or RAM in one month is a waste of money. Slowing down all the fans to 800 RPM to quiet them also reduces the effective cooling inside, so you may need to compensate by adding more fans by “modding” your case.

Cool (Literally!) Case Mods

To gain more cooling ability, I modified (or “modded”) my case by drilling a hole for a fan in the side of the case. The side fan blows air directly onto the CPU/RAM area of the motherboard, helping ensure the RAM doesn’t cook itself. As a fringe benefit, the air also flows over the motherboard chipsets to cool them, too. You can see the result in the photo below.

This shows the xMac from the side. Note the modded side fan.

In addition, I drilled extra fan hole in the bottom that accommodates an extra 140 mm fan. This helps ensure that the xMac runs really cool. This meant sacrificing the hard drive mountings on the bottom of the case, but I wasn’t planning to use them anyway.

Note: Cutting or drilling metal is dangerous and you should be wearing protective gear (eye cover at least). It’s not my fault if you accidentally cut off one of your appendages or lose an eye while modding your case. Hopefully you learned how to be safe in high school shop class.

I used a 5.5-inch hole saw to drill through the aluminum to fit the 140 mm fan. Here’s a PDF fan template at MNPC Tech that helps mark the drill location for the fan hole and screw holes.

Here’s a helpful YouTube video from David Blum / Custom Computers that teaches you how to drill your case for a new fan:

After the bottom vent was drilled, I fitted a Thermalright TY-140 fan blowing upward in the bottom of the case.

The fan on the bottom doesn’t help if it’s starved for air. Therefore I removed the stock feet from the case and replaced them with taller aftermarket feet from MNPC Tech. This raises the case a little higher off the floor to allow more air to be sucked into the big fan on the bottom. The feet mounting positions were relocated closer to the corners of the case by simply drilling new mounting holes in the bottom of the case.

By the time I was done, my tiny tower case had a total of 8 fans in it (6×120 mm and 2×140 mm), including the fan in the power supply. You’d think with that many fans the xMac would be loud, but because all the fans are rotating at about 800~1000 RPM the case is actually almost silent from 4-5 feet away (i.e., beside my desk).

To sum up, we’ve achieved a nice looking little case with good cooling that’s not going to disturb you in a quiet room.

This post is currently a work in progress… Stay tuned, more to come!

CPU Installation

While you’re installing the CPU you’ll definitely want to use a thermal compound such as Arctic Silver 5. Keep the thermal compound really thin; you’re just trying to fill in the very tiny gaps between the heat sink and CPU. Using too much thermal compound can actually insulate your CPU rather than facilitating heat transfer.

Software

Will need Lion

BIOS settings

Turn off USB_3 in BIOS (both front and back panel).

• Mac OS X compatibility
• high performance
• good value
• compact Mac-like design
• reasonably noiseless

As mentioned before, we have to choose our components carefully so they’re compatible with EFiX. Luckily, EFiX supports a wide variety of hardware. BTW, I’ll be using an EFiX v3 — the latest version — which supports newer chipsets such as the Z68 chipset.

EFiX-Compatible Components

These are carefully chosen from the EFiX hardware compatibility list (HCL). If you’re curious, you can refer to the EFiX v3 hardware compatibility list here.

COMPONENT TYPE	PRODUCT NAME / PHOTO	NOTES
Motherboard	Gigabyte GA-Z68MX-UD2H-B3 LGA 1155 Micro ATX motherboard	This Micro-ATX motherboard fits in compact cases, yet is very powerful for its size.
CPU	Intel Core i7-2700K 3.5 GHz LGA 1155 Processor	Intel’s “K” variants of their Core i7 CPUs are highly overclockable. This CPU has a base clock speed of 3.5GHz (3.9GHz in Turbo mode), but with some easily tweaking it can be mildly overclocked to a stable 4.2GHz (Turbo mode disabled) inside this case. (Note: Different chips have different overclock potential, even from the same product line, YMMV.)
Video Card	Gigabyte Radeon HD 6870 1GB GV-R687OC-1GD	Currently this is the overall fastest and most compatible video card that’s commonly available for use with EFiX and Mac OS X. (The 5870 would probably work great and run a bit faster, but they are very expensive and hard to find.)
DVD	Sony Optiarc Blu-ray Burner drive BD-5300S-0B	Any Sony Optiarc brand DVD or Blu-ray SATA drive will work well with EFiX. Get this Blu-ray burner if you want to burn Blu-ray discs or watch Blu-ray movies under Windows, otherwise save your money and get a regular Sony DVD SATA drive.

Additional Required Components

The remaining components can be anything you like, as long they’re compatible with the components above. For example, this build uses an SSD drive for extreme performance, but a regular hard drive would work fine instead. These are the exact components I used, and each is highly recommended.

COMPONENT TYPE	PRODUCT NAME / PHOTO	NOTES
Memory	G.Skill 8GB (2 x 4GB) Ripjaws X Series DDR3 1600MHz RAM F3-12800CL9D-8GBXL	For a full 16GB of memory you need to buy two of these 8GB packages. For most folks 8GB will be plenty, but developers and other power users will want to max out their RAM.
Hard Drive	Intel 320 Series 300 GB SATA 2.5-Inch SSD	This SSD has plenty of space for most users. Note it’s SATA2; don’t pay for SATA3 because OS X doesn’t support / can’t boot from SATA3 yet. If you want to run Windows you’ll need a second drive since EFiX doesn’t support two different OSes on partitions within the same hard drive.
Drive Bay Adapter	Silverstone 3.5 to 2×2.5-Inch Bay Converter SDP08	SSDs do not fit in 3.5 inch drive bays common to most cases; this adapter lets you install two SSDs into a single 3.5 inch drive bay in your case.
Case	Lian-Li Aluminum Mini Tower Case (microATX) PC-V354A	This case looks a lot like an Apple Mac Pro that got shrunk in the wash. It comes complete with the silver aluminum look, cheese grater front panel, and rounded edges. The addition of an Apple logo on each side makes it right at home next to genuine Macs.
Power Supply	Corsair Professional Series 650-Watt 80 Plus Certified Power Supply CMPSU-650HX	This compact power supply is ideal for use in a mini tower due to its small dimensions and modular design. Modular cables mean you only install the cables you need, thus preventing a rat’s nest inside your small case. The high efficiency rating is a nice bonus.

Miscellaneous Components

These last items are optional but highly recommended if you want a fast, quiet, cool-running system.

COMPONENT TYPE	PRODUCT NAME / PHOTO	NOTES
CPU Cooler	Antec Kühler H2O 620 Liquid Cooling System	This self-contained cooling system takes up much less space than a typical monolithic heat-sink cooler, and the sealed nature makes them foolproof. This particular water cooler distinguishes itself from other similar coolers (e.g. Corsair H60) due to its extra thick tubes that resist kinking and high static pressure fans. For the best possible performance, get a second Noiseblocker M12-S2 120mm Fan (see below) and mount it on the back of the radiator in a push-pull configuration.
140mm Top Fan (fits Lian Li PC-V354 Case)	Thermalright TY-140 Fan	The TY-140 is a 140mm fan that mounts in the standard 120mm fan mount holes in the top of the Lian Li PC-V354. The amount of airflow is outstanding when compared to the low noise level (it’s almost silent from a few feet away). The pea soup coloration is a bit strange though.
120mm Rear Fan (fits Lian Li PC-V354 Case)	Noiseblocker Multiframe 120mm Fan M12-S2	This outstanding fan from Germany is virtually silent but doesn’t push as much air as the Thermalright TY-140 due to its smaller diameter (the TY-140 won’t fit on the back of the case). A unique feature of this fan is that much of the frame is actually made of rubber to provide exceptional vibration resistance. Both this and the TY-140 are better than the more common Noctua fans, and far better than stock fans.
Fan Speed Controller	Fan Speed Reducer	Add one or more of these in series with your fans to slow them down and make them noiseless. A fan is generally noiseless from 3 feet away when it runs at 800 RPM or less.
Keyboard	Apple Aluminum Wired Keyboard	Complete the Mac OS X experience with a genuine Apple keyboard. It works great with this xMac.
Mouse	Microsoft Wheel Mouse (White)	Unless you’re a fan of the quirky Apple Magic Mouse, this is an excellent option that looks good with the xMac and works marvelously.

But how to we get Mac OS X to run on a vanilla PC?

The solution is actually quite simple. A device called “EFiX” makes it easy to run Mac OS X on a PC. This little USB dongle gets added to one of the USB headers on your PC motherboard and turns your PC into something very similar to a Mac.

How does EFiX work?

The EFiX operates on the notion that Macs run on something called called EFI (Extensible Firmware Interface), which is the next-generation successor to last millennium’s BIOS. EFiX should be set as your primary boot device. Then, when your computer powers up and begins its boot sequence, it “boots” into the EFiX chip code. When the EFiX boots it does two things.

First, EFiX provides an EFI compatibility layer on top of your PC’s BIOS. In turn, any OS that gets loaded over EFiX’s software will think its running on an EFI-based machine (i.e., a Mac) instead of a BIOS-based machine (i.e., a PC). Your BIOS simply needs a couple of easy configuration tweaks in CMOS Setup to support the EFI compatibility layer. EFI is natively supported by Windows and Mac OS X, and it’s one of the reasons why an EFI based Macintosh can boot Windows via Boot Camp.

Second, EFiX provides a graphical boot console showing you the bootable drives in your computer, which can be Windows, Linux, or Mac OS X. You graphically choose the drive to boot from. EFiX does the rest, booting your chosen OS (such as Mac OS X) on top of EFI.

This means that Mac OS X will run without modification on a PC equipped with EFiX. This is key.

There are other solutions to get Mac OS X to run on PCs, but they always require some degree of hackery of Mac OS X itself to get it working. This usually means the hacked version of Mac OS X must be re-hacked every time Apple updates Mac OS X, or all of a sudden your pseudo-Mac won’t boot anymore. Apple updates Mac OS X a lot, so this is a huge pain, IMO. Of course, the big upside to the hackery approach is that hacking Mac OS X is free.

On the other hand, you actually have to pay for an EFiX dongle.

However, for me at least, it’s much nicer to plug in EFiX and watch it “just work”, rather than having to tinker for hours or days to hack (and re-hack and hack again) with the free “hackery” solutions.

EFiX is not free, and neither is it magic. You have to be dilligent to use EFiX-compatible hardware (motherboard, video card, etc). If your assemblage of parts is not compatible with EFiX then Mac OS X may run poorly or not at all on your system. Fortunately there’s a free support forum available if you encounter any hiccups with EFiX.

The next post in this series will look at the parts used in the xMac build with an eye toward EFiX compatibility.

But the Mac Pro is not perfect. Why?

For example, there’s no denying the Mac Pros are rather large machines that utterly dominate any desktop. Most of us don’t need a system that can hold 8 processor cores, lots and lots of hard drives, a whopping 32 GB of RAM, etc. Not to mention the cost of a fully loaded Mac Pro system is about the same as a used car. Ouch!

For me, a system with 4 cores, 16 GB of RAM, and a couple of SSD drives that fits in a small space (say, the size of two shoeboxes) is plenty for day-to-day development use. Add in a decent video card and the machine could even run World of Warcraft with a great frame rate. In other words, in terms of Mac performance, I’d like to buy more than a Mac Mini or iMac, but less than a Mac Pro.

This sounds like the fabled “xMac”, which is the compact $1,000 minitower Mac that Apple unfortunatley refuses to make. If Apple sold an xMac I’d buy it in a heartbeat. After all, I’ve owned a G3 tower, a G4 tower, a Cube, a G4 Mini, and various Intel-based Minis, MacBooks, MacBook Pros, etc. (even a NeXT Cube and a NeXTstation Color, but that’s another story). A theoretical mini-tower xMac from Apple sporting discrete upgradable graphics and an upgradable CPU daughter card would surely sell like hotcakes, although it would undoubtably cannibalize some sales from the Mac Mini, iMac, and Mac Pro.

But there are alternative solutions if you’re creative. So I made my own xMac! Why, you ask?

Well, for starters, it bugs me that except for the Mac Pro, all other Macs use mobile-class video cards or integrated video. No wonder the Mac is not big in gaming circles.  So iMac, Mac Mini, and the rest are out. That leaves the Mac Pro. But then there’s that huge price tag and other drawbacks that were already lamented above.

However, there are ways to build a “Mac-like” PC computer and make it compatible with Mac OS X at a fraction of the price of a real Mac. Building my own xMac would allow me to buy exactly the level of performance I need with precisely the discrete video card I want, all in a case that doesn’t crush the desk, and at a price that’s relatively affordable.

With that in mind I set off to build my own xMac. Luckily I already had a bunch of the parts needed–such as the case–so with a few judicious upgrades I was able to achieve my goal of a custom xMac.

Stay tuned; in future posts I’ll detail the parts, the build, and the performance results.

First… What is Streambaby? Basically, Streambaby is a free application that works with your current model TiVo to stream video from your computer to your TiVo DVR. It automatically shows up in your TiVo’s menus when Streambaby is running on your Mac.

In other words, having Streambaby is like hosting your own Netflix service, but with all of your own personal videos.

Note the purpose of Streambaby is to stream rather than transfer your videos. Streambaby does not transfer video from your computer to your TiVo. (If you want to transfer videos from your computer to your TiVo then you’re looking for a different program called pyTivo.)

One of the things that makes Streambaby great is that you can store many terabytes of video on your Mac. With Streambaby your terabytes of video don’t consume valuable disk space on your TiVo itself, yet you can easily view the video anytime on any TiVo in your home. The video can be in any format supported by Streambaby and its dependent library, FFmpeg.

This post assumes you have basic familiarity with the command line, etc. This is a pretty safe procedure, but the standard disclaimers apply about messing up your computer etc.

Java Installation

Unlike previous versions of Mac OS X, Lion does not come with Java installed by default. If you have not installed Java on your Mac, then follow the steps below to install Java.

1. In Finder, go to Applications > Utilities > Java Preferences to launch the Java Preferences application.

2. If Java is not installed you’ll see an alert panel with the following text:
"To open 'Java Preferences', you need to install a Java runtime. Would you like to install one now?"
If you don’t see the alert panel then Java is already installed and you can skip step 3.

3. Click the Install button on the alert panel and accept the license agreement. The Java runtime will be downloaded and installed.

Streambaby Installation

Now that Java is installed let’s install Streambaby itself.

1. Download the latest zipped copy of Streambaby from the Streambaby download page:
http://code.google.com/p/streambaby/downloads/list

2. Extract the zipped file you just downloaded and rename the folder to “streambaby” (lower case). Move the streambaby folder into your /Applications folder.

FFmpeg Installation

The ffmpeg library is used by Streambaby to transform your various video files into something that your TiVo can understand.

1. Download the latest 0.8.X release of ffmpeg from here.
http://pytivo.sourceforge.net/forum/ffmpeg-builds-for-mac-os-x-t1803.html
The one I downloaded was called “ffmpeg_mac-0.8.10-x64.zip“.

2. Extract the zipped file and copy it into the /Applications/streambaby folder.

Streambaby Configuration

The next step is creating a configuration file that Streambaby will use each time it runs.

1. There is already a file called “streambaby.ini” in the /Applications/streambaby folder. This contains the default Streambaby configuration. Open it in a text editor, such as TextEdit.app.

2. Replace the entire contents of the file with the text below. Edit it to contain the path to your Movies folder and the shared folder name. In this example the movies are stored in /Users/justin/Movies and the corresponding name that will appear in the TiVo menus is Justin's Movies.

dir.1=/Users/justin/Movies
dir.1.name=Justin's Movies
com.unwiredappeal.tivo.vm.ffjava.FFmpegJavaVideoModule=false
ffmpeg.path=/Applications/streambaby/ffmpeg

Don’t change the last two lines above. Save the configuration file and close it.

Launching Streambaby

There are two ways to launch Streambaby, manually via the command line or automatically at login. For your first test I recommend running Streambaby from the command line. Once you’ve verified it’s working then switch to the automatic startup method.

Manually Launching Streambaby

The advantage of manually launching is that you’ll see the Streambaby app log in the terminal window.

1. You can manually start Streambaby by typing the following command in a Terminal window:

/Applications/streambaby/streambaby

You should see several lines of text as Streambaby starts up, similar to this example:

[justin@arwen:~]$ /Applications/streambaby/streambaby
Initializing StreamBaby v20111203-2132...
01/28/12 20:57:34 Listener: added factory
01/28/12 20:57:34 Main: streambaby ready & listening.

2. You can now test access to your streaming folder from your TiVo (see “Using Streambaby” below). After you’ve verified it works, you can stop Streambaby with Control-C.

Automatically Launching Streambaby At Login

You can have Mac OS X automatically launch Streambaby when you log into your Mac. Naturally, if you have auto-login turned on then Streambaby will start whenever you start your Mac. Streambaby will be automatically shut down when you log out.

1. Create a plain-text file in TextEdit with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
    "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
	<string>streambaby</string>
    <key>WorkingDirectory</key>
	<string>/Applications/streambaby/</string>
    <key>ProgramArguments</key>
	<array>
	    <string>/Applications/streambaby/streambaby</string>
	</array>
    <key>RunAtLoad</key>
	<true/>
    <key>KeepAlive</key>
	<true/>
</dict>
</plist>

2. Save your file as “streambaby.plist” in your personal LaunchAgents folder, for example within /Users/justin/Library/LaunchAgents.

3. Log out and log in again. You can now test access to your streaming folder from your TiVo (see “Using Streambaby” below).

Optional: Hiding The Streambaby Icon In The Dock

Streambaby is a Java application, and like most applications it will show an icon in the Dock when it runs. If you perform this optional step, then it will hide the Streambaby app icon when Streambaby runs. Other than hiding the app icon, there is no functional difference if you skip this step.

1. There is a file called “streambaby” in the /Applications/streambaby folder. This file is what is invoked when you run Streambaby. Open it in a text editor, such as TextEdit.app.

2. Add the following text (in brown text) to the “streambaby” file:

Save the file and close it.

Using Streambaby

On a Tivo Premiere running with HD menus enabled, the Streambaby menu shows up under Showcases & Apps > Stream, Baby, Stream. Navigate to that menu item to see the videos that Streambaby is sharing with your TiVo. Note that the folder structure is hierarchical, so you can place subfolders within subfolders in your Mac’s video folder, and Streambaby will let you drill down into them on your TiVo. When you’re ready, simply select a video and click Play to start the stream. Voila!

BTW, when Streambaby is running it’s normal to see a generic Java app icon appear in your Mac’s Dock. Don’t shut down or otherwise mess with this Java app or else Streambaby will stop and you’ll have to restart it.

Advanced users may want to set up more than one shared video folder. For example, in addition to my Movies folder I share my iTunes U videos from within my iTunes folder on my Mac. See the Streambaby site for more details about how configure Streambaby.

Background

About a week ago I needed to write a SOAP-based client for work. The SOAP framework I’m using is Apache CXF. I’m a total noob when it comes to SOAP services, and so I was a little apprehensive about this at first. My apprehension sprung from hearing horror stories a few years ago from coworkers who were writing Axis SOAP applications, and they were basically tearing their hair out over Axis.

However, word has it that CXF is much easier to use. Well, it took me a while to get it working correctly. In an effort to save other folks the same grief, I’ve posted my code here. If you’re reading this, I’m assuming you’re acquainted with Java and Maven, but fairly new to SOAP, WSDL, etc.

To keep things simple, I decided to write a “Hello World” type of application first to make sure I could get the technology stack working correctly. To keep things really simple, I decided to create a trivial Java “main” function that calls a SOAP service, logs the result to the console, and exits (no fancy web interface or anything like that).

The SOAP Service Provider

First I had to select an appropriate web service to test against. There are a bunch of free SOAP-based web services out there, and I chose the CDyne weather service. You can go read all about it if you want.

Obtain the Service’s WSDL

When you’re writing a new client in CXF for an existing web service, you start with the WSDL and work from there. This means you need to get a copy of the WSDL from the service provider. The WSDL for the CDyne weather service can be downloaded from their site. You can simply right-click that link and save the WSDL on your hard drive.

Once you have the WSDL in hand, you can build your client around it. Basically, you’ll use a CXF tool called wsdl2java to turn the WSDL into Java stub code that you then compile along with your application.

Create the Maven Project

As a recent convert to Maven, I set up a new Maven project. I created a new project directory called weather-client, which is the ${basedir}. Also, I put the WSDL file in ${basedir}/src/main/wsdl/weather.wsdl.

Yeah, I know Maven has its fancy archetype creator thingie to emit the initial POM file, but like most pragmatic programmers I simply copy and paste a similar POM from somewhere else and modify it to suit my needs. Here’s the project file I came up with.

weather-client/pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

http://maven.apache.org/maven-v4_0_0.xsd">

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.logicsector</groupId>
    <artifactId>weather-client</artifactId>
    <version>1.0</version>
    <name>SOAP weather client</name>
    <packaging>jar</packaging>

    <dependencies>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-frontend-jaxws</artifactId>
            <version>2.1.2</version>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-transports-http</artifactId>
            <version>2.1.2</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
            <version>1.5.2</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
            <version>1.5.2</version>
        </dependency>
    </dependencies>

    <build>
        <finalName>weather-client</finalName>
        <plugins>
            <!-- Generate Java classes from WSDL during build -->
            <plugin>
                <groupId>org.apache.cxf</groupId>
                <artifactId>cxf-codegen-plugin</artifactId>
                <version>2.1.2</version>
                <executions>
                    <execution>
                        <id>generate-sources</id>
                        <phase>generate-sources</phase>
                        <configuration>
                            <sourceRoot>${basedir}/target/generated/src/main/java</sourceRoot>
                            <wsdlOptions>
                                <wsdlOption>
                                    <wsdl>${basedir}/src/main/wsdl/weather.wsdl</wsdl>
                                    <extraargs>
                                        <extraarg>-client</extraarg>
                                    </extraargs>
                                </wsdlOption>
                            </wsdlOptions>
                        </configuration>
                        <goals>
                            <goal>wsdl2java</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <!-- Add generated sources - avoids having to copy generated sources to build location -->
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <id>add-source</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>add-source</goal>
                        </goals>
                        <configuration>
                            <sources>
                                <source>${basedir}/target/generated/src/main/java</source>
                            </sources>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <!-- Build the JAR with dependencies -->
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <configuration>
                    <descriptorRefs>
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                </configuration>
            </plugin>
        </plugins>
        <!-- Build with Java 1.5 -->
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <configuration>
                        <source>1.5</source>
                        <target>1.5</target>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>

</project>

The only items of interest in the POM are:

• We depend on the CXF v2.1.2 client libraries and the (most excellent) SLF4J logging system
• We invoke the cxf-codegen-plugin to run wsdl2java to generate our Java stub code into ${basedir}/target/generated/src/main/java
• We use the build-helper-maven-plugin so that Maven can compile from two source directories (normally Maven just compiles what’s in ${basedir}/src/main and not ${basedir}/target/generated/src, so we tell Maven to go compile the generated stub code too)
• We use the maven-assembly-plugin to create a final JAR containing all necessary dependencies, which Maven will create as weather-client-jar-with-dependencies.jar when we perform a mvn assembly:assembly

At this point, even though I had no code in the project, I ran mvn assembly:assembly to build the Java stubs from the WSDL file. The output is in the generated source directory mentioned earlier, in case you want to go poke at it.

The Client Code

Once we have the autogenerated stubs we can use them in a real Java program. Before you can use the stubs, you have to identify what the actual service object is. You can find out by looking at the generated stub code and see which Java class extends Service. That will be the service interface that you call in your client. In this case, the service is called simply “Weather”.

Without further ado, here’s the code I wrote to invoke the SOAP service:

weather-client/src/main/java/com/logicsector/soapclient/SoapClient.java

package com.logicsector.soapclient;

import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.List;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import com.cdyne.ws.weatherws.Forecast;
import com.cdyne.ws.weatherws.ForecastReturn;
import com.cdyne.ws.weatherws.POP;
import com.cdyne.ws.weatherws.Temp;
import com.cdyne.ws.weatherws.Weather;
import com.cdyne.ws.weatherws.WeatherSoap;

public class SoapClient {
    private static final Logger           LOGGER      = LoggerFactory.getLogger(SoapClient.class);
    private static final SimpleDateFormat DATE_FORMAT = new SimpleDateFormat("EEEE, MMMM d yyyy");

    public static void main(String[] args) {
        try {
            LOGGER.debug("Creating weather service instance (Note: Weather = Service subclass)...");
            long start = new Date().getTime();
            // Get a reference to the SOAP service interface.
            Weather weatherService = new Weather();
            WeatherSoap weatherSoap = weatherService.getWeatherSoap();
            // An alternate way to get the SOAP service interface; includes logging interceptors.
            // JaxWsProxyFactoryBean factory = new org.apache.cxf.jaxws.JaxWsProxyFactoryBean();
            // factory.setServiceClass(WeatherSoap.class);
            // factory.setAddress("http://ws.cdyne.com/WeatherWS/Weather.asmx");
            // factory.getInInterceptors().add(new org.apache.cxf.interceptor.LoggingInInterceptor());
            // factory.getOutInterceptors().add(new org.apache.cxf.interceptor.LoggingOutInterceptor());
            // WeatherSoap weatherSoap = (WeatherSoap) factory.create();
            long end = new Date().getTime();
            LOGGER.debug("...Done! weatherService instance: {}", weatherService);
            LOGGER.debug("Time required to initialize weather service interface: {} seconds", (end - start) / 1000f);

            // Send a SOAP weather request for zip code 94025 (Menlo Park, CA, USA).
            LOGGER.debug("weatherSoap instance: {}", weatherSoap);
            start = new Date().getTime();
            ForecastReturn forecastReturn = weatherSoap.getCityForecastByZIP("94025");
            end = new Date().getTime();
            LOGGER.debug("Time required to invoke 'getCityForecastByZIP': {} seconds", (end - start) / 1000f);
            LOGGER.debug("forecastReturn: {}", forecastReturn);
            LOGGER.debug("forecastReturn city: {}", forecastReturn.getCity());
            LOGGER.debug("forecastReturn state: {}", forecastReturn.getState());
            LOGGER.debug("forecastReturn result: {}", forecastReturn.getForecastResult());
            LOGGER.debug("forecastReturn response text: {}", forecastReturn.getResponseText());
            LOGGER.debug("");
            List<Forecast> forecasts = forecastReturn.getForecastResult().getForecast();
            for (Forecast forecast : forecasts) {
                LOGGER.debug("  forecast date: {}", DATE_FORMAT.format(forecast.getDate().toGregorianCalendar().getTime()));
                LOGGER.debug("  forecast description: {}", forecast.getDesciption());
                Temp temps = forecast.getTemperatures();
                LOGGER.debug("  forecast temperature high: {}", temps.getDaytimeHigh());
                LOGGER.debug("  forecast temperature low: {}", temps.getMorningLow());
                POP pop = forecast.getProbabilityOfPrecipiation();
                LOGGER.debug("  forecast precipitation day: {}%", pop.getDaytime());
                LOGGER.debug("  forecast precipitation night: {}%", pop.getNighttime());
                LOGGER.debug("");
            }
            LOGGER.debug("Program complete, exiting");
        }
        catch (Exception e) {
            LOGGER.error("An exception occurred, exiting", e);
        }
    }

}

Note that we’re importing the stubs as import com.cdyne.ws.weatherws.Forecast, etc, within the client program. The client is also hard-coded to get the weather report from the 94025 zip code, although you could easily alter the client to take the zip code as a command-line argument.

The All-Important CXF Client Configuration File

This is the part of the development process that threw me for a loop. I didn’t see any CXF documentation that indicated a cxf.xml file needs to be in the classpath of the client, so I hadn’t included one in the project. My client program kept failing with a (very cryptic, very unhelpful) CXF BusException (the complete message was org.apache.cxf.BusException: No binding factory for namespace http://schemas.xmlsoap.org/soap/ registered, which I’m mentioning here in case anyone else is Googling with the same problem).

Sure, there are plenty of CXF tutorials on the Internet, but they mostly seem to build a client and a service in the same project (sharing a cxf.xml file) and I had assumed the configuration file was for configuring only the server. Silly me.

It took me several days of Googling, trying different JAR dependencies, Googling again, testing various source code modifications, Googling some more, asking for help on the cxf-user mail list — all to no avail.

Eventually, while reading the solution to an unrelated problem, I finally discovered the cause. On start-up for a server OR A CLIENT, the CXF system looks for a cxf.xml file, and fails without it. Just for the record, the BusException message is incredibly unhelpful. Grrr!! I think it should read something like org.apache.cxf.BusException: No binding factory for namespace http://schemas.xmlsoap.org/soap/ registered (did you include a cxf.xml file somewhere in the classpath?), or some such.

Anyhoo, here’s the CXF configuration file I used. Not much to it. It’s basically just a trivial Spring configuration with three lines of imports.

weather-client/src/main/resources/cxf.xml

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"
    xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration

http://cxf.apache.org/schemas/configuration/http-conf.xsd

http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans.xsd">

    <import resource="classpath:META-INF/cxf/cxf.xml"/>
    <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml"/>
    <import resource="classpath:META-INF/cxf/cxf-servlet.xml"/>

</beans>

Good thing this is easier than Axis.

Logging Configuration

For completeness, I’ve included the logging file I used. Since we’re using LOG4J as the logging layer under SLF4J, we need to supply a log4j.properties file.

weather-client/src/main/resources/log4j.properties

log4j.rootCategory=WARN, CONSOLE
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=[%d{ABSOLUTE} %-5p %c{1}]: %m%n
log4j.logger.com.logicsector=DEBUG

Building and Running the Client

Once you have all the code in order, it’s time to build it. From within the weather-client directory, just use the previously-mentioned Maven build command to create a JAR file with dependencies:

mvn assembly:assembly

Now we can run the client. As mentioned previously, the client is hard-coded to get the weather report for the 94025 zip code (Menlo Park, California). From within the weather-client directory, the following command will start the client and invoke the service:

java -cp target/weather-client-jar-with-dependencies.jar com.logicsector.soapclient.SoapClient

The command above should all be on a single line. Note you may need to change your path separator if you’re not on a Unix-based system. If everything went smoothly you should see output something like this:

[17:31:06,278 DEBUG SoapClient]: Creating weather service instance (Note: Weather = Service subclass)...
Oct 18, 2008 5:31:08 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromWSDL
INFO: Creating Service {http://ws.cdyne.com/WeatherWS/}Weather from WSDL: file:/c:/Projects/weather-client/src/main/wsdl/weat
her.wsdl
[17:31:08,325 DEBUG SoapClient]: ...Done! weatherService instance: com.cdyne.ws.weatherws.Weather@754fc
[17:31:08,325 DEBUG SoapClient]: Time required to initialize weather service interface: 2.047 seconds
[17:31:08,325 DEBUG SoapClient]: weatherSoap instance: org.apache.cxf.jaxws.JaxWsClientProxy@6458a6
[17:31:08,825 DEBUG SoapClient]: Time required to invoke 'getCityForecastByZIP': 0.5 seconds
[17:31:08,825 DEBUG SoapClient]: forecastReturn: com.cdyne.ws.weatherws.ForecastReturn@aea710
[17:31:08,825 DEBUG SoapClient]: forecastReturn city: Menlo Park
[17:31:08,825 DEBUG SoapClient]: forecastReturn state: CA
[17:31:08,825 DEBUG SoapClient]: forecastReturn result: com.cdyne.ws.weatherws.ArrayOfForecast@5a2eaa
[17:31:08,825 DEBUG SoapClient]: forecastReturn response text: City Found
[17:31:08,825 DEBUG SoapClient]:
[17:31:08,825 DEBUG SoapClient]:   forecast date: Friday, October 17 2008
[17:31:08,825 DEBUG SoapClient]:   forecast description: Sunny
[17:31:08,825 DEBUG SoapClient]:   forecast temperature high: 82
[17:31:08,825 DEBUG SoapClient]:   forecast temperature low: 58
[17:31:08,825 DEBUG SoapClient]:   forecast precipitation day: 00%
[17:31:08,825 DEBUG SoapClient]:   forecast precipitation night: 00%
[17:31:08,825 DEBUG SoapClient]:
[17:31:08,825 DEBUG SoapClient]:   forecast date: Saturday, October 18 2008
[17:31:08,825 DEBUG SoapClient]:   forecast description: Sunny
[17:31:08,841 DEBUG SoapClient]:   forecast temperature high: 73
[17:31:08,841 DEBUG SoapClient]:   forecast temperature low: 55
[17:31:08,841 DEBUG SoapClient]:   forecast precipitation day: 00%
[17:31:08,841 DEBUG SoapClient]:   forecast precipitation night: 00%
[17:31:08,841 DEBUG SoapClient]:
[17:31:08,841 DEBUG SoapClient]:   forecast date: Sunday, October 19 2008
[17:31:08,841 DEBUG SoapClient]:   forecast description: Partly Cloudy
[17:31:08,841 DEBUG SoapClient]:   forecast temperature high: 70
[17:31:08,841 DEBUG SoapClient]:   forecast temperature low: 55
[17:31:08,841 DEBUG SoapClient]:   forecast precipitation day: 00%
[17:31:08,841 DEBUG SoapClient]:   forecast precipitation night: 00%
[17:31:08,841 DEBUG SoapClient]:
[17:31:08,841 DEBUG SoapClient]:   forecast date: Monday, October 20 2008
[17:31:08,841 DEBUG SoapClient]:   forecast description: Partly Cloudy
[17:31:08,841 DEBUG SoapClient]:   forecast temperature high: 70
[17:31:08,841 DEBUG SoapClient]:   forecast temperature low: 53
[17:31:08,841 DEBUG SoapClient]:   forecast precipitation day: 00%
[17:31:08,841 DEBUG SoapClient]:   forecast precipitation night: 00%
[17:31:08,841 DEBUG SoapClient]:
[17:31:08,841 DEBUG SoapClient]:   forecast date: Tuesday, October 21 2008
[17:31:08,856 DEBUG SoapClient]:   forecast description: Sunny
[17:31:08,856 DEBUG SoapClient]:   forecast temperature high: 73
[17:31:08,856 DEBUG SoapClient]:   forecast temperature low: 54
[17:31:08,856 DEBUG SoapClient]:   forecast precipitation day: 00%
[17:31:08,856 DEBUG SoapClient]:   forecast precipitation night: 10%
[17:31:08,856 DEBUG SoapClient]:
[17:31:08,856 DEBUG SoapClient]:   forecast date: Wednesday, October 22 2008
[17:31:08,856 DEBUG SoapClient]:   forecast description: Sunny
[17:31:08,856 DEBUG SoapClient]:   forecast temperature high: 74
[17:31:08,856 DEBUG SoapClient]:   forecast temperature low: 55
[17:31:08,856 DEBUG SoapClient]:   forecast precipitation day: 00%
[17:31:08,856 DEBUG SoapClient]:   forecast precipitation night: 00%
[17:31:08,856 DEBUG SoapClient]:
[17:31:08,856 DEBUG SoapClient]:   forecast date: Thursday, October 23 2008
[17:31:08,856 DEBUG SoapClient]:   forecast description: Sunny
[17:31:08,856 DEBUG SoapClient]:   forecast temperature high: 73
[17:31:08,856 DEBUG SoapClient]:   forecast temperature low: 55
[17:31:08,856 DEBUG SoapClient]:   forecast precipitation day: 00%
[17:31:08,856 DEBUG SoapClient]:   forecast precipitation night: 00%
[17:31:08,856 DEBUG SoapClient]:
[17:31:08,856 DEBUG SoapClient]: Program complete, exiting

Interestingly, it takes 2 seconds on my machine to initialize the interface, which seems like a really long time. CXF is probably doing a lot of stuff under the covers, but still, 2 seconds is forever in computer time.

The call to the weather service interface, once initialized, takes about half a second every time, which includes marshalling a SOAP request, sending it over the internet, receiving the response, and unmarshalling its contents. Not too bad I guess.

Concluding Thoughts

Hopefully this example will form the basis of your next SOAP client. It really is pretty easy once you see a complete and working example.

If you were ambitious, parts of this code could easily be incorporated into a web application that provides a weather report for the user. You’d simply create a servlet that takes the zip code as a parameter, invokes the SOAP service, and shows the weather report in the response. In other words, the technique of calling the SOAP service would be the same even if this was a web application.

Well, that’s the end of my post about creating a CXF client with Maven. I’d love to read your comments if you found this post helpful.

EDIT: Download the Source!

All the code necessary to build the project is listed above. However, to save time, you can simply download the code from my web site. Happy coding!

Angel eyes have changed over the years. BMWs that shipped back in 2005 (the year my car was built) have a much dimmer, yellowish halos as original equipment. Fortunately the aftermarket has stepped up to offer upgrades to our dim, yellow halos.

The first generation of angel eye upgrades were just as dim as BMW’s original equipment at about 1 Watt, but they changed the yellow halos to white.

The latest aftermarket halo upgrades are not only white, but much brighter than the original halo upgrades. They’re still not quite as bright as halos on a new BMW, perhaps, but not too shabby either.

Armed with the above information I went searching for a nice halo upgrade. Here’s what I found.

Where To Buy

I discovered that a company called MTEC offers an upgrade to pure white halos that are rated at 6W with their so-called “V3″ model. The LEDs in these units are made by Cree. These halos are about as bright as you can get, currently, without some extensive modifications to the car.

You can pick up MTEC parts at various online resellers or directly off eBay. I went the eBay route by purchasing from a vendor named “mtecpower”. If you’re an e63/e64 BMW driver you can find the right angel eyes by clicking this eBay search link. Total price should be less than $200.

A Note About Installation

The nice thing about the MTEC upgrades is that they are really easy to do yourself. It took me about 15 minutes to swap out both halo lights, but if I had known what I was doing it would have literally taken about 5 minutes. The only price was some scuffed knuckles and a cut pinky finger. For a 6 series like mine the headlights themselves don’t need to be removed, only the halo bulbs.

Note that to perform the upgrade you have to have pretty small hands since the gap in the engine bay near the halo bulbs is pretty tight. My pudgy hands barely fit.

Here is a link to a YouTube video that shows how it’s done.

How It Looks

With no further ado, here is the new look that shows the difference…

New halo on left, OEM halo on right. Taken in late afternoon.

MTEC V3 halo upgrades installed in my car. Nice and bright!

Headlight lit along with upgraded halos. Note white halo color matches headlight now.