Verifies the integrety of the projects, as builds are executed immediately after a code change was detected. This plan provides no artifiacts (use a nightly build instead).
OF-2269: Rewire SAXReader creation
This commit replaces individual snippets that create/use a SAXReader instance with one that's provided by the new utility implementation.
I'm aware that this undoes a bit of the change that was implemented as part of OF-2259. As part of those changes, the same SAXReader instance was used to parse all data for a collection of items (instead of recreating a new parser for each item). In the changes I'm making here, this is replaced by scheduling a task in an ExecutorService for each item, blocking for it to be processed by a reusable parser, before moving to the next item. Although more involved, this should still perform a lot better than recreating a parser for each item.
Dave Cridland <dave@forwardhealth.co>
4bfdaf6cd689ed542e7fe91c24f138a59e559b56
Store and retrieve subscription request stanzas
This change means that subscription requests are stored and
resent verbatim on login.
OF-2244: Store stanza in database
This commit ensures that the stanza of a presence subscribe request is actually stored in the database (as opposed to only be added in memory, without that change being pushed to the database.
Additionally, the stanza should:
- only be present in the roster item for the receiving entity
- be removed from the database after the request has been rejected or accepted (to not fill up the database with stale data)
OF-2269: Have uniform API to create a suitable SAXReader instance
SAXReader instances, used to parse XML, are created all over the place. They need a bit of specific configuration to circumvent vulnerabilities. Often, their lifecycle needs to be maintained, as their creation is resource intensive. All of this should be put in one central utility, instead of live as re-invented wheel fragments all over the place.
OF-2269: Caught InterruptExceptions shouldn't be hidden
The rewrite of SAXReader utilization introduces a new source of potential InterruptExceptions. This occurs when 'someone' wants to the thread to stop execution. By catching this as a regular exception, the code at hand will handle that scenario as appropriate, but will also hide the fact that 'someone' wants to stop the thread from its own invocator. To let the caller know that someone wants to stop the thread from execution, the interrupt flag should be set. See https://programming.guide/java/handling-interrupted-exceptions.html for more rationale.
