| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
- Problem: Apparently I used the wrong executor when supplying the
backend tasks via CompletableFuture.supplyAsync(). This method
relies on ForkJoinPool.commonPool(), and threads in this pool are
not configured correctly?
- Solution: Use spring-boots auto-configured TaskExecutor.
- More Information on this issue can be found here:
https://issues.apache.org/jira/browse/CXF-8100#
|
|
|
|
|
|
|
|
- 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
|
|
- Add loggin dependency.
- Enable Message Logging for Services and Clients.
- Add message logging config + examples to application.yaml
|
|
|
|
|
|
|
|
- Service Timeout : Add service timeout to mzs schema (DeliveryRequest
/ Config), application.yaml, convert service timeout from spring
environment to Config, and merge service timeouts in Configs.
- Handling of Asynchronous DeliveryRequestStatus: Move "Applying
Response Sinks" from backend into dedicated component
"MsgResponseSinkHub" and integrate SinkHub into MzsService (apply
sinks to asynchronous responses).
- Remove line breaks in SignatureVerifier's log statements.
- Revise documentation of parameters in application.yaml.
|
|
Reason: MoaZSException (and: its builder) were used to collect
intermediary results while stepping through the delivery request
backend. These results were needed to generate meaningful responses
towards the sender application in case of error. However, the builder
sprawled over too many interfaces (e.g. DeliveryRequestBackend and
TNVZHelper) and it became difficult to understand from where
intermediary results originated.
Solution: Put MoaZSException on diet:
- Remove all DeliveryAnswer fields from MoaZSException and refactor
code base to ensure that the removed fields get sourced by other
means.
- Remove Builder since amount of parameters is manageable.
Refactor DeliveryRequestBackend:
- Instead of passing down the builder and using MoaZSException as the
only source for intermediary results, we collect available results
at the outermost stack frame (DeliveryRequestBackend.accept) and
only retrieve results via exception if those results appear
somewhere down the stack frame (E.g. PredviceNoteSent). We collect
available results with the "fallbackAnswerBuilder" and switch to the
msg client response, once received.
Refactor MsgResponseBackend:
- Handle cases (response missing, binary response missing) properly.
- Integrate changes from MsgResponse.generateError()
Refactor TVNZHelper:
- Remove MoaZSExceptionBuilder from all interfaces.
Refactor MsgResponse.generateError:
- Change interface such that it's more intuitive.
- Implement NotificationResponse.generateError.
- Implement RequestStatusResponse.generateError.
Others:
- Replace all invocations against MoaZSException.Builder.
|
|
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.
|
|
Reason:
- Interfaces with a single method can be replaced with
interfaces from java.util.function.
- Less interfaces = less code = less maintenance!
- Spring can inject beans by name so we name dependencies correctly
to prevent ambiguity.
Others:
- Rename process to backend since backend gives a better description
of its components.
|
|
- Reason: Components, which rely on one of those, usually also rely on
the other, so merging them reduces amount of dependencies.
- Frame operations in DeliveryRepository API as "store" and "retrieve"
operations.
- Rename: Convert *Id in local variable names to upper case.
|
|
- 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.
|
