2014-08-29 15:09 GMT+03:00 Erik Jan de Wit <edewit@redhat.com>:

 

Other option is to have 2 jax-rs classes, but to make that work they will have to have 2 different paths. So you would have to ‘redirect’ / change the path in the servlet filter based on the accept header. Which feels like kinda of a hack to me.

While I like the above suggestion regarding the message format, couldn't we be still on the same path, and use some 'advanced' CDI injection mechanismn to inject a Version110SenderServiceImpl (or Version100ServiceImpl) ? Just curious

Right with CDI qualifiers you could select a specific version of the same implementation see SenderServiceImpl for an example of this it has all the PushNotificationSenders and selects them based on the variantType. 

And because the json in this particular Endpoint is serialised into a Map<String, Object> we don’t even have to have 2 different versions of the SenderServiceImpl or have CDI qualifiers we ‘just’ need to have a Strategy based on version that converts the Map into a Message object. 

I must say this is probably the most simple solution to this specific API change so I’m +1 on this one.

WDYT

Another option that might work out of the box would be to use the jax-rs @Consumes annotation e.g @Consumes({"application/vnd.aerogear.v101+json"}) on the service endpoints.      
So by making an abstract PushNotificationSenderEndpoint and and several PushNotificationSenderEndpointV101, PushNotificationSenderEndpointV102 with the right @Consumes annotation should work. I haven't tried it though 
 


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev