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: MOA ZS converts the mzs:Receiver/Person to
msg:Receiver/Person even if mzs:Receiver/Person is null.
- Solution: Distinguish Cases.
- Add ClearingProfilID in mzs2msg conversion.
|
|
- 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.
|
|
- Problem: When assembling the TNVZ Query Person Request, I convert
the Sender with msgp's ObjectFactory.createPerson. The marshaller
will then create a Corporate body like this:
<ns2:Person xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns2:CorporateBodyType">
What we really want is this:
<ns2:CorporateBody>
- Solution: Replace createPerson with createCorporateBody.
- Thanks to Johannes Hörtnagl and Christoph Kaiser-Feistmantl for
the feedback.
|
|
|
|
|
|
- Reason: Consistency
|
|
- 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#
|
|
app2mzs Schema Changes:
- mzs:MessageType/ZSDeliveryID was mandatory. However, in certain
cases the ZSDeliveryID does not exist (Example: perform
QueryPersonRequest, request fails > no ZSDeliveryID). This element
is now optional.
- mzs:Error/Code was of type xs:integer, is now xs:string. Reason:
msg:Code is also of type string.
Incorporate app2mzs schema changes into code base.
|
|
|
|
|
|
- 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.
|
|
- Error was assigned to TNVZ Client, but appeared in MSG Client.
|
|
|
|
|
|
|
|
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.
|
|
- getBoolean:= true if system property exists and is true.
- valueOf:= true if parameter == "true" (case insensitive).
|
|
|
|
...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.
|
|
|
|
...by ensuring that the interceptor also stores messages with the element
"msg:DeliveryResponse" to the repository.
|
|
- Ensure that moazs creates concrete Persons (CorporateBody,
PhysicalPerson), resp. concrete Adresses (InternetAddress,
PostalAddress, TelephoneAdress) instead of AbstractPersons or
AbstractAdresses during conversion from mzs to msg. Reason:
Instances of abstract classes do not conform to the xml scheme.
|
|
|
|
- Problem: Jaxb + JAVA >= 9 Runtime + Tomcat = ClassNotFoundException:
ContextFactory.
Reason: Apparently, jaxb uses the "wrong" classloader (the system
classloader via the thread classloader) and this classloader does
not know about jaxb api's and implementations at runtime since
oracle decided to move jaxb* out of JRE.
Solution: create a new thread, override the thread's "thread"
classloader with the "class" classloader and do all jaxb
interactions in that thread. See:
https://sjhannah.com/blog/2018/11/21/jaxb-hell-on-jdk-9/
- Move "run jaxb interactions in own thread with class class loader"
code into own component (JaxbClassNotFoundFix,
runInTheadWithClassClassLoader) and wrap ClientFactory and
Marshaller code into the "runInTheadWithClassClassLoader".
- Ensure that app can be deployed in a Tomcat container (by following
this guide: https://www.baeldung.com/spring-boot-war-tomcat-deploy)
|
|
- 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)
|
|
|