System Functions
Implements crucial system functionality as described in #8 (closed). Things to be sorted out:
-
Using AutoCloseable
for our transaction framework? This is discussed in #10 (closed). -
How to deal with static method mocking? As of late, Mockito supports this as well, therefore we should need no PowerMock and I have added the corresponding Maven dependency. HOWEVER: Something is not quite right yet. If you run the SystemStartupListenerTest
beforeConnectionPoolTest
, the latter completely fails as the logging functionality seems to be still mocked despite having explicitly calledclose()
on the static mocks. If you run the two test classes in the opposite order, they all pass nicely. -
Which methods exactly should the Mailer
offer? For now I have added a super general method accepting a collection of direct recipients, CC recipients, BCC recipients and Reply-To recipients as well as other arguments. The result of this discussion can be incorporated in my next pull request where theMailer
is officially implemented. -
How to deal with static method mocking? As of late, Mockito supports this as well, therefore we should need no PowerMock and I have added the corresponding Maven dependency. HOWEVER: Something is not quite right yet. If you run the SystemStartupListenerTest
beforeConnectionPoolTest
, the latter completely fails as the logging functionality seems to be still mocked despite having explicitly calledclose()
on the static mocks. If you run the two test classes in the opposite order, they all pass nicely. -
Introducing some kind of "fingerprint" for connections handed out by the ConnectionPool
to prevent accepting connections that have never been issued? -
Refactoring the several registries using just one generic Registry<T>
? Probably using CDI producer methods? -
Introducing factories for the dependencies created in SystemLifetimeListener
to the benefit of testability? This would however create some redundancy, as the factory methods would have the same signature and documentation as the called constructors...
This is a lot of stuff to consider and should be also discussed in virtual person tomorrow. So long!
Closes #8 (closed) and #11 (closed)
Edited by X kirschstei