Middleware that allows a sender application to send delivery requests to delivery services https://git.egiz.gv.at/moa-zs/atom?h=master 2020-03-03T07:53:43+00:00 2020-03-03T07:53:43+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2020-03-03T07:53:11+00:00 urn:sha1:260200a55c07a9a5a8beab70dcf1980e522c438b 2020-02-18T13:05:18+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2020-02-18T11:19:01+00:00 urn:sha1:8400a1f99e7377e164a0d995359ff8c00a52c4e2 - Fix: Parser Error that occurs when MOA ZS goes into service timeout. - Fix: Improve exception handling on MOA ZS Async. - Before: When MOA ZS processes delivery request but hits a timeout, MOA ZS would answer syncronously to the Sender app and forward the result assynchronously at a later point. If an exception were to occur after the timeout, MOA ZS would swallow this exception. - Now: If an exception occurs, MOA ZS converts the exception into a response and hands it over to the sink hub for proper processing of the event. 2019-12-09T09:25:02+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-12-09T09:25:02+00:00 urn:sha1:1d2aafe0cd6607a48d880c007881768079e49060 - Handle InterruptedExceptions as discussed in https://stackoverflow.com/questions/3976344/handling-interruptedexception-in-java - Remove unused imports. 2019-12-06T12:18:12+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-12-06T12:18:12+00:00 urn:sha1:ff1e38bfa954dd747a5ff185dfe51c120d5ab5e7 - Before: Upon receipt of a message via the msg/ endpoint, MOA ZS would immediately acknowledge the receipt without verifying that the message was successfully processed by the backend. - Now: MOA ZS receives a message via the msg/ endpoint, forwards it to the sinks, and acknowledges the receipt if and only if the processing succeeded. 2019-12-03T08:08:44+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-12-02T13:26:42+00:00 urn:sha1:8799a27e8d73c5e079d549f6d76abf861d75ee9e - Problem: I fixed CompletableFuture.*async within the DeliveryRequest flow, but forgot to do the same for the DeliveryRequestStatus / DeliveryNotification flow. - Solution: Ensure that all CompletableFuture.*async() invocations have Spring's task executor attached. 2019-11-29T14:56:44+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-11-29T14:56:44+00:00 urn:sha1:6dbe979e0b6bd6236db304b034ad592a4aeacabc - Refactor: Replace createSoap1{1,2} with create{Tnvz,App,Msg}Client. Configure each method with zusespec's specific parameters. Reason: Each service requires different parameters (e.g. with / without MTOM? soap11 / soap12? store responses in binary respository - yes/no?). These parameters could be placed in the client configuration of application.yaml. Since the parameters are tied to zusespecs, they do not need to be configurable via application.yaml. Another benefit for this refactoring is to improve readability. - Fix: Disable "Store Response" for TNVZ Client and App Client 2019-11-29T13:54:28+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-11-29T13:54:28+00:00 urn:sha1:a5b8668c0c7916a8fe2b84122d537a3e0bd67002 - 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. 2019-10-30T15:06:12+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-10-30T15:06:12+00:00 urn:sha1:c7551ed1dbf25fd786500a1516ddec9ec12dcf84 - Reason: Consistency 2019-10-04T09:20:20+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-10-04T09:17:48+00:00 urn:sha1:0727f68a2b899540fa951bfb22f9168bb1604b89 2019-10-04T08:28:56+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-10-04T08:28:56+00:00 urn:sha1:525c763bb99bc986543d0f1729228318d7c0ebcb