Friday, February 26, 2010

Higher and higher we are gonna take it...

I've been thinking today how to title this blog entry. First I typed "Sky is the limit" but spotted this page. Then I typed "The best is yet to come" but surely I found this one. So I ended up borrowing a phrase from the Killer's Confessions of the King and stopped being melodramatic.

It is the time to seek a new beginning and reflect a bit on the last 5.5 years I spent with IONA and Progress Fuse.

IONA was the company where I grew up as a software engineer. I was fortunate to work from the day one with the best engineers one can dream of working with, some of them being very well-known in the industry and some not but it is them from the latter group who brought me to that stage where seeing a failing system test passing was the most satisfactory thing one can imagine. It was the company where one could learn to compromise and move forward. And we had quite a few laughs all the way ! And VisIONAry t-shirts were the 'best' in the industry :-).

Working for IONA was the real thing. I enjoyed it. But I have to admit working in Progress Fuse on the CXF JAXRS implementation was probably the best part. It was the 'working on the line' kind of experience, the bleeding edge, it had it all ! Working on the open source projects gives one a chance to be a coder and an architect and lets the one to talk to users on the everyday basis. I'm not sure what can be better, as far as the software engineering is concerned.

Now it is time to think. Listen to U2. Start updating my CV. Visit London next week and hope Arsenal will not lose again (good we bought the city break package the previous week :-) as I'm feeling a bit frugal at the moment :-)) Continue supporting CXF users. And seek the new beginning.

Stay tuned and have fun !

Wednesday, February 17, 2010

Use your favorite Atom reader to view CXF logs

Andy Michalec and myself have worked recently on the Atom-based logging feature. Andy has implemented all the base classes and a push-style feature as well as wrote the initial draft describing how the push-style logging works. Myself has contributed recently by adding the initial code for supporting a pull-style logging.

Here is some more information about these features. They haven't made it into 2.2.6 nor will they make it into 2.2.7, etc but rather stay on the 2.3-SNAPSHOT trunk given that their code has been moved from the jaxrs frontend to a new rt-management-web component available on the trunk only.

I reckon the push style feature is already quite functional, you can try it by downloading a 2.3-SNAPSHOT and 'attach' AtomPushBeans to your jaxws or jaxrs endpoints by listing the loggers used by your code, as documented on the wiki. You may also find these links of interest :
beans.xml
and JAXRSAtomLoggingPushSpringTest, plus non-Spring JAXRSAtomLoggingPushTest and batch logging.properties. You can have log entries wrapped in a number of ways, as feeds or entries, with the content being added as an explicit entry content or an entry extension. Processing such entries is easy on the client side, with CXF you can do xmlSource.getNode('atom:entry/atom:content/*', LogRecord.class) or xmlSource.getNodes('atom:feed/atom:entry/atom:content/*', LogRecord.class).

Before actually moving to describing the pull-style feature, I'd like to mention that CXF can transparently ensure that Log4J or SL4J events can be captured back into JUL log records so you can get non-JUL records pushed/pulled as well.

Now, just today, I've finalized the first cut of the pull-style logging feature and I'm actually quite excited with the fact I was able to get a link to an endpoint-specific log feed from the CXF services page and see the list of log entries in Firefox, IE and a standalone Atom reader, by traversing to individual log entries (not in IE though which does not seem to recognize alternate links). Give it a try please, you actually might like it and it is very easy to try :-) !

Have a look at this beans.xml (see an atomPullServer bean which 'attaches' itself to a 'resourceServer' endpoint and relies on an 'atomServer' endpoint to expose the log entries) and the JAXRSAtomLoggingPullString test (see testFeed()). You will also need to add a dependency on the rt/management-web.

Some more details about the AtomPullServer. By default it is set to display 40 entries per page and keep 500 records in memory. It uses 'previous', 'next', 'last' and 'first' links to let users traverse across the whole range. The problem here is that I don't know of atom readers supporting these link types, let me know please if you do. Perhaps you do a simple atom browser yourself or easily deal with these links programmatically. May be we even add a basic browser in CXF over time.

You can inject into it a ReadWriteLogStorage implementation which can be used to offload the records to the external storage and persist them after restarts. Or just register a ReadOnlyLogStorage if you do not want your logging runtime to generate duplicate records if they're already being saved to an external file. At the moment, the latter storage requires a bit more effort as you'd need to write a file parser but it's doable and we may add few helpers later on. ReadOnlyLogStorage relies on the SearchCondition, stay tuned on the updates about using it in a regular JAXRS application code. Note that even if you already log to a file, you can still use the AtomPullServer to capture the most important log entries, there will be few of them in a healthy system so you can probably just set the max in memory size to 1000 and not worry about reading the same events from a file...

So this is what we have at the moment, give it a try please and help us to improve this feature.

Enjoy !

Tuesday, February 9, 2010

Support for JMS in CXF JAXRS

One of CXF JAXRS users have asked about the possibility of supporting JMS for a given JAXRS resource be able to get data over HTTP and JMS.

CXF has been designed from the ground up to support multiple transports so it was very easy to ensure CXF JAXRS could get the messages from JMS. Please see this beans.xml, it is just a matter of adding a transportId attribute to a given jaxrs:server endpoint, so if you have say a single service bean shared by both http and jms aware jaxrs endpoints you have multiple channels supported.

Now, you may ask, what is it all about ? JAXRS is about helping users to build HTTP-based RESTful services ? What about a "transport independence being a bug but not a feature" thing ?

I guess I could've said that REST is not about using HTTP, but it is just that HTTP, being the transport/application protocol of the WEB, is firmly associated with REST.

What really matters IMHO is that CXF JAXRS users will be able to see their 'investment' in JAXRS growing up. They've chosen to structure and annotate their resources in a way which makes it easy to expose them as RESTful services and being able to get data from different channels by relying on the underlying runtime is a good thing.

One of the reasons behind the 'longetivity' of SOAP is that users can get SOAP messages from JMS, in other words, they can easily tap into all those MQ stores with the help of the runtime.
Of course, one well-accepted alternative would be to use a routing engine such as Camel which would delegate from a jms channel to a given jaxrs endpoint. CXF gives you another alternative now.

What is common between CXF and Microsoft WCF

This morning I've read the interview with Don Box (thanks to this blog entry). I'm kind of unhappy with Twitter 'hijacking' a lot of people like Don expressing their thoughts aloud, I like reading the blogs, I can not get a lot out of Twitter one-sentences. I was 'following' Don since him contributing to his MSDN COM column, I wish himself and others could still find some time and blog...

So back to the interview. Here is what I liked most. Stefan asks :

" What is Microsoft doing from your perspective with regards to REST support? Do you see the two worlds coexist? Which role does which one play?"

Don replies and finishes with :

"One of the interesting things about Microsoft that took me a couple of years to understand was there is no place for religion in products. We build products for lots of different people and if someone wants to do REST, I want them to love our stuff. If someone wants to do SOAP and WSDL, I want them to love our stuff. Basically, it's our job to allow our customers to do what they want to go do with their software and the easier we can make that, the better. "

+1. This is what it is all about. This is what CXF is about. I love working on the CXF JAXRS project, JAXRS is a fantastic spec. I've also had some great experience in interacting with (IONA) customers (though mostly indirectly by fixing bugs :-)) who continue building advanced SOAP services even today. In CXF we are trying hard to ensure users can get the best of their chosen technologies/approaches, by combining them if needed.

I also liked how Don was talking about Mark Baker. In fact I was quite fortunate to have a long exchange with Mark where I was asking him a lot of newbie questions, it can even be found at www-archive@w3.org.