interceptors

18 views
Skip to first unread message

Dmytro Rud

unread,
Feb 23, 2022, 4:19:42 PM2/23/22
to ipf...@googlegroups.com
HI all

org.openehealth.ipf.platform.camel.ihe.ws.AbstractWsEndpoint overrides the default method org.openehealth.ipf.platform.camel.ihe.core.InterceptableEndpoint#getCustomInterceptors with a completely different return type (why does Java allow this?!) and different meaning, and therefore it is impossible to use IPF interceptors (org.openehealth.ipf.platform.camel.ihe.core.Interceptor) in Web Service transactions.  What do you think, would it be OK to break the backward compatibility by renaming the overriding method in AbstractWsEndpoint e.g. to getCustomCxfInterceptors?

Best regards
Dmytro

Christian Ohr

unread,
Feb 24, 2022, 3:46:53 AM2/24/22
to ipf...@googlegroups.com
Hi,

AbstractWsEndpoint does not implement InterceptableEndpoint. That's why the compiler doesn't complain.

Still, the identical name is obviously confusing. So I would agree to add a method with the name you proposed and adapt all callers in IPF, but if possible I would prefer to just deprecate the existing method for a release or so before removing it. 

The other question is why WS endpoints do *not* implement InterceptableEndpoint (like MLLP and FHIR endpoints do). Probably, back then, we felt that CXF's interceptor framework is good enough and it's unlikely to move away from CXF, so we didn't put another abstraction on top of it. Is there a good reason for changing this now?

regards
Christian


--
You received this message because you are subscribed to the Google Groups "ipf-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ipf-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ipf-dev/CAHh9K-%3D9y0NSJkaWJhcsnKLvWJfSJhu%2BPJBT9hsybyUAPn6JwQ%40mail.gmail.com.

Dmytro Rud

unread,
Feb 24, 2022, 6:02:24 AM2/24/22
to ipf...@googlegroups.com
Hi Christian

HPD defines sorting and paginating of search results (see https://github.com/oehf/ipf/issues/381).  My idea was to implement these features in corresponding IPF interceptors of Iti58Endpoint.  CXF interceptors would be a wrong place for that.

Implementing only one feature of these two were easy (this is what you can see in my commits so far), just like it is done in Hl7v3ContinuationAwareProducer/-WebService.  But the combination of two features makes it look weird.

Ok, for now, I will take what I can, because I need the features urgently.  But then -- yes, let us deprecate+release+delete, as you proposed.

Thank you and best regards
Dmytro


Reply all
Reply to author
Forward
0 new messages