CXF 3.0.0 Milestone1 is out !

CXF 3.0.0 Milestone1 has been released this week.  We have all worked very hard on getting this new major release out.

Here is what is new:

- CXF has become more modular. For example, CXF JAX-RS frontend in CXF 2.7.x or earlier has WSDL4J library dependency. Removing it completely proved very hard earlier, but Dan got involved and now the JAX-RS frontend has a minimum number of strong dependencies.

- JAX-RS 2.0 has been completely implemented. Users are encouraged to work with the 3.0.0 Milestone1, the JAX-RS 2.0 work has been completed for several months and only minor issues are expected to be found in Milestone1 - lets find and fix them all before 3.0.0 Final !

- Major WS-Security refactoring has been done, with Colm  doing a lot of work in CXF. It is mainly about the streaming features of WSS4J 2.0 supported at the CXF level, and it is going to be a massive feature for CXF WS users. CXF WS Security code will fly.

- Bean Validation 1.1 API has been wired in thanks to Andriy Redko. This is what is great about Open Source: I was not planning to do this work for 3.0.0 Milestone 1, but then Andriy offered his expert help and now all of CXF frontends, JAX-RS and JAX-WS ones can get the Bean Validation activated.

 - LocalTransport has been optimized to become much more suitable as a mechanism for the integrated testing -  this approach is superior to using mocks.

- Many other fixes, optimizations and improvements. Example, users can get their client-side auto-redirection done in a much more secure fashion.  Freeman has added an optional Swagger feature for  documenting REST endpoints. Netty transport has been added by Willem. The exceptions escaped from the native CXF interceptors can also be mapped to registered JAX-RS exception mappers which gets JAX-RS applications better integrated with the core CXF features. I just have to stop typing, so many things I'd like to mention here...

CXF 3.0.0 Milestone 1 is out and it is one more step toward asserting Apache CXF as the leading framework for the development of WS and RS applications.

Get On Board and Enjoy !

CXF 3.0 Trunk is JAX-RS 2.0 Ready

It took us some time to get the core JAX-RS 2.0 API completely implemented.

As I mentioned in my previous post the API is rich and powerful, so indeed it required quite a bit of effort to get it all supported but I'm happy to confirm that after resolving a CXF JIRA issue two days ago to do with supporting 2.0 Fluent Client API it is done now, CXF 3.0 Trunk is JAX-RS Ready.

As far as supporting new Client API is concerned, for the most part it has been implemented by delegating to CXF WebClient API, so those of you who work with CXF WebClient can continue using it, it won't be dropped. Besides, IMHO WebClient API offers a somewhat different approach toward writing a code to do with consuming HTTP services so it is good to say that in CXF we will offer several API flavors for users to experiment with.

Note that CXF 2.7.x supports JAX-RS 2.0 m10 - there are some minor differences between m10 and final 2.0 API supported on the trunk, but I'm hoping that users migrating to CXF 3.0 will see very few migration issues.

Now, as far as 2.0 API is concerned, I'd like to encourage users to actively experiment with the new features, with CXF 2.7.x and CXF 3.0.0-SNAPSHOT and report the issues if any; I'd like to thank those users who have already done so.

In meantime I will work on the proper documentation and stressing a bit the Client 2.0 API module against the early 2.0 TCK. Once this is all done we will turn our attention to getting Bean Validation feature supported across all CXF frontends.

Stay tuned !

JAX-RS 2.0 is out !

You may have already heard JAX-RS 2.0 (JSR-339) has been released. This is a very good news for Java developers building their RESTful HTTP applications and here are the reasons why.

The 2.0 API  offers a lot of new enhancements on top of already very capable JAX-RS 1.1 (JSR-311) API and spec. It has really been a very serious push to the next level across all the API and the specification text. And what is really good is that the community can now rest assured: the JAX-RS effort started by Paul Sandoz and Marc Hadley is very alive and is led by a new super team, Marek Potociar and Santiago Pericas-Geertsen who worked extremely hard to get JAX-RS 2.0 out. 

As I said the new API offers a lot of enhancements: client and server filters and interceptors, new Client API, client and server asynchronous invocation support, a lot of new context classes, new exception classes, a lot of API updates. A lot of new things to try and learn, but what I personally like most is the new asynchronous API and the fact that JAX-RS 1.1 Response class can be reused by Client API - it seems like a minor thing but IMHO it's one of the major points.

I've enjoyed taking part in the JAX-RS 2.0 development process. Talking to all the participants, 'fighting to death' on the subject of very trivial issues, running never ending threads - it has all happened and it has been great :-). As every developer out there knows sometimes one has to forget about the disappointment of having your great point of view rejected :-), and move on with the team toward making something good happen - this is what this spec effort has been about.

Talking to one of my former team leads, Bill, has been super too :-). As a side note, a lot of API enhancements have their origin in the work Bill and his team did.

JAX-RS 2.0 is out and about to take over and fly high. It is only a start, MVC support, some new useful features will hopefully and likely be in in the next major releases. Is it perfect ? Probably not - I can name few API and spec features I'm still not feeling exactly happy about, but overall JAX-RS 2.0 is great.  
In Apache CXF we are going to have JAX-RS 2.0 completely implemented by the end of the year. As it happens 2.0 server-side API is already completely implemented on the trunk. Some of the features like the integration with Bean Valdation API is required by the EE profile only but I think we can wire that into CXF too.
It is also validated against the early TCK 2.0 build (with Andrei helping a lot).

Client API is 50% done - CXF WebClient API has been enhanced to support new Client interceptors and filters, Response and even Asynchronous Invocations (with thanks to Dan).  Still some work to do on the actual new Client API. We are getting there.

So try JAX-RS 2.0 API and enjoy !

 

[OT] Apache CXF is more than just a library, you know!

Those of you living in Ireland who tune to listen to a brilliant NewsTalk team will recognize where I've got the idea for this regular, first half of the year, off-topic post :-), indeed, it is from NewsTalk being "more than just news, you know!".

So I got inspired and decided to do this short entry and suggest to you, the developers of web services, that CXF is more just a library,

It is the home, blueprint for developing the modern, secure web service applications.

On the way to making CXF JAX-RS run easily in your application container

Awhile back I posted an entry on how to get CXF JAX-RS loaded successfully within your favorite Java EE application container, and specifically within the containers like JBoss or Glassfish which have their preferred JAX-RS implementations actively supported.

I think it was a good enough initial step but it proved to be quite incomplete, with users reporting CXF failing to handle the objects of some of JAX-RS core types like Response.

In this rather technical post I will give an update on the situation.


What typically happens is that when Glassfish or JBoss loads a CXF-enabled application, the active subsystem (Jersey or RestEasy based) will still intercept the runtime  or application code doing a code like "Response.ok().build()" - this static sequence of calls will end up being processed by this subsystem which leads to a somewhat unusual case, where the CXF runtime ends up processing 'foreign' JAX-RS Response objects - attempting to cast to the CXF-aware Response object breaks the application.

So what we've decided to do now is to start working on making CXF JAX-RS completely isolated from the loaded third-party JAX-RS libraries, by minimizing and when possible completely removing the calls like "Response.fromResponse" which lead to the 3rd party subsystems intercepting the control. This makes CXF JAX-RS more robust when loaded alongside other JAX-RS runtimes, and also marginally faster - the cost of getting from the static code sequence to the actual Response builder implementation capable of producing Response is not completely negligible.

This is not possible to avoid completely - for example, you custom filter, exception mapper or indeed the user code will inevitably create a JAX-RS Response instance which will be 'foreign' to the CXF runtime.  In these cases CXF will simply copy such Responses into its own Response implementation. 

I hope it will make it very easy eventually to get CXF JAX-RS up and running in the latest JBoss and Glassfish distributions, due to it becoming effectively self-contained. Some more runtime code modifications may prove to be required but IMHO we are on the right path.

It is very well understood that for a given container it makes a lot of sense to optimize around a selected JAX-RS implementation, specifically in case of JBoss and Glassfish we are talking about well-known and recognized implementations.

This effort is all about helping those users who have decided to work with CXF JAX-RS in these containers continue doing so - this is all to it really :-).

Use SAML2 Assertions as OAuth2 Token Grants or Authenticators with CXF

OAuth2 allows third-party clients to use different types of grants in order to request access tokens. The specification defines a number of grant types to get some specific flows supported, but also allows for extensions - one can use whatever custom grant is required in a particular scenario.

SAML2 Bearer Assertion Profiles  and JWT Bearer Token Profiles standardize  two such extension grants, SAML2 Bearer Assertions and JWT Bearer Tokens grants, which can be used like any other OAuth 2.0 grants in order to request new access tokens. In addition, these documents specify how SAML2 Bearer Assertions and JWT Bearer Tokens can be used as client authentication credentials, irrespectively of the actual token grant type.

The use of SAML2 Bearer Assertions in particular is likely to get more immediate traction given that SAML2 Identity Providers are deployed in many productions, though no doubt JWT is going to be become much more visible going forward.

I think it is fare to say that it is the introduction of SAML2 into an OAuth 2.0 'space' that led some experts to start talking about the increased complexity of OAuth 2.0 compared to OAuth 1.0. One can definitely agree that working with SAML is more complex than with simple tokens.That said it is not a default token type after all - it is really about getting the Identity Providers which are already deployed be 'involved' which is always important - if that is not something that is needed for your case then no SAML2 assertions have to be used at all.

You may want to check SalesForce and PingIdentity documentation for more information on how to get SAML2 assertions utilized with OAuth2 servers.

Apache CXF OAuth2 module introduces an initial support for using SAML2 Bearer Assertions as grants and authenticators. Please check the documentation, see how easy it is to get the client code to use SAML2 assertions, start experimenting with the code and plan moving your OAuth2 project to the next level :-)

FIQL explained in JAX Magazine tutorial

JAX magazine for Java developers features articles and tutorials which can help to get the most of all the new and cool technologies and developments happening in the Java land today.

The latest issue offers, among other features, the tutorial introducing Feed Item Query Language (FIQL) and how it is currently supported in Apache CXF. Please download the issue as a PDF or get it over your preferred channel (on iTunes, etc), and see what you can do with FIQL - and provide the valuable feedback.

Enjoy!

Jettison 1.3.3 is out

Jettison 1.3.3 has been released earlier this month, please check the Download page.

This release ships a better MappedXMLStreamReader: arrays to be mapped to primitive collections in JAXB beans can be correctly processed without the loss of the data, some if its methods dealing with text will work properly as expected and the callers can identify an absolute position of the first illegal JSON character after XMLStreamException has been thrown.

As usual, I'd like to thank the users who have reported the issues against Jettison and would like to encourage to get the patches provided.

I think over the time it has become clearer to me why Jettison is still being used, at least by some of CXF users, even though such powerful and popular processors as Jackson exist. Jettison is a very lightweight library, it has just few basic STAX XMLStreamReader and XMLStreamWriter implementations: this alone is not sufficient to produce a perfect JSON. But in CXF at least Jettison can be customized a lot to make it produce if not perfect but close enough JSON sequences.

This is what keeps it visible really in CXF land at least IMHO - the fact that the users can use it to write or read simple sequences (with many JSON consumers actually expecting simple enough sequences) but also nearly completely control the way a given sequence is produced or consumed. For example, people are talking about backward and forward compatibility with respect to processing XML - same can be achieved for JSON in CXF, all without code-related changes.

This is where its niche is, a bridge between JAXB and JSON, simple to medium complexity sequences, the possibility of the easy enough customization.

If you work with Jettison: please test the latest release and provide the feedback, thanks