You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Improvement idea based on mailing list discussion about AWS deployment:
**Mailing List **
It was discovered that when deploying a WAR file to AWS Beanstalk, along with H2 database, the application will not function properly. The reason is that Beanstalk doesn't allow write access locally, but H2 db configured with local file configuration would require write access.
In the logs it can be seen that while the DB init will throw an exception, it is ignored and the process is continued, while part of the boot sequence operations will be left undone, for example setting the Classpath for lift snippets. This will be shown as template render failures on browser.
It is however not immediately apparent what is causing these render failures, and in some environments like Beanstalk, accessing the logs can be difficult.
Handling the DB init failure should be better and more apparent for the developer.
At first two different approaches were thought of:
In case of db init failure, quit the whole process or,
inform about the initialization failure somehow through the browser.
First option would be easier to implement, but poses breaking changes in expected behaviour of Lift.
Also would be good to investigate if applying the other boot sequence operations despite of DB init failure would be possible.
The text was updated successfully, but these errors were encountered:
Improvement idea based on mailing list discussion about AWS deployment:
**Mailing List **
It was discovered that when deploying a WAR file to AWS Beanstalk, along with H2 database, the application will not function properly. The reason is that Beanstalk doesn't allow write access locally, but H2 db configured with local file configuration would require write access.
In the logs it can be seen that while the DB init will throw an exception, it is ignored and the process is continued, while part of the boot sequence operations will be left undone, for example setting the Classpath for lift snippets. This will be shown as template render failures on browser.
It is however not immediately apparent what is causing these render failures, and in some environments like Beanstalk, accessing the logs can be difficult.
Handling the DB init failure should be better and more apparent for the developer.
At first two different approaches were thought of:
First option would be easier to implement, but poses breaking changes in expected behaviour of Lift.
Also would be good to investigate if applying the other boot sequence operations despite of DB init failure would be possible.
The text was updated successfully, but these errors were encountered: