Issue with Apigee-Java-MultipartForm-V2 on Apigee ...

EdwinFerreira

Master dchiesa1, I hope you’re having a great day.

I am currently using the Apigee-Java-MultipartForm-V2 JAR, and it works perfectly in my local environment. However, when I deploy it to the Dev environment on Apigee X, I encounter an error that prevents it from working.

Unfortunately, the error doesn’t provide much detail, so I’m not sure what could be causing the issue. I am attaching a screenshot for you to see what’s happening.

Could you guide me on what might be going wrong? And if you need more context or information, I will gladly provide it.

Thank you in advance for your help!

Best regards.

dchiesa1

hi Edwin

I'm happy to have a look. I know there have been some changes to the restrictions that Apigee X applies when dealing with Java callouts. That has caused some previously working callouts to stop working. In some cases we are able to get them working again with a recompile. This may be what is required in your case?

First, I guess you are using this callout. https://github.com/DinoChiesa/Apigee-Java-MultipartForm-V2

What version are you using? have you pulled the latest? I recently updated this callout to v20250404 . I made some changes to handle a specific variant of the Content-Disposition header. And took the opportunity to update some other things as well. I tested this on my Apigee X environment, and it worked for me.

The JARs I included in the API proxy bundle were:

apigee-multipart-form-20250404.jar
javax.json-1.1.4.jar
javax.json-api-1.1.4.jar

Can you please:

check the version number of the jar you are using
check that your policies reference the updated jar
check that your proxy does not include the old version of the jar and does include the latest version
check that the proxy also includes the javax.json jars as part of the Java/resources

if none of that solves your problem, show me the configuration you are using in the Java callout policy file.

EdwinFerreira

Hi Dino,

Thanks a lot for the quick response. I’ve gathered everything in one place so you can see the full picture.

JARs currently packaged in the proxy

javax.json-1.1.4.jar

javax.json-api-1.1.4.jar

apigee-custom-base64-20210409.jar

jc-crea**multipartform-multi.jar ← renamed copy of apigee-multipart-form-20250404.jar

Why the different name?
When my CI pipeline deploys a revision that contains apigee-multipart-form-20250404.jar, Apigee X always fails with the same error. The only workaround I’ve found is to create a new revision, upload the JAR manually, and rename it to jc-create**ltipartform-multi.jar. Keeping the original name makes the error persist, as if the previous version were cached.

Java call-out configurations

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JavaCallout name="jc-creat**ultipartform-multi" continueOnError="true">
  <DisplayName>jc-crea**multipartform-multi</DisplayName>
  <Properties>
    <Property name="descriptor">
        {
            "metadataValues": {
                "content-var": "metadataValues",
                "content-type": "text/plain",
                "want-b64-decode": false
            },
            "primaryFile": {
                "content-var": "input.archivo.contenidoBase64",
                "content-type": "{archivo.formato}",
                "want-b64-decode": true,
                "file-name": "{archivo.nombreArchivo}"
            }
        }
        </Property>
    <Property name="destination">message</Property>
  </Properties>
  <ClassName>com.google.apigee.callouts.MultipartFormCreatorV2</ClassName>
  <ResourceURL>java://jc-create**ltipartform-multi.jar</ResourceURL>
</JavaCallout>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Javascript continueOnError="false" enabled="true" timeLimit="200" name="js-extractDataSuccess-response">
  <DisplayName>js-extractDataSuccess-response</DisplayName>
  <Properties/>
  <ResourceURL>jsc://js-extractDataSuccess-response.js</ResourceURL>
</Javascript>

Behaviour summary

Environment Multipart JAR (jc-crea**multipartform-multi.jar) Base-64 JAR (apigee-custom-base64-20210409.jar)

Local (VS Code + Docker)	Works at first; after several consecutive redeploys it throws a NullPointerException (no stack trace).	Always works.
Apigee X via CI pipeline	Fails on every deploy. Only works after I create a new revision and manually upload and rename the JAR.	Always works.

I added extra logging inside the catch blocks of the multipart library, but the Docker logs still only show the bare NullPointerException.

My questions

Could this be related to how Apigee X caches JARs or handles class loading across revisions?
Do you see anything odd in the XML configuration above?
Is there additional logging I can enable (or flags I can set) to get more insight?

I can provide the full proxy bundle or any other logs you need.
Thanks again for your help!

dchiesa1

Wow, that's a puzzle.

I don't have any insight there. I would suggest you separate the two problems. You're seeing a NPE with one of the callouts, some of the time. And also, you're seeing a failure to deploy on the other one, but mysteriously, it seems to be related to the name of the JAR you are using.

Those are both puzzles but I don' t know if they are directly related. If I were you I would work to diagnose each of them separately.

And unfortunately I think you've taken it about as far as you can independently. The next step is to contact Apigee support and get their assistance. They will be able to turn on some debugging for your environment and maybe get some additional insight as to why the JAR is failing to deploy.

On the NPE problem, when faced with a surprising NPE, what I try to do is just surround my code with try...catch and set a variable or log a message.. You can re-throw the exception if you like, but the extra diagnostics emitted into the message context will help you understand what's going on.

Are you using both of these JARs together? If I were you I would try to separate them, if possible, into separate proxies and separate deployments. Isolate the problem with Base64 NPE and solve that separately from the failure to deploy.

Sorry I cannot be of more help. Good luck .