<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;">
<div style="word-wrap:break-word"><div><br></div><div>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.</div>
</div></blockquote><div><br></div><div>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</div></div></div></div></blockquote><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>I must say this is probably the most simple solution to this specific API change so I’m +1 on this one.</div><br></div><div>WDYT</div><br></body></html>