Activiti REST after restart

[hbacanak]

Hi,

I am deploying activiti-rest(5.17.0) war on tomcat (8.0.9) and postgresql(9.3.5). However it only works for the first time. After i restart tomcat i get 404.

What i changed:

activiti-rest\WEB-INF\classes\db.properties
db=pgsql
jdbc.driver=org.postgresql.Driver
jdbc.url=jdbcostgresql://localhost:5432/Activiti
jdbc.username=xxxx
jdbc.password=xxxx

activiti-rest\WEB-INF\classes\engine.properties(first run)
# demo data properties
create.demo.users=true
create.demo.definitions=true
create.demo.models=true

# engine properties
engine.schema.update=true
engine.activate.jobexecutor=false
engine.asyncexecutor.enabled=true
engine.asyncexecutor.activate=true
engine.history.level=full

activiti-rest\WEB-INF\classes\engine.properties(other runs)
# demo data properties
create.demo.users=false
create.demo.definitions=false
create.demo.models=false

# engine properties
engine.schema.update=false
engine.activate.jobexecutor=false
engine.asyncexecutor.enabled=true
engine.asyncexecutor.activate=true
engine.history.level=full

What i expect?
After database initialization and demo data is set, i shouldn't recreate the data again.

What is happening
At first deployment everything is working as expected
http://localhost:8080/activiti-rest/service/identity/users returns
{"data":[{"id":"fozzie","firstName":"Fozzie","lastName":"Bear","url":"http://localhost:8080/activiti-rest/service/identity/users/fozzie','email':'fozzie@activiti.org','pi...}, .. etc

When i restart tomcat and access  http://localhost:8080/activiti-rest/service/identity/users returns 404.
it is this way unless drop Activiti database, recreate and deploy activiti rest. Again this only works for the first time.

Any ideas why is this happening?

[jbarrez]

This sounds very strange. Are you sure the data is in your postgres database?

[hbacanak]

Hello Joram, your response is much appreciated. Database seems to be fine (all tables and data present, for example three demo users in the act_id_user table). I used following steps, may be i am missing some required step.

The critical  portion of  the log file seems to be
—-
org.apache.catalina.core.StandardContext.startInternal Error listenerStart
org.apache.catalina.core.StandardContext.startInternal Context [/activiti-rest] startup failed due to previous errors
org.activiti.rest.servlet.WebConfigurer  - Destroying Web application
—-
yet it is cryptic to me and does not says much about the reason of the error.


First deployment
1 Expand activiti-rest.war to a directory x
2 Make db.properties changes
3 Add postgresql driver
4 Move activiti-rest folder to tomcat webapps
5 catalina.bat run > first_run.log 2>&1
log results are in the first_run file(attachment)
http://localhost:8080/activiti-rest/service/identity/users responds as expected.
6 ctrl-c to stop tomcat

Second deployment
1 make changes to engine.properties at to prevent database initialization & data generation at x/activiti-rest
2 delete existing activiti-rest webapp 
3 copy modified x/activiti-rest to tomcat webapps
4 catalina.bat run > second_run.log 2>&1
log results are in the second_run file(attachment)
http://localhost:8080/activiti-rest/service/identity/users returns 404
5 stop tomcat

[hbacanak]

btw, exactly the same thing happening with activiti-explorer. also attached logs.

[hbacanak]

i changed the logging to debug mode. On the second run
if I turn off schema update it says Tables missing for component(s) engine, history, identity. Tables are there and seems to be populated.
if I recover engine.properties to original state and deploy again the third time
it gives table alredy exist errors as expected like ‘ERROR: relation "act_ge_property" already exists’

[trademak]

The db property in db.properties seems to have a wrong value. It should have postgres as value.

Best regards,

[hbacanak]

Hello Tijs, thank you for your response.
I applied your suggestion with clean install and outcome did not change.
I also updated the tool chain(apache, jdk, postgresql) to latest versions and it didn't make difference either.

[hbacanak]

ok. the problem seems to be locales.

at catalina.bat changing
      set "JAVA_OPTS=%JAVA_OPTS% %LOGGING_MANAGER% "
to
      set "JAVA_OPTS=%JAVA_OPTS% %LOGGING_MANAGER% -Duser.language=en -Duser.region=US"
corrected the problem.

table names distorted during application lifecycle(eg tablename.toLowerCase()). In  my humble opinion, locales should be handled more gracefully.

[jbarrez]

> In my humble opinion, locales should be handled more gracefully.

How? We are assuming UTF8 for all our code to cover as most as languages as possible. Checking the locale wont help for that.

[hbacanak]

My System:
System.out.println(Charset.defaultCharset().toString());  //prints windows-1254
System.out.println(Locale.getDefault()); // prints tr_TR

Problem Example:
—
public class LocaleTester {
  private String tableName="HI";
  @Test
  public void toLowercaseTest(){
    assertEquals("hi", tableName.toLowerCase());
  }
  @Test
  public void toLowercaseTestWithUsLocale(){
    assertEquals("hi", tableName.toLowerCase(new Locale("en", "US")));
  }

  @Test
  public void toLowercaseTestWithTrLocale(){
    assertEquals("hi", tableName.toLowerCase(new Locale("tr", "TR")));
  }
}
—
toLowercaseTestWithUsLocale passes,
toLowercaseTest & toLowercaseTestWithTrLocale  fails:
—
expected: <h > but was: <h[ı] >
Expected :hi
Actual   :hı
—
The root of the problem:
Upper case / lower case character mapping is not compatible with English for example:
English
Uppercase  - Lowercase
I - i

Turkish
Uppercase - Lowercase
I - ı
İ - i

—
so on the second run, when you search for a table named tablename.toLowerCase() it cannot find the table if it contains a variant of characters that has different mappings than english counterpart.
(I believe) the problem I encountered is only relevant in table name conversions. When I changed tomcat locale to English the problem solved. (Although it is not really a solution because this will bring other problems). Also I didn’t explore full extend of locale problems. My solution proposal is to change tablename.toLowerCase() to tablename.toLowerCase(englishLocale). Of course I may not be aware of different impacts this will cause.