Appian Nested CDTs and Java Plugin Objects Not Mapping Properly

RE: Appian Nested CDTs and Java Plugin Objects Not Mapping Properly

DanielH — Tue, 02 Dec 2025 19:39:07 GMT

As shown in the screenshots, process model input is type AttachmentList. Top-level complex type AttachmentList directly contains the Attachments element with no extra wrapper element level. The Java field is @XmlElement(name=Attachments") List<AttachmentDescriptor> attachments.

I also had already tried deleting and recreating both CDTs from the XSDs and redeploying a freshly built JAR to eliminate any cached definitions.

When I tried printing the attachmentList object in the Java code, it returned "placeholder.AttachmentList@3ce56992" and attachmentList.attachments was null. Is that to be expected? Wondering if it could be due to a mismatch in TypedValue between Appian and Java.

RE: Appian Nested CDTs and Java Plugin Objects Not Mapping Properly

DanielH — Tue, 02 Dec 2025 19:35:00 GMT

When I tried printing attachmentList, it returned "placeholder.AttachmentList@3ce56992" and attachmentList.attachments was null. Is that TypedValue to be expected?

RE: Appian Nested CDTs and Java Plugin Objects Not Mapping Properly

Shubham Aware — Tue, 02 Dec 2025 06:46:04 GMT

Confirm the process model input is type AttachmentList, not Any Type.

Ensure the top-level complexType AttachmentList directly contains the Attachments element (no extra wrapper element level), and that the Java field is @XmlElement(name="Attachments") List<AttachmentDescriptor> attachments.

Then delete and recreate both CDTs from the XSDs and redeploy a freshly built JAR to eliminate any cached definitions.

RE: Appian Nested CDTs and Java Plugin Objects Not Mapping Properly

maisieb646600 — Tue, 02 Dec 2025 03:39:00 GMT

I’ve run into similar mapping quirks when working with Appian CDTs and Java plugins. Sometimes the issue comes from a subtle mismatch in namespace or type name between the XSD, CDT, and plugin annotations. You might also want to log the raw TypedValue inside the plugin to see what’s actually arriving. When I’m stuck debugging odd behaviors, I usually take a break with Football Bros to clear my head, then come back with fresh eyes.

RE: Appian Nested CDTs and Java Plugin Objects Not Mapping Properly

DanielH — Mon, 01 Dec 2025 19:51:46 GMT

Thanks for your response, but I believe the Java list field already matches the CDT/XSD element name exactly.

From the screenshots I included:

-AttachentList.java already uses @XmlElement(name = "Attachments") on protected List<AttachmentDescriptor> attachments;.

-AttachmentList.xsd already has <xsd:element maxOccurs="unbounded" minOccurs="0" name="Attachments" type="tns:AttachmentDescriptor">.

I had also tried making AttachmentList.java use propOrder = { "Attachments" }, in case propOrder was case sensitive but that did not work either. Do you have other ideas?

RE: Appian Nested CDTs and Java Plugin Objects Not Mapping Properly

Shubham Aware — Mon, 01 Dec 2025 09:24:48 GMT

The Java list field must match the CDT/XSD element name exactly.
Make AttachmentList.java use @XmlElement(name="Attachments") on protected List<AttachmentDescriptor> attachments;.
Ensure AttachmentList.xsd has <xsd:element name="Attachments" maxOccurs="unbounded" type="tns:AttachmentDescriptor"/>.
Regenerate CDTs, redeploy the plug‑in, and rebind the process model input so getAttachments() returns the items.

Let me know if this works for you..