A headless facade that acts as a game host and provides web-based administration. Automation category: Terasology Facade. See https://forum.terasology.org/threads/facadeserver-headless-server-with-web-interface.1906
This PR contains the code which allows the HTTP and WebSocket servers to expose resources that can be accessed by clients. Also, two resources are included: ConsoleResource allows an authenticated user to execute console commands, and emits events when messages are written to the console, and OnlinePlayersResource can be queried (and notifies it's changes) to obtain a list of the names of the players currently connected to the server.
An overview of the implemented class structure is aviable on the devlog site, in the 18 June (week 3) update.
A better error handling system for invalid request messages has been implemented too. As recently suggested by @msteiger, I implemented a custom gson type adapter factory (ValidatorTypeAdapterFactory) which delegates the deserialization work to the default deserializer for a given data type, and then if the obtained object's type implements the Validable interface, its validate method is automatically called as part of the deserialization process so that if the data sent by the client is not consistent (i.e. mandatory fields are missing or similar issues) the deserialization fails. Now the classes which encapsulate data deserialized from client messages still have a validate method, but the usage is different from the old checkValid methods that were called manually after deserialization: the methods are there because the message classes implement Validable, but the code that calls gson.fromJson(...) doesn't need to call them because the validation is intrinsically performed during deserialization when the deserializer detects that the class implements Validable.
This PR contains the code which allows the HTTP and WebSocket servers to expose resources that can be accessed by clients. Also, two resources are included:
ConsoleResourceallows an authenticated user to execute console commands, and emits events when messages are written to the console, andOnlinePlayersResourcecan be queried (and notifies it's changes) to obtain a list of the names of the players currently connected to the server. An overview of the implemented class structure is aviable on the devlog site, in the 18 June (week 3) update.A better error handling system for invalid request messages has been implemented too. As recently suggested by @msteiger, I implemented a custom gson type adapter factory (
ValidatorTypeAdapterFactory) which delegates the deserialization work to the default deserializer for a given data type, and then if the obtained object's type implements theValidableinterface, itsvalidatemethod is automatically called as part of the deserialization process so that if the data sent by the client is not consistent (i.e. mandatory fields are missing or similar issues) the deserialization fails. Now the classes which encapsulate data deserialized from client messages still have avalidatemethod, but the usage is different from the oldcheckValidmethods that were called manually after deserialization: the methods are there because the message classes implementValidable, but the code that callsgson.fromJson(...)doesn't need to call them because the validation is intrinsically performed during deserialization when the deserializer detects that the class implementsValidable.