search

ECF / JaxRSProviders

Remote Services distribution provider based upon JaxRS. Includes imples based upon Jersey and CXF.
Apache License 2.0
13 stars 19 forks source link

Restore JAX-RS component binding #28

Closed modular-mind closed 4 years ago

modular-mind commented 4 years ago

I'm wanting to add JAX-RS filters, resolvers, etc. to configure the REST calls. I noticed that the DS bindings for these have been removed at some point, and I was wondering if it would be ok to add them back in. This PR adds them back in for Jersey, but I could do the same thing for the CXF client if needed.

I also added some logic in the JAX-RS client to skip the ContextResolver registration if one has been added through DS. It looks like if there are multiple resolvers for ObjectMapper then there is no way to prioritize one over another. I'm wanting to supply my own ObjectMapper to customize the Jackson data binding.

modular-mind commented 4 years ago

These changes work fine for me. But I'm actually going down a bit of rabbit hole thinking about scoping of these things. Ideally each REST service would be able to contribute its own ObjectMapper instance at least. We could allow ObjectMappers to be contributed by DS (instead of a ContextResolver) and then have the current ObjectMapperContextResolver decide which to return, but I'm not sure of the best way to map between requests and ObjectMappers.

I'll think about it some more, and if you have any ideas let me know.

modular-mind commented 4 years ago

Btw, for reference there is the OSGi JAX-RS Whiteboard Specification that deals with extension filtering:

https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#service.jaxrs.extension.services

Of course this is a big can of worms that I'm not sure I really want to get into. I think for now the ability to replace the ContextResolver works, but it's something to think about longer term...

scottslewis commented 4 years ago

You said:

We could allow ObjectMappers to be contributed by DS (instead of a ContextResolver) and then have the current ObjectMapperContextResolver decide which to return, but I'm not sure of the best way to map between requests and ObjectMappers.

Each request (i.e. each service call) will need a separate ObjectMapper instance? or it a separate instance for each remote service instance?

scottslewis commented 4 years ago

Btw, for reference there is the OSGi JAX-RS Whiteboard Specification that deals with extension filtering:

https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#service.jaxrs.extension.services

Of course this is a big can of worms that I'm not sure I really want to get into.

That definitely makes two of us.

I think for now the ability to replace the ContextResolver works, but it's something to think about longer term...

Yes. I would like to have some discussion about the use cases that need to be supported, their prioritization...and how best to support them (e.g. customizing jaxrs distribution provider via jaxrs extension mechanism, vs. extending distribution provider impls, vs. introducing new distribution providers...e.g. based upon jaxrs spec-compliant impls).

I'm of the view that the OSGi spec authors and large member companies can sometimes be a little overzealous in their introduction of 'standardized' ipc (for plenty of obvious commercially-driven reasons). What I like about the RS/RSA specs is that it leaves the distribution provider and discovery providers (and serialization/transport) largely unspecified and so able to accommodate moving remote services around to fit different use cases without having to be bound to one protocol/transport+serialization format.

modular-mind commented 4 years ago

Each request (i.e. each service call) will need a separate ObjectMapper instance? or it a separate instance for each remote service instance?

The use case I was thinking of is that each REST service might need it's own ObjectMapper. For example, the SpaceX Launch Service needs a SnakeCase naming adjustment or perhaps a specific Jackson deserializer, while another REST service needs some other configuration. Currently all REST service clients will need to share a single ObjectMapper, etc.

I would imagine that an ObjectMapper list would be created at startup and then that list would be re-used as service requests are made, so definitely not an ObjectMapper for each request.

But having said that, I think it's good for now to have a single custom ObjectMapper that can be added to replace the default one. That will allow me to move the SnakeCase configuration out of the JAX-RS POJOs into the ObjectMapper. Perhaps we can keep extension filters in mind in the future if that's a requirement. I don't think it's worthwhile doing the work now in anticipation.

modular-mind commented 4 years ago

Btw, it would be great to get a new build with these changes. I'd like to publish an article about using JAX-RS extensions with the Jersey Client, and I want readers to be able to pull in the latest version through the p2 repo. Thanks!

scottslewis commented 4 years ago

Just now I've released version 1.13.8.