| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
- Former: Fail with Exception.
- Now: Issue a warning and fall back to default configuration profile
after verifying that sinks in default configuration profile are
correctly configured.
- Refactor: Make DEFAULT_CONFIG_KEY static.
|
|
|
|
|
|
|
|
...since it's a client that communicates with the app.
|
|
- JAXB Hack: Handle InterruptionException properly (as in [1], "Dont
swallow Interrupts")
- Mzs2MsgConverter: Rename convert(Person) to
convertReceiverPerson(Person) to emphasize that this method can only
be used to convert Receiver Persons (Reminder: Receiver Persons are
PhysicalPersons / CorporateBodies. SenderPersons can also be
Authorities)
- Mzs2MsgConverter: Remove assertion because not needed anymore.
- Refactor: Move mzs:DeliveryRequest validation out ouf augmenter and
into service.
- Refactor: Create a single entry point for validating a
mzs:DeliveryRequest.
- Remove unused imports.
- Fix log messages.
[1] https://www.ibm.com/developerworks/java/library/j-jtp05236/index.html?ca=drs-#2.1
|
|
Schema Changes:
- Remove mzs:DeliveryRequest/TnvzMetaData because all metadata fields
can be collected from DeliveryRequest and redundancy is not needed.
Fixes and Refactoring in preprocess:
- MzsDeliveryRequestValidator: Instead of returning false, throw an
exception when a condition is not met, and explain which condition
is not met / why it is not met in the exception's message.
- Integrate interface change in ConfigProfileGenerator and
DeliveryRequestAugmenter.
- Rewrite and simplify DeliveryRequestAugmenter's augmentation.
- ConfigUtil Fixes: Ensure that we do not override the wrong
parameters while merging. This error appeared in tnvz / msg client,
connection / receive timeout, key / trust store, and lax hostname
verification / trust all.
Fix Bugs in Interceptor / SoapUtils:
- Problem: DOM access and information extraction was implemented
somewhat sloppy.
- SolutioN: Change DOM access interface to access DOM more
efficiently. Add boundary checks and handle edge cases while
extracting information from SOAP Messages.
- Test those changes properly.
Testing:
- Implement Delivery Request Flow in ITEndToEndTest.
- Start application on random port instead of fixed port when running
integration tests.
- Add assertions to tests in ITMzsServiceTest suite.
Others Bug Fixes:
- ServicesConfig: Ensure that mzs service and msg service run on
different endpoint addresses (/msg and /mzs).
- DeliveryRequestBackend: Throw exception when binary message is
missing. Don't wrap the exception.
- SaveResponseToFileSink: Wrap Response in JAXB Element (otherwise,
marshaller does not recognize it)
|
|
MZS Schema Change:
- Add configuration for ForwardResponseToServiceSink
(add parameters in mzs:DeliveryRequest/Config)
- Add sink configuration in application.yaml, convert from Spring
Environment to ConfigType, and merge ConfigTypes.
- Validate sink configuration completeness.
Contract added:
- Add contract mzs2app.wsdl: This contract specifies how
mzs:DeliveryRequestStatus' and mzs:DeliveryNotifications are
forwarded to the sender application.
- Implement "ForwardResponseToService" Sink.
- Add and implement MsgResponse.sendToMzsClient() : This is a somewhat
unfortunate solution because, intuitively, sending should be done by
it's caller, the "ForwardResponseToService"-sink. However, this
solution prevents differences between msg:DeliveryRequestStatus and
msg:DeliveryNotification (and code that needs to handle differences,
i.e. sending) from sprawling outside of the respective MsgResponse
derivatives. We move the entire "send" process into MsgResponse to
prevent a hard-to-maintain "if type == notification then do x else
to y" construct in ForwardResponseToServiceSink. Otherwise,
introducing the MsgResponse wrapper was pointless.
|
|
- Add zuse2app.wsdl contract.
- Add MsgResponse as an type-agnostic view for DeliveryRequestStatus
and DeliveryNotification messages. Reason: Both DeliveryNotification
and DeliveryRequestStatus messages have similar fields and need to
be treated similarly (e.g.: receive from msg service, store to
repository, verify signature, store to file...). In order to prevent
duplicated code, the wrapper interface provides a type-agnostic view
onto these messages for depending components to operate on.
- Add MsgResponseHandler interface; decides how to process
MsgResponse. Also implement this handler with a multi-threaded
single-node implementation.
- Add MsgResponseSink interface; decides how to archive MsgResponse.
- Implement and test SafeResponseToFileSink.
Change Identifier for MsgResponses:
- Before, DeliveryRequestStatus and DeliveryNotifications had their
own repositories. Now, both types are stored in the same repository
(the MsgResponse repository) to streamline the handling of
MsgResponses. We need to change the identification of MsgReponses,
otherwise the identifiers (AppDeliveryID) clash.
- MsgResponses are not identified by:
<AppDeliveryId>+<typeSpecificSuffix>
- Rewrite StoreSOAPInterceptor to accommodate fact that, both
DeliveryRequestStatus and DeliveryNotification messages have
different IDs upon storage / retrieval.
Restructure packages and components as follows:
- client: All components that are involved when consuming a web service.
- process: "fabric" of MoaZS; contains business logic that
orchestrates back-end tasks of MoaZS's operational services, e.g.:
by processing a delivery request.
- service: Implementation of MoaZS's front-end services.
Refactoring:
- MoaZSException: Remove unused fields. Before: Store mzsrequest,
tnvzresult, msgrequest and msgresult as members. Now: Only keep the
fields that are needed later, e.g for generating a
msg:DeliveryRequestStatus element. Add copy constructor to Builder.
- Put storage of byte[] into a dedicated "BinaryRepository". Reason:
This was useful in a former design. Now it's not really needed
anymore.
- Put "create Endpoint" code into EndpointFactory. Reason: Eliminate
duplicated code when configuring a service.
Testing:
- Activate Stacktraces in surefire.
|
