I’ve had the WORST luck with return flights lately. My last three trips ALL had issues with the return flights.
It started over Christmas for our flight back from Ft. Lauderdale. I got an email the night before saying our flight was canceled. That’s never a good thing. I called JetBlue and they did get us on a flight 3 hours earlier. However, when we got to the airport, that flight was delayed. We ended up taking off roughly the same time as our original flight. Basically, had to spend a few extra hours in the airport with a 2 year old and a 6 month old. In this case, the cancellation/delays were weather related (huge snowstorm in the northeast) so not really something that the Airline could be faulted for.
The flight back from The Server Side Java Symposium in Vegas on the 20th also ended up being delayed. I had specifically grabbed the 11pm red-eye from Vegas to Boston so that I could be back home by 9am on Saturday to take my kids to swimming lessons. However, the plane had a “water leak in one of the Galleys” and it didn’t end up taking off till about 1am. Didn’t get back in time, kids missed their lesson. 🙁 To JetBlue’s credit, they DID send out a travel credit due to the delay not being weather related.
Then, last Friday, I was flying back from Emerging Technologies conference in Philly and, once again, delay. I had planned to get back home right at 8:30 which is when my kids go to bed so I could say good night. That didn’t happen. This was a “two part” delay. The plane was late getting there due to weather conditions someplace. However, even after it got there and we boarded, we ended up sitting for another half hour or so because the “safety seal” on the Fire Extinguisher has broke and we had to wait for maintenance to swap it out. Ended up getting home at 10:15. Not a thing from US-Air, possibly because the original delay was weather related.
So, if you are planning to travel someplace, make sure you and I aren’t on the same return flight. 🙂
This has definitely been an exciting couple of weeks for Apache CXF. First, we finally got 2.2 out the door which significantly increases interopability with WCF and others, especially in regards to WS-Security type things, as well as some initial JAX-RS 1.0 API’s.
While that was being voted on, we FINALLY got access to the JAX-RS TCK. Thus, we can start getting it certified for JAX-RS in addition to JAX-WS. Still quite a bit of work to do to get it done, but at least we now have the tools.
Then, JOnAS becomes J2EE certified using Apache CXF for their JAX-WS implementation. I didn’t even know they were using CXF until I downloaded it to try it out. That was a pleasant surprise. Nice job to the whole JOnAS team. Getting the J2EE5 certification is NOT easy.
Finally, today, RedHat has announced that they are going to start supporting CXF as a core component of JBoss. This is a huge announcement. The JBoss team has a lot of expertise in the space. They have a very large and very complex test suite that goes WAY beyond the JAX-WS TCK. They also have quite a bit of expertise with interop testing with Microsoft and others. This is all very valuable experience that I hope we can leverage to improve CXF.
I’ve already seen some results from this. The RedHat folks have submitted several patches to CXF to fix various issues. They’ve also logged some other issues that their test suite has picked up and they are working on fixes for those as well. None of them have earned committership on CXF yet, but if they keep up the excellent work, I except it will eventually occur.
Anyway, this has been an EXCITING couple of weeks for CXF. It’s great to see years of hard work being validated by being used extensively.
Last week, the JOnAS team announced their latest 5.1 milestone release, M5. What is most exciting about this is that this version passes the entire J2EE5 certification suite. Part of the J2EE5 suite requires a JAX-WS stack. What stack did they choose? Apache CXF.
I’m pretty excited about this. JOnAS marks the third J2EE app server (that I’m aware of, please let me know if there are others) to certify with CXF. Geronimo and Pramati already certified with CXF. I also know JBoss is hard at work getting CXF embedded into JBoss (they keep bugging me with patches, which is great. Keep it up guys!).
The fact that these projects are looking into CXF to meet their JAX-WS requirements is a testament to the quality and complete implementation that CXF delivers. From day one, JAX-WS compliance has been a priority for CXF. Add to it the ease of embedding and the support provided by the excellent CXF community as well as by the FUSE team at Progress and CXF is a very smart choice for JAX-WS.
Finally managed to Apache CXF 2.2 out the door. Definitely took a bit longer than expected, mostly cause I COMPLETELY underestimated what a PAIN doing security stuff is.
Normally when working with WebServices, if something goes wrong, it’s very easy to use Wireshark or similar to grab the SOAP message and examine it to see if the problem is related to the message or not. With the various WS-Security standards, that doesn’t work very well. The captured messages end up encrypted. Thus, looking at the raw messages doesn’t help too much. I ended up writing several extra helper things to help me decrypt the messages to see what they really look at.
The other issue I ran into is security people tend to NOT give useful error messages. Then tend to think it’s a security violation or similar to say “the provided X509 key was not trusted” or similar. Instead, you get a “Security tokens could not be processed” type fault. Yea, that helps. Which token?
The GOOD news is that CXF 2.2 now passes the Microsoft Interop PlugFest tests for WS-Security 1.0 and 1.1, WS-SecureConversation, and the client side portion of WS-Trust 1.0 and parts of WS-Trust 1.3. That’s a huge step forward in interopability with WCF. There is still a lot of work to do and a bunch of performance tuning is needed, but this is a huge milestone representing a ton of work.
Anyway, major thanks to the entire CXF team for helping to get this out.