FWIW,
Another approach is to use OSGi Remote Services [1]...specifically ECF's
JaxRS distribution provider impls [2]. Remote Services Admin creates a
proxy for the remote service and this proxy is/may be treated as a local
service by SCR.
The ECF impl allows pluggable distribution providers, and the repo here
[2] uses Jersey or CXF along with the JaxRS-standard annotations + the
OSGi standard remote service properties. See examples and tutorials [2].
Although remote services wasn't built with JaxRS transport specifically
in mind, it does IMHO integrate naturally with service registry and
SCR...especially WRT service discovery, proxy creation, API versioning,
and service dynamics.
ECF's impl allows the creation of new distribution providers, or
extension/customization of the existing providers (using JaxRS extension
mechanisms and/or Jersey or CXF extension mechanisms).
For more info please see [3]
Scott
[1]
https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html
[2] https://github.com/ECF/JaxRSProviders
[3] http://eclipseecf.blogspot.com/2019/11/ecf-3146-released_2.html
On 11/20/2019 8:29 AM, Oliver Schweitzer wrote:
I understand where you’re coming from.
So Christian is basically right, the Jax-RS Whiteboard, like the whole DS
approach, feels somewhat like the future - a clean, elegant form of building
dynamic modular, standards-based services with Java. For me, the Wow! happened.
But it’s only almost, not quite there yet, in terms of working, understandable
but, and maybe that’s the point, more feature-complete or complex examples or
projects, or even ready-made features. Not snippets.
For my own “enterprisey" setup I believe I have everything working I need right
now - e.g. Cors, Jaas, Serialisation, OpenAPI - but a lot of that I had to write
myself or scrounge from all over the 'net, and the “fluency” and the feeling of full
control isn’t yet there for me.
What made things easier for me was that I tried to use an “almost pure” Jax-RS approach
from the beginning, even before moving to Karaf. Migrating from a proprietary, custom CXF
setup to this brave new world might well be a challenge and involve a whole lot of
"basic research" right now.
As for me, a new REST Service I’d gladly build with DS/Jax-RS Whiteboard again,
and for an existing, proprietary system with a long enough expected lifetime
I’d give a serious look at migrating.
Best regards,
Oliver
On 20. Nov 2019, at 15:53, Ranx0r0x <[email protected]> wrote:
Christian,
That's probably not going to happen as we migrate over with all the plugins,
providers and interceptors setup in the current environment to a better more
decoupled design but still using CXF. I'm not even 100% positive I'm free of
SOAP endpoints yet.
We a number of endpoints with different authentication mechanics and
different logging requirements and that's why I'm trying to find a good way
to implement and share bus configurations. I have one way of doing it via
Blueprint that works and with the DS JAX RS I'll be working today on seeing
if I can't create a standard mechanic for it that might have a number of
defaults that can be set via cfg much like PAX JDBC. As an example, being
able to enable/disable logging at the in/out interceptors would be nice.
JAAS Authentication may be another. Haven't cracked it open yet.
But I can easily bootstrap a similar component for SOAP if I needed using
the same interface.
I'm certainly wiling to be convinced that JAXRS Witeboard is more elegant if
I see some compelling examples showing different security and logging
configurations that snap into place for different use cases. Then I can sell
it to my colleagues as a better way of refactoring the project.
Honestly I've seen snippets and some examples of JAX RS Whitebaord but can
say I never went "Wow! That's so cool. I have to use that...." That might be
due to my lack of exposure or just that the samples weren't particularly
overwhelming.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
