| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
- 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.
|
|
- 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
|
|
- 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.
|
|
- Problem: When activating the QueryPersonRequest, the TNVZ returns an
Identification element that needs to be integrated into the
msg:DeliveryRequest as a child of Receiver. The Identification child
is mutually exclusive to another sequence consisting of (Person,
AustrianAddressesOnly, Address). I forget to delete the sequence
when adding the Identifcation element and violate the the msg
schema.
- Solution: Delete sequence when adding Identification.
- Test the fix in test case.
Thanks to Johannes Hörtnagl for pointing out the problem.
|
|
- Reason: Consistency
|
|
- Put SSL client auth guide into separate file.
- Add download link to apps.egiz.gv.at/releases.
- Put note that cluster mode is not ready.
|
|
|
|
|
|
|
|
Upgrade zusemsg 2.2.0 to 2.2.007:
- msg:RelayedViaERV
- Change from boolean to complex type (ervcode).
- Move from msg:DeliveryRequestStatusType/Success into
msg:DeliveryRequestStatusType, which affects Success, Error, and
PartialSuccess.
- Was removed from DeliveryNotificationType.
- Change msg:DeliveryNotification/Answer from list to singleton.
- Change msg:DeliveryRequestStatusType/PartialSuccess is to type AnswerType.
- msg:DeliveryRequestStatusType and msg:DeliveryNotificationType
receive the attribute ID (for signature referencing).
- Add new optional element msg:AustrianAdressesOnly (IndicatorType) to
DeliveryRequestType/Receiver/(choice sequence).
- Add new optional element ClearingProfilID to DeliveryRequestType/Sender.
- Add new element ERVConfirmedDelivery, which subsitutes msg:Answer
and extends msg:AbstractOperation
- Has element ErvCode (also new token256 type).
- Has element ERVDeliveryTimestamp.
- Add new optional element TargetIdentification of type
p:IdentificationType to msg:DeliveryNotification/User/ as optional
element.
- Add new enumeration "System" to msg:DeliveryNotification/User/Role.
- Rename type AustrianLanguageType from
"AustrianEthicMinorityLanguageType" to "AustrianLanguageType" and
add "DE" as value.
- msg:Tags were unbounded, now they are limited to 20.
- VersionNumberType: Patch version can have three digits.
Upgrade zusetnvz 2.2.0 to 2.2.006:
- Add StandardMimeTypeList to tnvz:QueryPersonResponse and
tnvz:QueryAdressabilityResponse.
- Add AllStandardMimeTypes (indicator) to tnvz:PersonResult/Success.
- Add optional msg:MetadataList to tnvz:PersonQueryType/Metadata
tnvz:AddressabilityQueryType/Metadata.
- Move tnvz:AustrianAdressesOnly to msg namespace.
Carry zusemsg changes into app2mzs interface:
- Switch namespace of AustrianAdressesOnly from tnvz to msg.
- Add new optional element ClearingProfilID to
mzs:DeliveryRequestType/Sender; Reason: Element was added to zusemsg
2.2.007.
- Add new choice in mzs:DeliveryNotification to forward new answer
type msg:ERVConfirmedDelivery to the app.
- Move msg:RelayedViaERV from SuccessType into MessageType (now it's
available to all types that derive from MessageType).
Accommodate zusemsg/tnvz changes in code base:
- TNVZHelper: Consider StandardMimeTypeList when assessing if
DeliveryRequest/mimetypes overlap with TNVZ's Accepted Mimetypes.
- Msg2MzsConverter:
- Put getRelayedViaERV() into all DeliveryStatusRequest replies.
- Honor that Notification/Answer is Singleton instead of List.
- Handle case were DeliveryNotification/Answer is of type
ERVConfirmedDeliveryType.
- Remove RelayedViaERV from DeliveryNotification as this element is
not available anymore.
- NotificationResponse: Honor that Notification/Answer is Singleton
instead of List.
Fix all testcases and sample soap messages to comply with schema changes.
|
|
- But: Leave MZS Interface at Soap 1.1
- Add ClientFactory.createSOAP11 to ensure that we can talk back to the app.
|
|
|
|
...since it's a client that communicates with the app.
|
|
- sed 's/tvnz/tnvz/'
|
|
|
|
|
|
- Otherwise app wont detect it
|
|
- Add better descriptions.
- Reorder entries.
|
|
Reason: Restructure not neccessary.
|
|
- 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
|
|
- Problem: @TestConfiguration did not override config/MoaSigConfig.
- Therefore test uses bean that is configured via application.yaml.
- Solution: Replace @TestConfiguration with bean that was created
and configured directly in testcase.
|
|
|
|
- Reason: Integration tests need configuration, but config files
should not be packaged into the final artifact.
- Update paths.
|
|
- Reason: Now we can run integration tests without the need to set up
SSL reverse proxy with client certificates.
|
|
|
|
- Change app2mzs schema: Add Custom Headers to ClientType Element.
- Set custom headers in ClientFactory.
- Parse custom headers from spring environment.
- Merge custom headers from two different profiles.
- Add example to application.yaml.
- Test conversion of custom headers from spring profile
- Test merging and overriding custom headers.
|
|
|
|
|
|
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)
|
|
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.
|
|
- Fix in ConfigUtil: SaveResponseToFile boolean would override
LogResponse configuration (Copy Paste Error).
|
|
- MZS Schema Change: Add "MsgResponseSinks" element to
mzs:DeliveryRequest/Config that allows sender to configure how
MsgResponses should be archived.
- ConfigUtil: Interpret MsgResponseSink parameters from Spring
Environment and merge with ConfigType.
- MsgResponseBackend: Send responses to sinks according to
MsgResponseSinks in Config
- application.yaml: Add MsgResponseSinks parameter to configuration.
- Uncouple Sink implementations from java.util.function.Function,
because the sink interfaces are going to differ and there is no need
to unite them under one interface.
- Add and test LogResponseSink, which logs responses to it's logger.
- MsgResponse: Add JAXB getter for response. Reason: Can be passed to
marshaller.
|
|
|
|
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.
|
|
- Fix typo in SafeResponseToFileSink.
- MoaZSException: Simplify constructor by replacing lots of arguments
with the builder instance.
- Fix minor codesmells (unused imports, superfluous braces).
|
|
- 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.
|
|
StoreSOAPBodyBinaryInRepositoryInterceptor:
- Replace "generate body's id via concatenation" with "give the right
generator function the app delivery id and let the generator
function do the work". Reason: Prevent the logistics of deriving IDs
to spill into unrelated components.
MsgResponse refactor:
- Make MsgResponse an abstract class.
- Derive ResponseID's ONLY in MsgResponse::createResponseID.
Others:
- Ensure that all invocations to DeliveryRepository.getResponse and
BinaryRepository.get use "responseID" instead of ambiguous "id" or
incorrect "appDeliveryID".
- Move SingleThreadedDeliveryPipeline into process package.
|
|
- 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: Handle edge case where
Mzs/DeliveryRequest/Sender/CorporateBody is missing (Reason: This
field is in a <choice> with msg:SenderProfile, so if CorporateBody
is missing the request still passes the schema validation). Handle
case by rejecting missing CorporateBody and TnvzQuery activated.
- Add test cases for TnvzHelper.
|
|
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".
|
|
- Merge TnvzClient and TnvzResultVerifier to TnvzHelper; TnvzHelper
now builds the QueryPersonRequest, sends it to the tnvz port and
evaluates the result.
- Publish some interfaces in Mzs2MsgConverter because they are needed
by TnvzHelper.
- Generalize MsgClientFactory to ClientFactory such that it can be
used to generate arbitrary SOAP clients (e.g. also for tnvz!).
Schema Changes to accomodate Tnvz's QueryPersonRequest:
- Add optional tnvz:AustrianAddressesOnly and optional TnvzMetaData to
mzs:mzs:DeliveryRequest.
Removed Unit Tests:
- Remove subset of SameThreadDeliveryPipeline testcases (mimetype
related) because its logic moved to TnvzHelper.
|
|
- EgovUtils were needed because of DomUtils. Replace it with eaaf
components' DomUtils.
- Add test case to ensure SoapUtils still works as intended. - Remove
unused import statement
|
|
Per default, integration tests are excluded from build. They can be
included with the `-P integration-test` argument.
- Pom: Add maven profile for integration tests.
- Rename integration tests (add `IT` prefix).
- Move Resources into IT* folders.
- Add MsgClientTest to test suite and add assertions to each test case.
|
|
- Move JaxbM initialization into Marshaller such that it can be used
in tests without Spring's Application Context.
- Remove SpringRunner from Mzs2MsgConverter Test, which makes the test
run faster.
|
|
- Also: Ensure that truststore is of type JKS because PKCS12 is not
supported.
|
|
- Print a big scary warning message for everyone who enables "trustAll"
- Test TrustAll and LaxHostNameVerification
- Describe test case requirements and add key material needed to run
these test cases.
|
|
- Refactor: Get rid of MsgClient, because MsgClientFactory can do all the work.
- Add Connection Timeout and Request Timeout (Policies of HTTP Client)
to mzs:DeliveryRequest/Config and application.yaml.
- Update readme: Add JDK 12 Requirement
|
|
- Switch to java 12 for now. Reason: Bug [1] in JDK 11 (up to
jdk-11+28) impairs SSLHandshake ("Unsupported Operation Exception"),
but was fixed in Java 12.
- Set HTTP policy to infinite.
- Fix key/truststore path resolution
- Fix NPE in ConfigUtil.merge
- Rearrange application.yaml to include two config profiles (one with
and one without SSL for the msg client).
- Add key material for testcases (Note: expires: May 2 14:47:08 2020 GMT)
- Update MsgClient Testcases
[1] https://bugs.openjdk.java.net/browse/JDK-8214098
|
