ODK Aggregate v2.00 - Possible Bug in Generated WAR File

I have just busted by head trying to debug ODK-Aggregate-v2.0.0-Linux-x64.run.zip. My server was running ODK v1.7.0 on Ubuntu Server 18 previously and I used the ODK-Aggregate-v1.7.1-Linux-x64.run.zip for my next hop. Ran the RUN file, generated the WAR and plopped it into my /opt/tomcat/webapps folder and restarted, everything worked beautifully.

Then I repeated the exact same steps to go from v1.7.1 to v2.0.0 and everything broke. I kept getting the redirect to a 404 Not Found when going to https://myodkserver.local:8443/Aggregate.html.

Then I checked the Tomcat log files /opt/tomcat/logs/Catalina.out

WARNING: Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'dataSource' defined in class path resource [odk-settings.xml]: Could not resolve placeholder 'jdbc.driverClassName' in string value "${jdbc.driverClassName}"; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'jdbc.driverClassName' in string value "${jdbc.driverClassName}"
Feb 28, 2019 1:44:50 PM org.springframework.web.context.ContextLoader initWebApplicationContext
SEVERE: Context initialization failed
org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'dataSource' defined in class path resource [odk-settings.xml]: Could not resolve placeholder 'jdbc.driverClassName' in string value "${jdbc.driverClassName}"; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'jdbc.driverClassName' in string value "${jdbc.driverClassName}"
at org.springframework.beans.factory.config.PlaceholderConfigurerSupport.doProcessProperties(PlaceholderConfigurerSupport.java:223)

So the I did some troubleshooting and noticed that there were missing lines in the jdbc.properties definition file!!

This is the file from v1.7.0 and v1.7.1 is similar:
jdbc.driverClassName=org.postgresql.Driver <<--- This Line missing in 2.0.0
jdbc.resourceName=jdbc/odk_aggregate <<--- This Line also missing in 2.0.0
jdbc.url=jdbc:postgresql://127.0.0.1/odk_prod?autoDeserialize=true
jdbc.username=odk_user
jdbc.password=meinP@ssw0rt!!!
jdbc.schema=odk_prod_schema
jdbc.help.about=Generated on 2018-11-01T11:58:38-0700 for MeinODK ODK Aggregate v1.7.0

This is the file in v2.0.0 notice the two lines missing above!!!
jdbc.help.about=Generated on 2019-02-28T10:13:12-0800 for MeinODK Aggregate v2.0.0
jdbc.url=jdbc:postgresql://127.0.0.1/odk_prod?autoDeserialize=true
jdbc.username=odk_user
jdbc.password=meinP@ssw0rt!!!
jdbc.schema=odk_prod_schema

The Tomcat was unable to find ${jdbc.driverClassName} and thus unable to query the database and thus unable to start the listener leading to the 404 Not Found because those two lines were missing in jdbc.properties.

To fix it:

  1. I first ran the RUN file using all the original settings I entered the first time I ever installed ODK Aggregate to get the WAR File.

  2. Extract the WAR into a new folder (I called it mod) using the jar -xvf commando

  3. Go into the ./mod/WEB-INF/lib folder

  4. Create a mod-settings folder and extracted ODKAggregate-settings.jar into there

  5. Modify the jdbc.properties file adding back the two missing lines
    jdbc.driverClassName=org.postgresql.Driver
    jdbc.resourceName=jdbc/odk_aggregate

  6. Repackage the modified ODKAggregate-settings.jar file being careful not to include the mod-settings folder into the root of the archive. I did this while in ./mod/WEB-INF/lib/mod-settings by running the command

--> jar -cvf ,,/ODKAggregate-settings-2.jar *

  1. Go back to ./mod/WEB-INF/lib and delete the broken ODKAggregate-settings.jar file and rename the one we just made

--> rm ODKAggregate-settings.jar
--> mv ODKAggregate-settings-2.jar ODKAggregate-settings.jar

  1. Repackage the repaired ODKAggregate.war file by going back to ./mod and running the command
    --> jar -cvf ../ODKAggregate.war *
    Which will place the newly created war file one directory up, in order not to include the mod directory in the root of the web application.

  2. Redeploy the ODKAggregate.war into /opt/tomcat/webapps

  3. Test and it should be working!

I don't understand how such a bug got into the final build. v1.7.1 was fine. v2.0 beta0 has even a bigger problem in that it calls the database using odk_unit username instead of odk_user, and odk_db instead of odk_prod database i.e. the settings you entered during the RUN / WAR file generation are ignored.

2 Likes

@gt3o0o Thanks so much for your troubleshooting! You are correct that this is a bug. It's been filed at https://github.com/opendatakit/aggregate/issues/429 and my goal is to have it fixed in the hot fix that's coming out in a few days.

1 Like

Thanks a lot, @gt3o0o!

We're tracking this issue back at https://github.com/opendatakit/aggregate/issues/429 and we've already filled a PR fixing this at https://github.com/opendatakit/aggregate/pull/432

Hopefully we can just replace the installers during the next hours, since the code of the release is OK.

2 Likes

By the way, in case anyone (@gt3o0o) wants to test the fixed installer, here are some links:

Also, let me say I'm sorry you got frustrated with the experience of updating to v2.0! We work really hard to make it as smooth as possible. Aggregate is a complex piece of software and there are many things we need to check and verify and just so much time and resources to do it.

In this case, it was an installer issue, and the other issue with the XSRF log messages you've reported at Error deploying ODKAggregate,war file in apache tomcat - #5 by gt3o0o is easily fixed by cleaning your browser's cache. As you can see, neither of those issues were directly related to Aggregate's code, but to something else (the installer, the browser), and we often can't test those thoroughly as we'd want because it requires different setups that we can't possibly emulate.

We need help to make sure these things don't happen and that's why we run the beta pre-releases for some time before doing an official release. v2.0 beta run for almost one month during January. It would be great to have your help, @gt3o0o, @Vijayalakshmi, and all the other user's help during the next beta testings to prevent releases with problems such as the ones we're talking about now.

3 Likes

I talked to @ggalmazor and we won't be replacing the installers. If we caught this right after the release, then maybe, but I don't love the idea of having a v2.0.0 from last week and a v2.0.0 from this week having different behavior.

We will fix this issue in v2.0.1 which will be in testing tomorrow and I'm hoping will be out on Wednesday. And speaking of testing, Guillermo is correct, there are a lot of moving pieces and we can't get everything. The best we can do is to react quickly when there is a problem and make sure this class of mistake doesn't happen again. We'll add this scenario to the testing plan to ensure that.

@gt3o0o I really appreciate you reporting this bug so we can get it fixed. We'd love your help trying our future beta releases so mistakes like this don't make it into the final build.

2 Likes

Thanks for confirming the bug! I am glad I didn't miss any steps or do something terribly wrong to get that error.

I will test out the next release v2.0.1 when it comes out and let you know if I experience any more issues.

Cheers!

2 Likes

Hello @gt3o0o,

Thanks for explaining and troubleshooting the bugfix in 2.0.0 version. I completed the steps and deployed the war file again on tomcat 8.5 but now im getting a new error stating failed to start component. Attached the log file for your reference.

Also im using the 7.zip for extracting and repackaging the jar and war files.

Kindly guide if some step is missing or some additional steps required to resolve this.

Thanks in advance.
ODKAggregate Deploy Error.txt (9.1 KB)

Hello @usfreak13

From the looks of the message in the log file "java.util.zip.ZipException: error in opening zip file" it looks like Tomcat is not recognising the format of the repacked WAR file.

Could you try using the "jar.exe" file to do the repack for both the WAR and the configuration JAR file that you made changes to?

It should be located under the JAVA JDK install path or "JDK_HOME\bin", if you have set your PATH Environment Variable correctly you should be able to run this command without the need to be in that directory.

Aggregate v2.0.1 is out and it has a fix for the bug in the generated war. Special thanks to @ggalmazor and @kkrawczyk123 for their quick turnaround.

@gt3o0o and @usfreak13 perhaps you can try this version to see if the issue is resolved?

1 Like

Wow.. thanks for this info.. lemme try this new version and give my headsup on the process.

Cheers

Hi,

Unfortunately the jar.exe isnt doing the task. I tried to repack the .jar and then .war but its not deploying properly again there is some problem may be the .jar and .war files are not keeping the other required supporting links intact while repackaging.

Any fool proof solution on actually unpacking .war and .jar files and repackage them without loosing their original links and supporting class files.

Thanks in advance.

You shouldn't have to unpack and repack. v2.0.1 should give you a properly configured war.

@yanokwa @ggalmazor @kkrawczyk123

Hurray ..GOODNEWS.. Your upgrade verson 2.0.1 works like a piece of cake without a single error. Super kewl work guys.. cheers for fixing the bugs in no time..

I've installed and its showing great on Tomcat 8.5, Java 8, Postgres 10.7 works like a charm..

Kudos to the team..Cheers

3 Likes

@yanokwa @ggalmazor @kkrawczyk123

Very good news! It is working PERFECTLY! All the XRLF errors and the java placeholder errors are gone, my Enketo Webforms are also working beautifully.

Thanks for having this resolved so quickly!

4 Likes

A post was split to a new topic: Aggregate install on Ubuntu 16