Added a main method to webservice.App that launches the webserver and backing service in the same VM connected using loopback bus. Useful for initial local testing.

Added capability to specify REST method in service model and automatically generate http request parameters from the InMessage of the Operation.
Nested entities cannot be supplied as query params since embedded fields do not support the createFromRawJson. Users would have to use POST method in these cases.

Added support to generate HTML Test page for the service - to be able to quickly test the service Apis.

This release makes injectable peer service clients available for (remote) handlers which enables synchronous request reply with the peer service.

Non-functional refactor for code cleanup, efficiency and a step towards supporting zero garbage implementation. Upgrade to X 3.4.68 or higher required.

This release changes Eagle's internal heartbeat request handler to be a Remote handler since it does not use the repository/state.

Refactored web app functionality to generate AbstractWebApp and allow users to extend and customize behavior of the web service.

Added exception handling in Web App to return proper http response.

Refactored the lifecycle of HTTP server, embedded by the service's web app's App.java, to follow the same lifecycle as the app itself.

Eagle comments in the ADM and ASM models to be aggregated into the generated WebApp and integrated with a REST API documentation tool so that my comments eventually self document the REST API. This story should do the following:
Added support for documentation of an ASM model just like one can document an ADM model.
Enhanced ASM code generator to document the REST endpoints using documentation in the ADM and ASM models
Integrated with Swagger to auto-document and provide the ability to test the REST API

Prior to this release, a user had to invoke open() on an Eagle service client before issuing service requests. This story enhances the client to automatically invoke open() when the first service request is issued.

Prior to this release, all service requests issued on an Eagle service client completed synchronously i.e. the thread invoking the request method blocks and waits for the response to come back before returning to the caller. This release implements the capability to do asynchronous request-reply. To perform asynchronous request-reply, the user would invoke the OperationRequestAsync method (newly generated in this release) which is the async request method corresponding to the synchronous OperationRequest method (generated prior to this release). The method would send the request and immediately return to the caller. To asynchronously receive the response for the request, the client should provide the object containing @EventHandler methods to handle the response messages to the Client constructor. This would result in the response messages being asynchronously dispatched to the registered handlers. The OperationRequest methods continue to be generated for synchronously request-reply invocation of service methods.

Prior to this release, an Eagle service client creates its own AEP engine instance. This release adds the ability for a user of the service client to supply an AEP engine for it to use rather than create a new one.

Note: Although this functionality can be used by an end user, this is primarily for use by a peerEagle service to perform asynchronous request-reply with the the service

Prior to this release, two peer Eagle services could not perform request-reply with each other. This release implements the ability to do so. When a service is declared as peer of another service, this release will perform the following:

• Automatically include the peer service's client in the service runtime
• Instruct the peer service client to use the service's engine
• Generate handlers for the peer service client's response messages
• Generate injectable MessageSender instances for the peer service event and request messages