[PROPOSAL] Use CXF for the REST API

[Ciprian Ciubotariu <ch...@gmx.net>]

The last few weeks I've been struggling to integrate the current brooklyn-
rest-server using jersey-1.x into the karaf OSGi container. My goal includes 
separating the REST API from the Web GUI as separate features instead of 
programmatic insertion of resources as filters into the brooklyn-jsgui war. 

On the OSGi path we have to switch to CXF now or later in the future, so I 
wanted to ask for the opinion of the community earlier.

Here are a few reasons for my proposal:

1. it's open-source AND free software, maintained by Apache, while Jersey is 
under the control of Oracle

2. high compliance with JAX-RS 2.0 TCK [1]

3. this migration will include the switch to JAX-RS 2.0

4. CXF is widely used in the OSGi world, and is geared towards integration of 
REST resources and microservices


Any thoughts on doing this switch for the current brooklyn-launcher?


Thanks,

Ciprian




[1] http://cxf.apache.org/docs/jax-rs.html#JAX-RS-2.0Final

Re: [PROPOSAL] Use CXF for the REST API

[Alex Heneveld <al...@cloudsoftcorp.com>]

Cipi,

+1 ... but with some caveats

I've not heard anyone profess undying love for Jersey, and CXF sounds 
like it has a lot going for it.  I also like the sound of the modular 
way of serving resources.

But FYI the REST resources are added using 
`ResourceConfig.getSingletons().add(...)`, not filters.  There are quite 
a few filters added for authentication, gzip, and state checks (e.g. to 
discourage POST to a STANDBY server).

I assume with this proposal all the same behaviours can be applied, right?

We also have downstream projects which provide overlaid WAR files, and 
which use the BrooklynLauncher.webapp(...) method to add custom WARs.  
It would be nice if we could continue to support all this, at least as 
legacy ie with a deprecation warning wherever there is a new better 
way.  There is pretty good test coverage for these behaviours so if the 
tests work as is we should be okay.  If we do have to break any of those 
I don't think it's the end of the world but we MUST clearly document it.

Final consideration is the way that JSON serialization, Swagger, and the 
Java REST Client package work.  They may need changes in a shift from 
Jersey to CXF (although maybe it will all just work). Again I think we 
have good test coverage.

Best
Alex


On 24/11/2015 18:13, Ciprian Ciubotariu wrote:
> The last few weeks I've been struggling to integrate the current brooklyn-
> rest-server using jersey-1.x into the karaf OSGi container. My goal includes
> separating the REST API from the Web GUI as separate features instead of
> programmatic insertion of resources as filters into the brooklyn-jsgui war.
>
> On the OSGi path we have to switch to CXF now or later in the future, so I
> wanted to ask for the opinion of the community earlier.
>
> Here are a few reasons for my proposal:
>
> 1. it's open-source AND free software, maintained by Apache, while Jersey is
> under the control of Oracle
>
> 2. high compliance with JAX-RS 2.0 TCK [1]
>
> 3. this migration will include the switch to JAX-RS 2.0
>
> 4. CXF is widely used in the OSGi world, and is geared towards integration of
> REST resources and microservices
>
>
> Any thoughts on doing this switch for the current brooklyn-launcher?
>
>
> Thanks,
>
> Ciprian
>
>
>
>
> [1] http://cxf.apache.org/docs/jax-rs.html#JAX-RS-2.0Final
>