Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
...since it's a client that communicates with the app.
|
|
|
|
|
|
- sed 's/tvnz/tnvz/'
|
|
|
|
|
|
- Otherwise app wont detect it
|
|
- Add better descriptions.
- Reorder entries.
|
|
- Describe Configuration Profiles
- Describe Logging
- Refactor: Put each Sentence in a new line.
|
|
|
|
- Add Tomcat Deployment Guide
|
|
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.
|
|
- Fix Code Blocks
|
|
|
|
- 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.
|
|
- See https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#build-tool-plugins-maven-packaging
|
|
- Also: Replace local repository with apps.egiz.gv.at/maven
- Update Readme and remove cumbersome "build via local repo" guide.
|
|
|
|
|
|
|
|
|
|
|
|
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)
|
|
|
|
|
|
|
|
|
|
- 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 Changes:
- Formerly: The mzs:DeliveryNotificationType is a choice between
Success And Error; Change: Wrap choice in a sequence. Reason: msg
2.0.0 adds fields that fit best in this sequence. Adding new fields
to Success or Error duplicates code, whereas adding it to the base
type (which is MessageType) also affects mzs:DeliveryRequestStatus.
- Add msg:SenderDetails, ReceiverDetails, user, AdditionalFormat,
NotificationsPerformed; Reason: It was added to zusemsg 2.0.0.
|
|
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.
|
|
- 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.
|