Recently, I consumed a WSDL with Apache CXF that required authentication information to be placed into a SOAP Header rather than through standard HTTP authentication. This is all well and good, but I couldn’t figure out how to attach the headers to the CXF method calls. The authentication object had been generated by CXF, but there was no way to attach the object to the other methods.

After some research, I found the answer. Adding -exsh true to WSDL2JAVA updated the method signatures to include the header object as a valid parameter. If you’re cool like me and use the CXF Maven code generator plugin, the XML looks like this:

<execution>
<id>generate-sources-vixxi</id>
  <phase>generate-sources</phase>
    <configuration>
      <sourceRoot>target/generated-sources</sourceRoot>
        <wsdlOptions>
          <wsdlOption>
            <extraargs>
              <extraarg>-exsh</extraarg>
              <extraarg>true</extraarg>
            </extraargs>
          <wsdl>yourWSDLPathHere</wsdl>
        </wsdlOption>
      </wsdlOptions>
    </configuration>
    <goals>
      <goal>wsdl2java</goal>
    </goals>
</execution>

I verified this works with CXF 2.0.9 and 2.1.4. I haven’t tested it on any other versions, but I don’t see any reason why it wouldn’t work on 2.0.9+.

Or, perhaps more fittingly, why I am unhappy with Comcast.

Since I got back to Colorado from Hawaii in 2003, I’ve used, and been relatively happy with, Comcast broadband Internet. There have been issues, but nothing that has been so bad as for me to consider moving to another service.

Unfortunately, that changed last week.

Let me back up and say that I don’t often use my Blog to call out a company for something irritating (that’s usually relegated to Twitter). In this case, however, I feel it a good object lesson in how poor design coupled with horrible customer service can transform a (mostly) satisfied customer and cause them to look into other options.

What took place is pretty simple to understand. My wife and I share the account, and her email address is one of the six email accounts that I can have attached to our service. She decided she wanted to add another address. What she didn’t know, and what the UI didn’t tell her (in BIG RED WARNING LETTERS) was she was actually changing her email account. Without any “are you sure you understand what you are doing and want to do this?” type of dialog, her email address was changed and her previous account stopped receiving mail immediately.

When she realized what happened, she frantically clicked back to get her old address re-activated, but the UI continued to tell her the username was in use even though it had been deactivated.

She called me pretty upset, and I got on the phone with Comcast. They told me that they couldn’t do anything about the issue for a minimum of 30 days. When I asked them why, they told me that when an email address is deactivated, it gets placed into a “holding” status for 30 days to insure another person doesn’t take the alias and start receiving mail intended for another customer. This makes a lot of sense to me. The odd thing is that they couldn’t re-activate it for the same customer!

I told the CSR on the phone that someone should be able to quite easily login to their database and type something like:

update user set status="active" where username = "[Amber's username]";

and that, while I knew he couldn’t do it, someone with a shiny Comcast data-center badge could.

After much back and forth, he finally submitted an “IT” ticket for me. Since then, and his promise that this would be resolved in 72 hours (over a week and a half ago from today), I’ve heard nothing.

There are a couple of lessons here. The first is that it is obvious Comcast doesn’t get how important an email address is. I would have rather Amber lost her phone number than her email address. From our online banking to Facebook, it is extremely difficult to change an email address when you have no access to the old one. Most services send confirmation messages to the old email address. The CSR I spoke with and Comcast’s policies in general around this issue prove that, while they claim to be on the vanguard of Internet technology, they just don’t get it. At all.

Secondly, it is extremely easy to add UI confirmations so do it! There is no excuse for this type of oversight whatsoever.

Our current plan is to switch over to Qwest Fiber as soon as it becomes available in our area. Unfortunately, Comcast has lost our confidence.

The Autocompleter suite of functions in Scriptaculous are pretty nice. While they don’t solve every autocomplete problem straight out, they do provide a good starting point.

However, the answers to problems in Javascript are not always obvious. Despite some amazing support from Firebug, debugging is often difficult and tracing down problems can be rough.

Earlier this week, I ran into a very strange problem with Autocompleter.Local. I was designing a page that would query the server for a list of cities in a state and load that list into the Autocompleter. The catch was that the state could be changed at any time by the user, and the array containing the list of cities available would be updated asynchronously from the server. (While there is an Autocompleter.Ajax for automatic server updates, this assumes the autocompletion is done on the server side which I deemed too slow to be very functional in our case.) The specific issue I was having was that the city name was inserted into the target text field multiple times as the number of hits to the server for updated city lists increased.

I discovered, after looking over code in control.js, that the Autocompleter attaches event observers every time it is newed up. These event observers are difficult to remove manually because they pass in states of the specific object that are often no longer available. I had code that was doing something like:

[get list of city names for a state into cityNameList]
if(!autocompleter)
  autocompleter = new Autocompleter.Local('cityTextfield',
   'cityAutocompleteList', cityNameList);

but the the observers that the Autocompleter was creating were being piled up on each other every time I “reset” the Autocompleter to a new instance.

I discovered that the Autocompleter data is stored in the .options.array field. While it is not documented as part of the API, updating this array effectively updated the Autocompleter without adding new event observers. All I had to do was new up the Autocompleter variable once and then update this array field (directly; using dot notation) every time the data from the server changed.

Often, the Struts 2 tag library doesn’t offer enough functionality to support a nice DHTML type of layout. In those cases, I find myself creating URLs manually to send to the action.

In most cases, this isn’t a bid deal. However, to make it work right, you have to duplicate the format that Struts uses to receive the data. For example, to send a list of items (such as List<String> names;), you would format your URL to look like


&names=johnny&names=tim&names=bill


Maps are a little harder. To create a URL to send to a map, you can use the following format:


&variableName[key]=value


Say you have the following map:

Map<Integer, Integer> userIdOrderIdMap = new HashMap<Integer, Integer>();

To set the map from Struts 2, you’d use the following URL string:


&userIdOrderIdMap[0]=1&userIdOrderIdMap[10]=15

This is the equivalent of:


userIdOrderIdMap.put(0, 1);
userIdOrderIdMap.put(10, 15);


You will probably have to manually call encodeURIComponent() on the URL string to make sure the brackets and any other special characters are escaped properly, but you already knew that, right?

You can also use a dot notation (such as &variableName.key=value), but I find that a bit counterintuitive to the way KVC types are intended to be represented.

Yesterday, my dev team embarked on a significant refactor of our main code base in order to merge in a branch alongside implementing new functionality and changing some existing classes. A trifecta of complexity if you will. For a production quality system, one that we expect to deploy very soon and is the backbone of our company’s infrastructure, you might expect us to have been a bit more careful / timid in making our changes.

However, you’d be wrong and it’s all because of unit tests (that and we are all rock-star engineers, but that’s another post).

I didn’t work with unit tests much before my current position. This was mostly due to legacy platform limitations that did not make automated testing easy. Now, I couldn’t live without them. Confidence in my work is much greater now than it was previously for a good reason: unit tests give engineers power.

I know that the requirements of a particular class are laid out in the classes’ test. Whatever I do to the class, it must not only compile but light up green. This gives me the boldness to make large changes without worrying that the refactor is going to negatively impact (read: break) other parts of the system.

Code these days often exists beyond the classes themselves and in places like configuration files and build scripts, and we’ve created tests that take these pieces of auxiliary setup into account. Doing that extends our confidence beyond our primary classes and into our build process, database connections, and system as a cohesive whole. Very cool.

Unit tests are great for creating interfaces (working with the API before you actually write the implementation is a good way to make sure it doesn’t suck), verifying complex functionality, and system integration. The most empowering thing they offer, however, is confidence. In an agile shop such as ours, this gives us the ability to work as quickly and fluidly as possible and is a huge factor in why our little team has been so successful.

“A compiler tells you your code is well formed, a unit test tells you your code is well behaved.”

– No Fluff Just Stuff, Fall 2008

A few weekends ago (November 14-16), I attended the No Fluff Just Stuff software symposium. It was a three-day long event with some of the best and brightest in the Java, open source, and engineering-in-general space. I took a lot out of this conference, and I’m looking forward to going again in the near future. One of the great things about going to something like this is watching how the touring speakers use different tools. Even with applications that I use on a regular basis (such as TextMate), I was able to pull some new uses and features from the presentations. Here is my take on the sessions I attended:

1. Groovy: The Blue Pill – This was the first talk from Scott Davis on Groovy. It was designed to be an easy introduction to the Groovy space for current Java developers. Some standout information:
   1. Groovy compiles to Java bytecode
   2. Groovy consists of only one .jar file
   3. Groovy includes a lot of Java cruft built in for free (such as automatic getters/setters, default constructors, etc.)
   4. Groovy can easily call Java methods and use Java objects
   5. Groovy can use inline values in Strings (called “G”-strings)
   6. You can easily insert XML, JSON, HTML, etc. into a Groovy string using triple quotes
   7. Unit tests are a great insertion point to begin integration of Groovy into a Java application (but Groovy currently only supports JUnit 3.x and not 4.x)
2. Groovy: The Red Pill – This was the second talk on Groovy from Scott Davis. This talk was intended to demonstrate the real flexibility and power of Groovy rather than simply touting its interoperability with Java:
   1. Groovy can use “Groovy truth” which allows statements such as
      if(array) {}
      rather than
      if(!(array==null || array.isEmpty())) {}
   2. Groovy supports operator overloading
   3. Groovy supports closures and has some great support for iteration through collections
3. Rapid Web Development with Grails and AJAX – This was the third talk on Groovy from Scott Davis which covered how Groovy and Grails integrate to create an incredible web application development experience. Unfortunately, much of the AJAX information was cut short due to a guy in our session asking a bunch of “Rails vs. Grails” questions. Some good points:
   1. Grails was inspired by Rails but is not a clone of Rails
   2. Grails is a full-stack solution and not simply a framework like Struts or Spring MVC
   3. Grails is database agnostic and supports practically every Hibernate dialect available
   4. Grails has some great IDE support
   5. Grails has great built-in AJAX and scaffolding support
4. Give It a Rest – This was Brian Sletten’s first talk on REST (Representational State Transfer). I have a fair amount of practical experience with REST API’s (creating, consuming), but this was a great talk about the goal of a REST API and how it relates to an application as a whole.
   1. SOAP is overkill in many situations and increases complexity
   2. Over 85% of Amazon customers prefer to use the REST API rather than its SOAP counterpart
   3. REST is more than just URLs
   4. REST focuses on information spaces rather than code or objects
   5. REST can use HTTP return codes to dynamically point to moved resources
   6. REST uses HTTP verbs to indicate the desired action
   7. Since REST uses HTTP, it is stateless and takes advantage of built-in browser caching to reduce server overhead
5. Spring 2.5: Spring without XML – This was Ken Sipe’s talk on Spring 2.5 without the XML-hell that many of us Spring 2.0 developers are wading through. I don’t currently use Spring 2.5, so it was difficult at times to follow where Ken was going. However, I soaked in a lot of the capabilities of Spring without XML and finding out exactly “how” to do something is much easier than the information gap of knowing if it is possible or not.
6. Java.Next – Stuart Halloway spoke in this session about all the different languages that are making their way into the JVM. Most of his talk was simply about why this is happening and why it is good for the Java community (and, trust me, it’s very good for us!) I didn’t take too many notes during this session, but he definitely convinced me (although, to be honest, Scott Davis’ sessions on Groovy had me convinced already)
7. Architecture and Scaling – This presentation, by Ken Sipe, was an outstanding pragmatic approach to creating an easily scalable application. Some good points:
   1. Scalability is about predictability (e.g. if you know what a load looks like with 200 users, you should know what it looks like with 400)
   2. Scalability can be horizontal (adding more nodes) or vertical (adding more resources to a node such as increased memory or CPU power)
   3. Performance is not equal to scalability. You often have to sacrifice up-front performance gains to make room for future scalability (one example great Ken used was a load balancer. Load balancers introduce latency to a project, but allow for multiple nodes to be inserted and, therefore, increase scalability)
   4. An engineer should always be trying to manage things outside their control (e.g. user behavior)
   5. Metrics are good; use them
8. Git – Another Stuart Halloway talk revolving around the new SCM system called git. While I was already a bit familiar with git, this talk intrigued me enough to find an environment whereby I use it on a regular basis and can put it through its paces.
9. Introduction to Hibernate – Scott Leberknight’s talk on Java Hibernate.
   1. Hibernate is a very popular open-source ORM framework
   2. Hibernate uses dialects to talk to a database
   3. Hibernate uses annotations to communicate relationships between objects (one-to-many, one-to-one, etc.)
10. Rich Clients, Rich Data Linking and Consuming – These were the last couple of talks of the conference by Brian Sletten. He expanded on REST concepts and showed how RDF can be used for some pretty amazing data combinations. He also encouraged projects to move beyond their silos and expose their data to the rest of the web. He had some amazing examples of this sort of exposure, and I am excited to put some of his ideas to use at some point.

The conference was pretty amazing and I am very happy to have gone. In addition to the sessions above, there was a great keynote by Ken Sipe about inter-relational skills engineers should strive to build. A great quote from this keynote:

Your employer is responsible for your job; you are responsible for your career

Watch your iPhones, kids!

Walking out of work today, a guy stopped me on the sidewalk and asked if he could pay me a dollar to make a call. I told him that he could make one for free (how nice of me) and asked him the number (it is a lot faster for me to dial a number since many people don’t know how to access the dial-pad unless they already own an iPhone).

The guy called a number (720-621-7655) and said something along the lines of “I’m stranded at 21st and Larimer” to the answering party. He then proceeded to steal my phone.

I chased him around the corner with Amber in the car (who had pulled up right as the guy started running away) following on the street. About two blocks or so later, I caught up to him and he proceeded to change direction and cross right in front of a line of cars on a one-way street running into a small alleyway. At that moment, another car (going the wrong way on the street) pulled into the same alleyway and I thought that my phone was gone. I figured the guy had called a friend to come pick him up and my mind went right to figuring out strategies to either locate my phone (unlikely) or simply make sure all my personal / work data was properly disposed.

After saying a few curse-words, Amber noticed a group of people congregating about half a block from the alleyway the thief disappeared into, and I recognized the vehicle as the same car that pulled in after him. As it turns out, the driver of the car had noticed me chasing the guy down the street and had taken it upon himself to retrieve my phone. In just a few minutes, I had my phone back in perfect condition.

I learned a few things from this:

1. Don’t let strangers make calls. It’s 2008 … get your own damn phone.
2. I enabled the password on my phone. If it’s entered incorrectly 10 times, all data will be wiped clean. It’s not too cumbersome to type in the code every now and again, and it will definitely come in handy if this ever happens again.

The phone itself is valuable but it’s the data that I was most concerned with. I can always cancel the phone’s IMEI and suspend the account, but the jerk-off would have had access to all my emails, Twitter account, and whatever else I have loaded. Granted, the guy didn’t seem very technically minded (probably just saw a shiny object he thought he could sell for crack or something), but the fact that my personal information was just “out there” really sent me for a loop.

Learn from my mistakes and lock up your phones!

Great post on Finding Rhythm here: http://www.findingrhythm.com/blog/?p=1428. Got me thinking about “traditional marriage” as defined by Dr. Dobson and other fundamentalist leaders.

It’s pretty easy to see that:

1. Marriage has not been defined as “one man and one woman” since the beginning of human history
2. The definition of marriage has always been based on culture

The Bible has some historical elements and, while the actual authenticity might be in question, you can glean a lot about ancient values from some of the narratives. People often got married during that time for political and economic reasons more than anything. It makes a lot of sense to have as many wives as possible so you can get as many children (hopefully males) as possible in order to gain an economic and strategic advantage over other tribes.

It was cultural.

If we can admit that this sort of definition is not objective but based on current cultural conditions, why would it be so hard to simply extend that definition to include homosexual couples?

My marriage is not based on some fundamental definition of what it’s supposed to look like. It is fluid; looking a little different every day. There was a period of time in our society where a marriage looked like a man as the bread-winner and the woman as a home maker. That definition has changed fairly dramatically over the last fifty years. Despite that shift, I don’t hear people trying to push a constitutional amendment that defines marriage as “a male earning the family’s money while a female takes care of the home.” If this did actually make it up for a vote, there would be a public outcry eerily similar to that of many homosexual couples.

Again, I encourage those on the social right to try and be intellectually honest about this issue. There are far more important problems to be dealing with right now than what relationship is more legitimate based on something that is, by nature, subjective.

A few weeks ago, I listened to this podcast from NPR regarding the credit crisis and all the craziness that took place right before the bubble began to burst.

One gentleman by the name of Glen practically leaped out of the report. He was a young guy, fresh out of college, making $75,000-$100,000 per month. His job was to package mortgages and sell them to Wall Street as investment products.

Can you imagine how much hell you’d raise with all that money at 22-23 years old?

I’d imagine any of us would take that opportunity if it came up given the circumstances at the time. Unfortunately, that’s not usually how life works.

Cultivating a career is hard work. It rarely falls into your lap and you rarely make a lot of money when you start. It takes a lot of sacrifice on your own time reading, studying, making connections, etc.

You should expect to spend a good chunk of your early life deciding what you want to do and how you can leverage that in order to feed your family in the future. Once that decision is made, you should expect that it is going to take several years before the fruit of your labor is going to kick in. Often, as in my field, it takes a college degree plus a few years of experience before you start making some decent money.

I’m extremely lucky in that I found a career I love that also happens to offer a pretty decent salary (albeit sub-Glen) all things considered. However, it hasn’t been extraordinarily easy to become good at what I do. I’ve been working at it since I created my first “for-profit” program at the age of 13!

I’d advise anyone to be cautiously skeptical of any position that promises the kind of money Glen was making (or even a fraction of that) without putting in a fairly substantial amount of time and energy. If you’re lucky (and perhaps more importantly, talented) you might be able to cut a few corners here and there. But don’t count on it. Trying to make a quick dollar instead of a career is like a crap shoot and your chances of a sustainable lifestyle decrease substantially the more you believe that you can avoid the ramp up period and jump right into dropping your Hamiltons. Even beyond that, it’s much easier to live a modest life doing something you enjoy than to hate what you do and make lots of money.

If anything, this credit crisis has demonstrated just how fleeting the promise of quick wealth can be. If it sounds too good to be true …

I haven’t written much about this here, but Amber (my wife) and I have been trying to jump-start our family for the last couple of years or so. After some tests earlier this year, we realized that we had a choice: either attempt In Vitro Fertilization or adopt. For a few reasons, we chose adoption.

However, adoption is not cheap and we are far from rich. We’ve already spent about $11,500 (initial deposit; took out a loan) which we expect to get back via an adoption credit on our taxes for whatever year we actually get a baby.

Adoption costs vary but we expect to spend $10,000-$15,000 more over the course of the time between now and when we finally bring home an infant. So, we are officially asking for help. We’ve both been very active in the blossoming social network that the Internet has turned into over the last decade and, after donating ourselves to many causes that we personally believe in, we’re hoping that spirit of generosity extends outside our small sphere and encompasses the social community as a whole.

So, we’ve launched HelpUsStartAFamily.com, a site that acts as a hub to convey as much information as possible about us alongside receiving any amount you might feel inclined to give.

Our goal is to spend the money taking in a baby that has no home. Any additional amount we receive beyond the cost of our adoption will go to a charitable organization that helps adoptive families (we’re still looking for one … I’m sure they exist somewhere!)

Unfortunately, we can’t give a tax benefit or provide “official” accountability of funds like a not-for-profit corporation might, but we have created a pretty transparent link to help put any doubts about our motives at ease.

Thanks for any help you might provide and thanks for reading this blog!

www.HelpUsStartAFamily.com