404 when submitting login form about cuba-ordermanagement

[mariodavid]

Hi,

so i'm not sure if i get correctly what you did, so here are a few questions:

The app is running on a separate machine on the local network (so not localhost)

What is the app in this case? The deployed CUBA app consists of two different war files. This you can see in the article in the Dockerfile:

Add generated app war files to the webapps directory

ADD war/app.war /usr/local/tomcat/webapps/
ADD war/app-core.war /usr/local/tomcat/webapps/

With app, do you mean the docker container or one of the two war files?

and I've updated the web-app.properties and portal-app.properties accordingly to the IP address of the server concerned.

What did you change in the properties files? Are you talking about the property: cuba.connectionUrlList ? In case you are, it is not necessary to do so. What is described with this urls is only relevant when you deploy both war files in different servers / containers. This sometimes makes sense when you want to create more front-end servers then backend servers or so.

But in the Docker scenario, both war files are in the same container, so it actually has to be "http://localhost:8080/app-war".

If you have actually deployed both wars in different containers / servers, that it is probably a container network connectivity problem.

Can you give me a hint if i'm guessing right here?

Since it does not make much sense to run two war files in one docker container, it would be possible to deploy the CUBA app with a singe war approach. You'll find more information here: https://doc.cuba-platform.com/manual-6.1/build.gradle_buildWar.html (under singleWar). It might be useful to create another example with a single war, because then you don't have to set cuba.connectionUrlList at all, because it is the same war.

Thx for reading btw!

Bye,
Mario

[rustytrombone]

Hi Mario,

Thanks so much for such a quick response.

So, it's the docker container that is running, with what should be both of the war files running within it. I'm assuming that is the case, as I'm just following the instructions verbatim from the article and I'm quite new to containerisation of apps as a concept.

Would it be helpful for me to supply more complete logs from the docker-compose session?

Many thanks

Chris

[mariodavid]

Hi,

ok, after trying it out myself after a while i think it even might be true that i made a mistake here. The logs for of the tomcat would be great.

Is it possible that the tomcat could not start the "app-core.war" because of a database connection problem or something? In this case, the web app starts up but when trying to login, it just gives you a error message to contact the administrator and in the logs there will be a 404 on app-core/removting/cuba_loginService ...

When you send me the links i'll go through it and potentially get the error and update the blog post accordingly.

Bye

[rustytrombone]

Hi Mario,

I've attached the log file that includes the gradle & docker build phases too. I can't see a specific message in there regards the core failing, but it's highly likely I've missed something important.

Full disclosure: I had to tweak one of the supplied SQL files (core/db/update/hsql/160418-2-updateProduct.sql I believe) to change the 'longvarchar' to a 'varchar(255)' field to try and get this to start up at all, as there doesn't seem to be postgres specific scripts for this phase of the DB initialisation and having the longvarchar in there was causing the process to fail because that column datatype was not recognised by postgres.

I think this was because the system was falling back to the hsql scripts and then encountering this error. I might be totally wrong on that, I'm quite new to this method of building/running applications.

cuba-om-log.zip

[mariodavid]

hi,

thanks for the logs. i'll go thorugh it. Besides that, could you have a look at the changes i just pushed (73d0a90) and give it another try? I saw the missing PostgreSQL db files as well and added them. additionally i changes the docker-compose.yml file structure to use the version 2 of the syntax with custom networking and stuff...

[mariodavid]

could you additionally show the application.properties files you mentioned above?

[rustytrombone]

Hi Mario,

Please find the new logs attached. I have reverted entirely to the new version of the code (cleared directory and re-cloned) so the .properties files should be as they are in the repo.
cuba-om-log.zip

[mariodavid]

Hi,

sorry for the late reply. I've looked through the logs and found this exception:

`postgres_1 | ERROR: relation "sys_db_changelog" already exists
postgres_1 | STATEMENT: create table SYS_DB_CHANGELOG(SCRIPT_NAME varchar(300) not null``

Further information:
primary key, CREATE_TS timestamp default current_timestamp, IS_INIT integer default 0) web_1 | 11:52:23.728 ERROR c.h.cuba.core.sys.AppContextLoader - Error initializing application web_1 | java.lang.RuntimeException: An error occurred while creating changelog table web_1 | at com.haulmont.cuba.core.sys.dbupdate.DbUpdaterEngine.createChangelogTable(DbUpdaterEngine.java:143) ~[cuba-core-6.1.2.jar:6.1.2] web_1 | at com.haulmont.cuba.core.sys.dbupdate.DbUpdaterEngine.doInit(DbUpdaterEngine.java:193) ~[cuba-core-6.1.2.jar:6.1.2] web_1 | at com.haulmont.cuba.core.sys.dbupdate.DbUpdaterEngine.updateDatabase(DbUpdaterEngine.java:98) ~[cuba-core-6.1.2.jar:6.1.2] web_1 | at com.haulmont.cuba.core.sys.AppContextLoader.afterInitAppContext(AppContextLoader.java:78) ~[cuba-core-6.1.2.jar:6.1.2] web_1 | at com.haulmont.cuba.core.sys.AbstractWebAppContextLoader.contextInitialized(AbstractWebAppContextLoader.java:64) ~[cuba-global-6.1.2.jar:6.1.2] web_1 | at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4811) [catalina.jar:8.0.33] web_1 | at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5251) [catalina.jar:8.0.33] web_1 | at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147) [catalina.jar:8.0.33] web_1 | at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725) [catalina.jar:8.0.33] web_1 | at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701) [catalina.jar:8.0.33] web_1 | at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717) [catalina.jar:8.0.33] web_1 | at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:940) [catalina.jar:8.0.33] web_1 | at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1816) [catalina.jar:8.0.33] web_1 | at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_72-internal] web_1 | at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_72-internal] web_1 | at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_72-internal] web_1 | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_72-internal] web_1 | at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72-internal] web_1 | Caused by: java.sql.SQLException: ERROR: relation "sys_db_changelog" already exists Query: create table SYS_DB_CHANGELOG(SCRIPT_NAME varchar(300) not null primary key, CREATE_TS timestamp default current_timestamp, IS_INIT integer default 0) Parameters: [] web_1 | at com.haulmont.bali.db.QueryRunner.rethrow(QueryRunner.java:463) ~[cuba-global-6.1.2.jar:6.1.2] web_1 | at com.haulmont.bali.db.QueryRunner.update(QueryRunner.java:551) ~[cuba-global-6.1.2.jar:6.1.2] web_1 | at com.haulmont.bali.db.QueryRunner.update(QueryRunner.java:522) ~[cuba-global-6.1.2.jar:6.1.2] web_1 | at com.haulmont.bali.db.QueryRunner.update(QueryRunner.java:607) ~[cuba-global-6.1.2.jar:6.1.2] web_1 | at com.haulmont.bali.db.QueryRunner.update(QueryRunner.java:572) ~[cuba-global-6.1.2.jar:6.1.2] web_1 | at com.haulmont.cuba.core.sys.dbupdate.DbUpdaterEngine.createChangelogTable(DbUpdaterEngine.java:138) ~[cuba-core-6.1.2.jar:6.1.2] web_1 | ... 17 common frames omitted web_1 | 02-May-2016 11:52:23.736 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal One or more listeners failed to start. Full details will be found in the appropriate container log file

I think you already created the db-container and this might caused the error.
When you use docker-compose, before starting the containers via docker-compose up do a docker-compose kill && docker-compose rm to be sure that you have a clean state.

[mariodavid]

Were you able to get the container up and running?