commons-xua handling

[T. Papke]

Hello everyone,

with the last changes to 5.0-m2 the ipf-commons-xua was probably dropped by accident, currently there is only a swiss xua handling in SwissEpr.

I would vote to also bring back a “simple” Ihe xua handling. 

I was already in a first exchange with Dmytro about some ideas:

A) Dmytro bring the following first proposal. 

1 eliminate WsAuditDatasetEnricher.NOOP.

2. introduce a non-Swiss-specific implementation instead of NOOP as default.

3. leave a Swiss-specific implementation as plug-in.

4. redefine the field AbstractAuditInterceptor.wsAuditDatasetEnricher as final, because it is hardly conceivable that you want to dynamically readjust something in a short-lived interceptor.

Advantage: Xua is included by default without an extra module
Disadvantage: Noop would no longer exist

Proposal 2:

1 Reactivate the ihe-commons-xua module

2 Stay with the WsAuditDatasetEnricher Interface  in commons-ws

3 Provide a commons-ihe-xua implementation of WsAuditDatasetEnricher  and one in a swiss specific module

Advantage: adaption similar to the way in ipf 4.x

Disadvantage: at least 2 modules with 1 class each

Proposal 3: 

Include the BasicXuaProcessor in ihe-commons-ws, but WITHOUT the serviceloader definition. This means that if someone wants to switch from Noop to basic-Xua, the ServiceLoader definition must be created in the application under Meta-Inf.

Advantage: One Maven module saved

Disadvantage: Existing applications must be adapted

What are your opinion on this topic?

My preference would be option 2 :-)

Best regards,

Thomas

[Dmytro Rud]

Thank you Thomas

Let us make the type of WsAuditDatasetEnricher a parameter in the AuditContext, same as we did for transmission protocol, message queue, etc.  This would provide a uniform configuration mechanism, and even the possibility to have different enrichers in different contexts.

Best regards and have a nice weekend

Dmytro

--
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/CADbaft81E56OqtYKBWirUQKJj%2BJq%2BsymtBTgsZmN3Buf%3D74dXQ%40mail.gmail.com.

[Dmytro Rud]

...and no additional maven artifacts will be necessary.  There will be simply three classes somewhere in commons-ihe-ws: NoOpWsAuditDatasetEnricher, VanillaIheWsAuditDatasetEnricher, SwissEprWsAuditDatasetEnricher.

[Dmytro Rud]

...implemented and documented on https://oehf.github.io/ipf-docs/docs/migration-5.0/.

[Thomas Papke]

Hi Dymtro,

looks like a good solution for me. 

Thank you,

Thomas

[Dmytro Rud]

Just committed a FHIR counterpart of it, +documentation.

Best regards

Dmytro

To view this discussion on the web visit https://groups.google.com/d/msgid/ipf-dev/80c35475-bdf7-4001-b4ff-532522f32f7an%40googlegroups.com.