Expand my Community achievements bar.

Enhance your AEM Assets & Boost Your Development: [AEM Gems | June 19, 2024] Improving the Developer Experience with New APIs and Events

Document is in disposed state! - accessing a Document workflow variable


Level 7

We have written a custom workflow step.  It has the following code.  The idea is to save a Document variable to the Payload directory.

In Java, we are trying to read in the Document variable.


Document doc = (Document) wfd.getMetaDataMap().get(docDataVariableName);
log.info("Document is a variable name: " + docDataVariableName);
log.info("Document information content type: " + doc.getContentType());


It fails when accessing doc.getContentType();


java.lang.IllegalStateException: Document is in a disposed state!
at com.adobe.aemfd.docmanager.Document.checkDisposed(Document.java:236) [adobe-aemds-core-docmanager:3.0.94]
at com.adobe.aemfd.docmanager.Document.getContentType(Document.java:383) [adobe-aemds-core-docmanager:3.0.94]
at com.s360g.aem.workflowcomponent.custom.saveDocumentToPayload.execute(saveDocumentToPayload.java:74) [com-s360g-aem-workflowcomponent.core:]


We have similar problems in other components too - all when accessing the Document variable from a workflow.


I had a previous post that says this was a bug in 6.5.9 - I have upgraded to 6.5.12 and still having the issue.  I have opened a ticket: 000626337 but, I would love any feedback ahead of answering the ticket.  It's a big blocker in our project.



9 Replies


Employee Advisor

@crich2784 which service is it? output, forms, dor?


Level 7

It is not a service producing the Document.  We have built a custom component to read a file from filesystem into a document variable.


Document doc = new Document(inFile);
wfd.getMetaDataMap().put(documentVariableName, doc);


This is the code to set the Document variable in the "read file from filesystem"


Level 7

No.  All OSGI and windows.  I updated the case with source code, jar, dialogs and test workflow.  






@crich2784 Will it be possible for you to share the code for the custom workflow step? Are you calling document.dispose() anywhere in your code? How are you creating the document object? Most likely, this is not a product bug but issue in the custom code.


Level 7

@sharoon23  the code is super simple and I have a 1 step workflow to exploit the issue.  It has been submitted to Adobe support.  After reading my dialog variables, this is the code to read the file from the filesystem and put it into a Document variable in the workflow.  The document variable in the workflow is not be accessed prior to this component.


log.info(" Creating File variable using this path: " + path);
File inFile = new File(path);
if(inFile.exists() ) {
log.info(" File exists - proceeding with setting process variables.");
if ( fileExistsVariableName.length() > 0 ) {
log.info(" Setting variable fileExistsVariableName to Boolean.TRUE" );
wfd.getMetaDataMap().put(fileExistsVariableName, Boolean.TRUE);
log.info(" Creating Adobe Document from java File.");
Document doc = new Document(inFile);
log.info(" Document created with content type " + doc.getContentType() + " and maxInlineSize " + doc.getMaxInlineSize());
//Path filePath = Paths.get(path);
//com.adobe.aemfd.docmanager.Document doc = new com.adobe.aemfd.docmanager.Document(Files.readAllBytes(filePath));
wfd.getMetaDataMap().put(documentVariableName, doc);



I have observed that - in the custom LogVariable step, the document variable is converted to String since the default value supplied to metadataMap.get() is a String.

This conversion of the document to String is not recommended since the workflow engine tries to convert it to JCR Value and then the JCR Value to string. The workflow engine closes the document whenever serialization of the document to Value is done. So, when the next step tries to read the document to save it under the payload, it fails.

Even though the document variable is created/initialized by the custom workflow step, its lifecycle is under the control of the workflow engine and the engine has to take care of closing the document on serialization to avoid memory/performance issues.

It is recommended to do the below:

VariableTemplate varTemplate = workItem.getWorkflow().getWorkflowodel().getVariableTemplates().get(variableName);
if(varTemplate.getType().equals("com.adobe.aemfd.docmanager.Document") {
 Document document = workItem.getWorkflow().getWorkflowData().getMetaDataMap().get(variableName, Document.class);
//Do custom work with document like getting inputstream, etc, not recommended to close} 

Alternately, the workflow engine can also retrieve the variable values with the correct type with just:

Object obj = workItem.getWorkflow().getWorkflowData().getMetaDataMap().get(variableName);
//Check the type of obj with obj instanceof Document.class and do further work, not recommended to close

If it is required to get the value as String/JCR Value, then the existing logic can be used, but the workflow engine would close the document, so it is expected of the custom code to reconstruct the variable value using what was retrieved earlier and set workflow metadata map again. This is not the recommended approach though.


The documentation will be updated in some time.