The current implementation of player loading/saving in Apollo relies on the persistence providers having a no-args constructor, making implementation of persistence providers that rely on external systems troublesome.
For example, a persistence provider that uses a JDBC connection to load data from a SQL database will likely want to pool its connections. To achieve this the implementation would need to share the pool via static state, which makes testing difficult and the code obtuse.
Solutions:
- Bootstrap the server using a fully-fledged Dependency Injection framework (Guice?)
- Extend the PlayerLoader XML reader with support for passing in configuration parameters/other objects.
The current implementation of player loading/saving in Apollo relies on the persistence providers having a no-args constructor, making implementation of persistence providers that rely on external systems troublesome.
For example, a persistence provider that uses a JDBC connection to load data from a SQL database will likely want to pool its connections. To achieve this the implementation would need to share the pool via static state, which makes testing difficult and the code obtuse.
Solutions: