Issues with java action compilation in AWS DynamoDB connector

0
I'm not sure what's happening here but I've been having a consistent issue with the AWS dynamoDB connector. I'm able to fix it temporarily but it keeps coming back. The issue: When building a package through the environment menu on my application's page to push to an environment, the java actions fail to compile properly. The temporary fix: I have a copy of the batchWriteItem.java file from a previous commit where this issue didn't happen. I go to MYAPP\javasource\amazondynamodbconnector\actions, delete the existing BatchWriteItem.java file, and replace it with my working batchWriteItem.java file (the case of the "B" is important). I then commit without running my application locally. I can then build a package with no issues. What breaks it again: as soon as I run my code locally, the java action is overwritten and reverted back to the not working version. What I have tried: I have tried changing the case of the "b" of my working file from batchWriteItem.java to BatchWriteItem.java. I have tried deleting my local copy of my application and pulling a fresh copy of the working version (that is able to compile the java actions) from the team server. I have tried updating my version of Mendix (currently on 10.24.26, we're not ready to move to Mendix 11 yet)I have tried reloading the dynamoDB connector from marketplace.I have tried completely deleting and re-downloading the dynamoDB connector from marketplace.What I am looking for:Is anyone else having this issue or a similar issue?What fixes can I try?I can use the temporary fix but it's annoying and inconvenient. I don't understand why the file is reverting back to a version that doesn't work, and why redownloading the connector from marketplace doesn't fix the issue.
asked
1 answers
0

Hi Hartley,


The behavior you're seeing is actually a good clue: Studio Pro is regenerating BatchWriteItem.java, so I would not treat this as a random compilation issue.


Mendix regenerates the Java files for Java Actions when the app is deployed/built. Code outside the supported generated-code sections can therefore be replaced. Mendix explicitly recommends keeping custom implementation code between // BEGIN USER CODE / // END USER CODE and extra helper code between // BEGIN EXTRA CODE / // END EXTRA CODE.


The DynamoDB Connector is also a likely factor here. The current Marketplace release history shows that version 3.0.0 changed its dependency handling: third-party JAR dependencies were moved into the module and removed from userlib.


I would check this in the following order:

  1. Compare BatchWriteItem.java from the working revision with the failing revision.
  2. Don't just compare the file after running locally. Check the actual Team Server revision.
  3. Check the BatchWriteItem Java Action in Studio Pro.
  4. If the Java code that works is outside:

// BEGIN USER CODE

// END USER CODE

then Studio Pro can regenerate it and bring back the generated implementation. Move custom code into the supported sections.

  1. Check the DynamoDB Connector version and dependencies.
  2. In particular, compare the working project and this project for:
Amazon DynamoDB Connector
AWS Authentication Connector
AWS SDK / related JARs
userlib contents

Don't manually add an AWS SDK JAR just to make the compilation pass if the connector version already manages that dependency. The connector changed its dependency management from version 3.0.0 onward.


  1. Clean the deployment directory and rebuild.
  2. A stale generated Java/dependency set can make this look like the source code is reverting. Mendix provides App → Clean Deployment Directory specifically for cleaning generated deployment artifacts.
  3. Check the actual Team Server revision.
  4. Since you mentioned that pulling a fresh copy gives you the working version, I would compare the commit/revision containing BatchWriteItem.java. If the working file isn't actually committed to the repository, another build/pull can naturally bring back the old version.

One important distinction: don't modify the generated Java file and expect that change itself to be permanent. Mendix states that code outside the preserved sections is regenerated on deployment.

So the fact that your temporary replacement works locally but gets reverted when you build a package strongly suggests that the source Java Action/dependency configuration in the project is still pointing to the old implementation.


I would start by comparing BatchWriteItem.java in the working Team Server revision vs the failing revision, and then check the DynamoDB Connector version/userlib differences. That should tell you whether this is a Java regeneration problem or a connector dependency/version problem.

Hope this helps.

answered