| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
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.
|
|
- 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.
|
|
- Move components that depend on the service contracts into scheme
package.
- Move cxf related components into util package.
- Rename SameThread to SingleThreaded.
|
|
TnvzHelper Fixes
- Handle additional edge cases.
- Mzs:Schema Change: Eliminate PreAdviceNote redundancy by removing it
from mzs:DeliveryRequest/TnvzMetaData; PreadviceNote is already in
the Receiver element. Update TnvzHelper accordingly.
- Implement and integrate tnvz completeness check into
DeliveryRequestAugmenter to ensure that, after augmentation, tnvz
can be performed.
Refactor mzs:DeliveryRequest Validation:
- Before: Validating, merging and generatig ConfigType in ConfigUtil.
- Change: Need to add validation of DeliveryRequest (Reason: For
performing Tnvz Requests, the DeliveryRequest needs to be in a
consistent state).
- Problem: DeliveryRequest validation does not fit into ConfigUtil.
- Solution: Put validation of DeliveryRequest and Config into new
Component "MzsValidation".
|
|
- Reason: All three classes opertate with the same data type, have
the same clients, and have the same reasons for change.
- Makes code in client more readable as it reduces number of
dependencies.
|
|
Refactor
- Add Builder to ConfigProfileGenerator. Reason: Constructor had too
many arguments.
- Move Conversion from Map to Config from ConfigProfileGenerator into
dedicated 'ConvertMapToConfig' Class; Reason: I expect additional
configuration properties and I don't want those changes to affect
the ConfigProfileGenerator (or it's test cases)
- Move Access to Spring's env into facade to simplify ConfigProfileGenerator.
|
