aboutsummaryrefslogtreecommitdiff
path: root/src/main/java
AgeCommit message (Collapse)AuthorFilesLines
2019-11-29Fix NPE When Receiver Is Identified by IdentityChristof Rabensteiner1-4/+14
- 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.
2019-11-22Fix Msg Schema Error: Honor Mutual Exclusiveness of <Choice>Christof Rabensteiner1-3/+6
- 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.
2019-11-07Fix Error in TNVZ QueryPerson RequestChristof Rabensteiner1-1/+1
- 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.
2019-11-06Remove Unused TNVZ VersionChristof Rabensteiner1-1/+0
2019-11-06Bump zusetnvz Contracts to Version 2.2.008Christof Rabensteiner1-2/+0
2019-10-30Refactor: Rename ClientFactory.create InterfaceChristof Rabensteiner3-8/+8
- Reason: Consistency
2019-10-30Remove JAXB Class Not Found FixChristof Rabensteiner4-96/+11
- 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#
2019-10-07Fixes in app2mzs Schema and CodeChristof Rabensteiner1-3/+5
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.
2019-10-07Resolve Sonarqube FindingsChristof Rabensteiner6-10/+4
2019-10-04Add Validation for TNVZ QueryPersonRequestChristof Rabensteiner1-0/+6
2019-10-04Fix Validation Error MessageChristof Rabensteiner1-1/+1
- Error was assigned to TNVZ Client, but appeared in MSG Client.
2019-10-04Add @author Tag Where It Was MissingChristof Rabensteiner42-3/+163
2019-10-04Add Licenses, NOTICE, and License HeaderChristof Rabensteiner44-0/+924
2019-10-03Update zusemsg and zusetnvz to Newest Version & Accommodate ChangesChristof Rabensteiner4-36/+39
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.
2019-10-02For {TNVZ, MSG}: Switch to Soap 1.2Christof Rabensteiner3-10/+25
- But: Leave MZS Interface at Soap 1.1 - Add ClientFactory.createSOAP11 to ensure that we can talk back to the app.
2019-10-02Fix Bug: Replace Boolean.getBoolean with Boolean.valueOfChristof Rabensteiner1-3/+2
- getBoolean:= true if system property exists and is true. - valueOf:= true if parameter == "true" (case insensitive).
2019-09-03Rename MzsClient to AppClientChristof Rabensteiner7-13/+13
...since it's a client that communicates with the app.
2019-08-30Fix Tnvz TypoChristof Rabensteiner2-16/+16
- sed 's/tvnz/tnvz/'
2019-08-28Fixes and RefactoringChristof Rabensteiner8-34/+36
- 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
2019-08-28Ensure that Each Step of Each Backend Process is LoggedChristof Rabensteiner12-18/+52
2019-08-28Remove Dependency to Apache AntChristof Rabensteiner1-10/+1
2019-08-26Log Incoming And Outgoing Messages with CXF Logging InterceptorsChristof Rabensteiner3-0/+17
- Add loggin dependency. - Enable Message Logging for Services and Clients. - Add message logging config + examples to application.yaml
2019-08-23Fix Binary-Status-Missing BugChristof Rabensteiner2-0/+2
...by ensuring that the interceptor also stores messages with the element "msg:DeliveryResponse" to the repository.
2019-08-23Fix JAXB Unmarshalling / Conversion BugChristof Rabensteiner1-15/+23
- 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.
2019-08-23Add Trace Logs to DeliveryRequestBackendChristof Rabensteiner1-0/+36
2019-08-23Fix: JAXB + Java >= 9 Class Loader Bug & Ensure Tomcat DeploymentChristof Rabensteiner5-7/+83
- 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)
2019-08-23Moved Config Files From main/resources/ To test/resources/configChristof Rabensteiner2-9/+12
- Reason: Integration tests need configuration, but config files should not be packaged into the final artifact. - Update paths.
2019-08-20Replace Thread.sleep with AwaitChristof Rabensteiner1-1/+1
2019-08-20Add Custom Http Headers to HTTP ClientsChristof Rabensteiner3-2/+73
- 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.
2019-08-19Refactor: mv logger logChristof Rabensteiner1-2/+2
2019-08-19Refactor Error MessagesChristof Rabensteiner1-3/+3
2019-08-19SignatureVerifier: Log incoming request to debugChristof Rabensteiner1-0/+11
2019-07-22Test Flow of DeliveryRequest from "End-To-End" & Fix BugsChristof Rabensteiner14-126/+267
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)
2019-07-18Fix: Remove Hardcoded Version in Mzs2MsgConverterChristof Rabensteiner1-1/+1
2019-07-18Refactor MzsService: Handle Timeouts In Separate MethodChristof Rabensteiner1-4/+12
2019-07-18Validate Schema of app2mzs Messages in Both DirectionsChristof Rabensteiner1-2/+1
2019-07-18Integrate Mzs Service Timeout and Handle Async ResponsesChristof Rabensteiner6-81/+115
- 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.
2019-07-17Put MoaZSException on Diet & Handle Edge CasesChristof Rabensteiner13-238/+168
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.
2019-07-16DeliveryNotification: Change Mzs Schema, Convert From Msg to MzsChristof Rabensteiner1-8/+94
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.
2019-07-16Implement ForwardResponseToService Sink And All Its ImplicationsChristof Rabensteiner10-53/+163
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.
2019-07-15Save Response To File Sink: Add Path to Configuration + FixChristof Rabensteiner3-15/+47
- Fix in ConfigUtil: SaveResponseToFile boolean would override LogResponse configuration (Copy Paste Error).
2019-07-12Allow App To Choose Between MsgResponse SinksChristof Rabensteiner7-21/+166
- 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.
2019-07-12Renamed and Simplified SignatureVerifierChristof Rabensteiner1-29/+38
2019-07-09Refactor Needles Interfaces and Rename "process" to "backend"Christof Rabensteiner14-131/+93
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.
2019-07-09Minor Fixes And RefactoringChristof Rabensteiner8-41/+36
- Fix typo in SafeResponseToFileSink. - MoaZSException: Simplify constructor by replacing lots of arguments with the builder instance. - Fix minor codesmells (unused imports, superfluous braces).
2019-07-09Refactor: Merge BinaryRepository into DeliveryRepositoryChristof Rabensteiner10-75/+84
- 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.
2019-07-09Refactor MsgResponse and its IDsChristof Rabensteiner10-51/+48
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.
2019-07-08Implement Zuse2App ServicesChristof Rabensteiner30-212/+724
- 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.
2019-07-03Refactor: Restructure ProjectChristof Rabensteiner11-32/+28
- Move components that depend on the service contracts into scheme package. - Move cxf related components into util package. - Rename SameThread to SingleThreaded.
2019-07-03Soap Client: Enable MTOM Per DefaultChristof Rabensteiner1-0/+6