Dan Kulp's Blog

I kind of feel bad about not blogging this earlier in the week, but it’s been one of those weeks…

On Monday, Glen Mazza officially started at Talend. For those of you that are not familiar with him, Glen has been a long time commiter to Apache CXF getting started with CXF while it was still in the incubator. On CXF, he’s probably best known for reviewing the code and changes and such and fixing all the typos he found and enhancing the error messages and javadoc and such. While not a strict “feature contribution”, these types of changes have been invaluable in making CXF more pleasant to use.

However, he is a software engineer so he’s also contributed to CXF in other areas. He’s done a bit of work in the WS-Security stuff, especially in the area of creating test cases and identifying deficiencies and bugs. He’s also done quite a bit of testing with CXF and other WS-Security implementations (mostly Metro) to find interopability issues and has worked to get them resolved.

That all said, he’s probalby BEST known for the examples and walk throughs that he has done on his blog: http://www.jroller.com/gmazza/ His examples on his blog have been a great starting point for MANY CXF users as they start using CXF. When people ask for a getting starting tutorial or sample, many people point them off to his blog. His blog also tends to collect links to other interesting web pages and blogs and such related to Web Services. Definitely a great place to look for information.

Anyway, I just wanted to say “Welcome Aboard!” to Glen and I definitely look forward to working with him to make CXF better and make Talends products better.

For those of you that don’t follow the news feeds and press releases an such, Talend and Sopera announced this morning that Talend has acquired Sopera. Since I know a lot of you are too lazy to go read the actual press release, here’s a quick summary:

• Talend acquires Sopera
• Talend also has secured $34 million in financing from Silver Lake Sumeru and it’s existing investors
• Sopera will become Talend’s “application integration division”

So, what does this mean? Well, for starters, as of today, I’m now an employee of Talend. How exciting. Third company this year. Time to go update profiles and such. Again.

Seriously, the combination of Sopera and Talend makes a lot of sense. Talend is best known for it’s technology around data management. Taking a step out, the next category of problems that customers usually face are application integration problems, and that’s where Sopera comes in. Through Sopera’s current “ASF” product, the Swordfish project at Eclipse, involvement in various Apache projects, and it’s engagements with it’s customers, Sopera is recognized as a leader in solving tough application integration problems. The combination of Sopera and Talend provides a complete middleware platform.

The $34M in financing that was secured is also an exciting part of the announcement. Obviously, the extra money helps to allow us to rapidly expand the teams. Talend/Sopera will definitely be hiring good developers. (On a related note, with Talend having more locations around the world, like huge offices in France and the US, things like employee benefits are a bit more secure, especially for a US based person like myself.) The more important thing to look at, however, is WHO is doing the financing. Silver Lake is NOT a small investment firm. They’ve been in the business of financing technology companies for quite a while. They know what they are doing. They do their homework before investing to give the investment the highest chance of success. The fact that they are investing that much money into Talend really shows that they believe the strategy can work.

If you missed my note last week, we’ve already started to grow the team by hiring Sergey Beryozkin and Colm O hEigeartaigh, both highly regarded engineers at Apache. We plan to continue the process of expanding the team as we refine our product strategies and prepare new product offerings. More to come on that topic at a future time.

Anyway, I’m very excited about this. I believe that this can really “open the doors” for new opportunities for both Sopera and the Apache projects that I’m involved in.

I’m very excited to be able to announce that two very talented developers have joined the Sopera team.

The first is Sergey Beryozkin. Sergey has been an extremely valuable resource in developing, promoting, and supporting the JAX-RS and other REST related parts of Apache CXF. He’s also been a solid contributor to the DOSGi stuff, various JAX-WS/WS-* things, very active on the mailing lists, etc…. Basically, a very valuable CXF contributor.

The second developer joining us is Colm O hEigeartaigh. Colm is an expert in the various XML security related specifications and technologies. He is one of the main contributors (and release manager) to the Apache WSS4J project and is the PMC Chair of the Apache Santuario project. He has contributed several patches to CXF related to the WS-Security runtimes, and I fully expect that to continue.

With the addition of Sergey and Colm to the team, Sopera is now the one company that can really provide top notch support and leadership for CXF.

Anyway, I want to extend a warm welcome to both Sergey and Colm and I look forward to working with them once again.

It’s been a LONG time coming (way too long, actually), but Apache CXF 2.3.0 is finally released. This version is a pretty significant upgrade from the 2.2.x series of releases.

New features include:

• JAX-WS 2.2 Compliant (passes TCK)
• JAX-RS 1.1 Compliant (passes TCK)
• New annotations for Java first use cases to reduce the need for external configuration and provide more control over the runtime and generated WSDL
  • @WSDLDocumentation annotation to add documentation nodes to generated wsdl
  • @SchemaValidation annotation to turn on schema validation
  • @DataBinding to set the databinding used (if other than JAXB)
  • @GZIP to turn on GZIP compression
  • @FastInfoset to turn on FastInfoset support
  • @Logging to turn on and control various Logging functionality
  • @EndpointProperty to configure endpoint properties
  • @Policy to associate WS-Policy documents with the service
• SOAP/JMS spec implementation. While CXF has supported SOAP over JMS since 2.0, there wasn’t a standard specification to describe how it should be done so different vendors did things differently and interoperability was impossible. The new SOAP/JMS specification support implements the new SOAP/JMS spec to achieve a higher degree of interoperability. The older SOAP/JMS configuration is still supported. WS-Addressing also now fully works with the JMS transport when used in conjunction with the SOAP/JMS spec implementation.
• SDO databinding
• Schema Validation support for Aegis Databinding if Woodstox 4 is used for the Stax parser
• Many other small tweaks and enhancements, too many to enumerate.

In addition to the above, CXF 2.3.0 was enhanced to reduce it’s memory footprint and reduce it’s startup time by delaying creation of many objects until/unless they are really needed.

See the 2.3 Migration guide for more details about the release.

Along with 2.3.0, the latest patch for the 2.2.x series (2.2.11) was also released. This patch fixes over 60 JIRA issues compared to 2.2.10. The CXF community prides itself on it’s ability to get fixes out to users in a timely manner. However, if you need better support than that, I have to recommend contacting Sopera as they can support all aspects of CXF usage better than any other company.(my opinion)

I’ve been unemployed for just over 9 weeks now, but as of today, that comes to an end as I start a new job. While I did spend a significant part of that time NOT thinking about working at all, I have spent the last few weeks chatting with several people about opportunities. In the end, it really came down to one of three options:

1. Independent contracting – the day I was layed off, I had SEVERAL people contacting me about possible contracts and projects needing help and such. Being one of the primary developers on the leading Java Web Services stacks, there are a LOT of opportunities with companies using CXF that would like an expert to come in an help out. I really did consider this option fairly extensively. Bunches of pros (money, hours, tax deductions for new computer, etc..) and few cons (likely some travel).
2. JBoss/RedHat – RedHat is a gigantic company and there are PLENTY of opportunities for someone with my skills. Actually finding the “right” position can sometimes be a challenge due to the size. I talked to a couple people and I know some of the other folks that Progress let go also talked to a bunch of people in RedHat before finding appropriate spots. You can literally interview for weeks before finding your one true spot. That’s good and bad. Good that there are a lot of opportunities, but kind of frustrating the sheer number of people you may need to talk to. That said, there are a LOT of good people that work for RedHat/JBoss. Joining a team there would really mean working with some good people. RedHat has also hired a bunch of the other engineers that Progress let go so I already would know a bunch of folks. With RedHat’s engineering HQ in Mass., they would also be able to easily offer benefits such as insurance and such, which is another positive.
3. Sopera – pretty much on the extreme opposite end of the spectrum from JBoss is Sopera. Sopera is a MUCH MUCH smaller, private company based in Germany that specializes in SOA expertise. Their stack is very similar to what I worked on at Progress, with projects like CXF and ServiceMix being building blocks for a more complete SOA platform. They provide a lot of value add on top of the Apache projects. However, they also understand and promote open source concepts very well. For example, they are a major driving force behind the Swordfish project at Eclipse. In a lot of ways, the stack at Sopera is much more complete than what we were able to provide at FUSE and that provides a bunch of new and exciting opportunities to expand my knowledge, yet also apply my expertise in new and exciting ways.

So, which direction did I chose? I ended up going with option #3, Sopera. At this point in time, I REALLY feel this was the best fit for me.

My wife kind of vetoed the independent contractor thing. With two small children (one entering his terrible twos), she wasn’t comfortable with some of the uncertainty around that option. I definitely thought it would be a fun challenge getting out to see real world scenarios and such, but the concern around the uncertainty and such is somewhat justified.

JBoss definitely had a bunch of positives, but there were a couple things that kind of bothered me. The number one issue is the size. After dealing with “large company politics” at Progress for a year and a half, and the “we wish we were a large company” politics at IONA for 8 years, I really wanted a break from that. Also, with the size of JBoss/RedHat and the sheer number and breadth of projects, it was kind of hard to feel “super excited” about any individual opportunity. In the end, I really felt that, at this point in time, a smaller company where the entire company is focused around doing one thing and doing it right was more what I was looking for. That said, I could just be repressing all the bad parts about working for smaller companies. Time will tell. Oh, and to the other IONA/Progress people that are now working for RedHat, I definitely wish them the best of luck and a big thanks to RedHat for stepping up and offering them positions that they are now excited about.

So, in the end, the Sopera opportunity really feels right for me. I get to continue to be highly involved with Apache CXF and continue to drive direction there. I’ll probably have to get more involved with ServiceMix, which is something I should have been doing anyway. I may also have to get more involved with the communities at Eclipse, which will be completely new for me. Being a smaller company, I’m also going to have to be highly involved in solving specific customer problems. That’s NOT a bad thing. Getting to see and participate in real world use cases is kind of exciting. Of course, there is certainly going to be new issues and challenges. Even negotiating terms was “interesting” due to language differences and the 6 hour time zone between myself and them. Nothing insurmountable though. Dublin was 5 hours off (most of the year) so I’m kind of used to at least that part.

I’m quite excited to see how this new chapter of my life unfolds.

It’s now been over three months since I blogged about the status of the various Java SOAP stacks and the bug counts. When I first posted it, many people considered it a “wake up call” to the projects and were wondering how the projects would respond.

A lot has happened in the last three months so I wanted to re-examine the states of the projects.

Apache CXF

The CXF team had a busy three months mostly working on fixing bugs directly reported by users. They released 2.1.8 and 2.2.5 in November and 2.1.9 and 2.2.6 in January. Between them, over 150 JIRA issues were closed. Some bugs, some new features, etc… CXF also had two books published targetting CXF users providing additional documentation and tutorial information.

Apache Axis

The Axis folks also had an exciting quarter. They released their Axis2 1.5.1 patch that fixed around 15 bugs, one of them a critical issue that was causing a lot of problems. Their most exciting news, however, was that they have been promoted to a Top Level Project at Apache. Probably long overdue, but it’s nice to see them out of the “Web Services” umbrella and out on more equal footing with the other projects at Apache. The process of getting things moved out to the new TLP areas is still ongoing, but a major “Congrats!” goes out to them for finally getting that done!

Sun Metro
Obviously the big news for Sun is that the aquisition by Oracle is now complete. Time will tell if that ends up a good thing or bad thing for the Metro folks. In anycase, they released their new 2.0 version in the last few months which includes a bunch of new things such as JAX-WS 2.2 support.

As you can see, it’s been quite a busy three months for all three of the projects. However, I’m still interested in looking at how many “known bugs” exist in the projects. As of today (Feb 12, 2010):

So, of the three projects, only CXF reduced their bug count. That said, I certainly cannot fault the Metro folks. I would definitley expect an influx of bugs after releasing any “#.0″ version and the uncertainty of the Oracle/Sun situation I’m sure put a damper on things for quite a while.

The last table in my previous post showed what percent of bugs logged recently had been fixed. If you look at just the bugs that have been logged since my previous post on Nov 5, you see:

Last time, people complained about using raw bug count numbers. I agree that raw numbers are usually not useful since projects with more users are more likely to have users that encounter (and report) bugs. Complexities of the projects are different. Features are different. How the tracking system is managed is different. Etc…. However, it is the trends that the raw numbers expose that I think is important. Bug counts going down or staying steady is good. Projects fixing a majority of reported bugs in a timely manner is good. Projects providing new releases that fix reported bugs is good.

Of course, bug counts and releases are only a couple aspects that are important when selecting a project. Features are important (after all, if it doesn’t have a feature you need, it doesn’t matter how bug free it is). Performance is important. Documentation is important. Ease of use is important. A friendly and responsive community is important. I’m sure there are lots of other reasons that people use when evaluating projects. I’d love to see CXF “on top” in all those categories, although I have to admit, I’m pretty bad at doing documentation.

I finally managed to get Apache CXF 2.2.6 and 2.1.9 released and out the door. In a lot of ways, this was a “big” release, not because of any cool or exciting new features, but due to the concerted effort of just “fixing bugs”. At the time I did the release build, there were 19 known “bugs” (couple more bugs have been logged since then), several of them blocked on third party fixes such as in JAXB and WSS4J. Getting down that low has been a giant effort for the entire CXF team. At one point about 4 months ago, we had almost 250 open bugs. Getting to the current level required a LOT of work on everyones part to dig through JIRA, write test cases, dig into with debuggers, etc… The result is definitely all positive. We’ve fixed a TON of bugs that have been outstanding for a very long time. I definitely encourage CXF users to update to 2.2.6.

While the push to reduce the bug count in CXF has been a very welcome and important step for CXF, it has detracted from the development of the new features and stuff for 2.3. 2.3 is definitely many months behind where I would have liked it to be. Now that the count is down to something reasonable and manageable, I’m really hoping to re-concentrate on getting 2.3 ready to ship. No promises though.

Claus Ibsen wrote up a nice blog post about how Apache Camel did this year using some easily obtained metrics. I thought it was kind of interesting so I wanted to do the same for CXF.

Number of posts on the users list: 6614

Number of posts on the dev list: 1661

Number of messages on commits list (svn commits and wiki changes and such): 3893

Number of JIRA issues raised in 2009: 595

Number of JIRA issues resolved in 2009: 763

Number of JIRA issues raised in 2009, but still unresolved: 51 (only 19 are bugs, 3 are bugs in JAXB where we need a new release of JAXB and 5 were logged in the last 2 weeks while most devs were on vacation, so really 11 bugs unresolved).

The JIRA stats are kind of interesting. Put in a graph:

CXF issues created/resolved graph for 2009

You can kind of see that the last 4 months or so, the CXF community really tried to go through all the old JIRA entries and resolve as many as possible. The result should be a much more stable and bug free product.

Just a week or so after the first book for Apache CXF was released, a second book now appears. Developing Web Services with Apache CXF and Axis2 (3rd Edition) is an update to Kent Ka Iok Tong’s book about Axis2, but it now covers CXF as well.

Being on holidays, I haven’t had time to look much at it (I’m only 1/4 of the way through the first book), but a quick glance through provided me a nice surprise. I kind of expected that it would be geared more toward Axis2 (since it’s an 3rd edition of the Axis2 book) with small “Now here’s how you do the same thing with CXF” type sections. However, it looks to be completely the oppossite. The initial examples and screen shots and stuff in the text is using CXF and JAX-WS stuff and then a small “Now here’s how you do the same thing with Axis2 section.”

Anyway, after the holidays, I hope to review both books in more detail.

Someone once told me that you’ll know your product is a success when someone writes a “For Dummies” book about it. Apache CXF took a step in that direction yesterday with the release of Apache CXF Web Service Development. As far as I know, this is the first published book about CXF.

What’s particularly exciting about this is that it’s not written by any committer on the CXF project. The authors and reviewers are completely independent. They decided that CXF needed a book and set out to write one. That’s quite interesting because on most of the OpenSource projects I’ve seen, the first sets of books are usually written by people actively involved in the project. The fact that this was written by actual users, not the developers working on the project, gives my some hope that it’s targeted correctly. One of the problems I’ve seen repeatedly with books written by the same developers that are writing the project code is the book gets too technical and makes assumptions about the readers that aren’t correct. The “I know this, so eveyone else must know it too” fallacy.

Anyway, I haven’t read it yet (I just bought it and am only up to page 17 or 336) so I cannot vouch for how good/bad it is yet. However, I’m very excited as this does fill a gap in the CXF offerings. I just wanted everyone to know it’s there.