nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

CSWorkarea.submitDirect() failing with null pointer exception

System

TS 6.7.1
Solaris 10

****************************************** Added after initial post ********************************

Caveat to original post...

The operation that appears to be turning these files from not modified to modified in the GUI is a MetadataTask in the workflow (WFM). Even if you don't change any of the metadata, it saves the files and then they show up as modified in the CC GUI (when nothing about the file appears to have actually changed). So since I have no control over the MetadataTask, but I do want to have a MetadataTask in the workflow for the users to be able to change certain metadata, what, if anything, can I do to make it so the MetadataTask only saves the files if the metadata actually changes? Anyone? Anyone? Beuller?

****************************************************************************************************

We have a process in our workflow that performs a submitDirect() if any of the files attached to the current task are modified. We found a scenario that occurs when files are appearing as modified in the CC GUI (the little pencil icon is showing, and they show up when you view modified files in the GUI), and the code preceeding the submitDirect is detecting these same files as modified, but when the submit is called, the code fails with a null pointer exception in this method:

 
java.lang.NullPointerException
  at com.interwoven.cssdk.sci.filesys.CSWorkarea.submitWithFileAndDirHandling(CSWorkarea.java:374)
  at com.interwoven.cssdk.sci.filesys.CSWorkarea.submitPathList(CSWorkarea.java:241)
  at com.interwoven.cssdk.sci.filesys.FileServiceWorkareaSciImpl.submitDirect(FileServiceWorkareaSciImpl.java:146)
  at com.interwoven.cssdk.sci.filesys.FileServiceSciImpl.submitDirect(FileServiceSciImpl.java:4492)
  at com.interwoven.cssdk.filesys.java.FileServiceAdapterImpl.submitDirect(FileServiceAdapterImpl.java:612)
  at com.interwoven.cssdk.filesys.impl.CSWorkareaImpl.submitDirect(CSWorkareaImpl.java:304)
  at com.swa.ecm.workflow.tasks.PublishTask.executeTask(Unknown Source)
  at com.swa.ecm.workflow.tasks.WCMTask.execute(Unknown Source)

When I compare the files in CC, there is not a thing different between the version in the workarea and the version in STAGING - only that the version in the workarea is 6+ and the version in STAGING is 6. Everything else matches exactly. So really there is nothing "modified", but TeamSite is still showing the files as modified, but it appears that submitDirect is not seeing these files as modified, so it's got an empty list of files and crashes. At least I think that's what's happening.

Here's the lines of code that performs the submitDirect:

[left]

 




if(numberModifiedFiles > 0) //only submit attached files to staging if something has been modified. otherwise an NPE will occur in the CSSDK API.

{ 

 //Submit the attached files to staging

 workarea.submitDirect(getSubmitComment(), null, submitFiles, SWorkarea.OVERWRITE_ALL);



[/left]






}

[left]

[/left]

Has anyone come across anything like this?

Find more posts tagged with

Comments

Migrateduser

And another thing....

Why would submitDirect() throw a null pointer exception when it attempts to submit unmodified files? Wouldn't it make more sense and be a better function if it simply didn't do the Submit operation and returned a return code that indicated no Submit was performed due to no files being modified? It is unacceptable for this function to throw an exception when it is very possible that someone could attempt to submit a list of unmodified files. It should do something gracefully - not kill your process.

Migrateduser

IW Support is still "working" on this problem. We were able to use a workaround by wrapping a try/catch block around the submitDirect() method call and basically ignoring any NullPointerException. I am not expecting big things from my support engineer as I can barely understand a word he says. That is SO irritating to me when I have to say "I don't understand what you just said" after every single thing he says.

Nipper...we need to go have several drinks...

vpatel

I have seen this exact behavior as well: when you submit an unmodified file, it throws an exception. I did the exact same workaround -- used try / catch and in the catch did nothing but just log that we actually encountered that error on a particular file.

I have seen this on two different TS instances and you've seen it now -- perhaps this is a bug. I'll see if I can file it or if you have an active case w support have them file it for you.

Migrateduser

Thank you. I am of the opinion that it is a bug as well. It's even worse in that the rest of the functions believe the files are modified, and so does the TeamSite UI as the modified (pencil) icons appear by the files. Yet the submitDirect() method is apparently using a different algorithm and thinks they are not modified. And even if the files were all unmondified, it shouldn't throw a NullPointerException - it should return gracefully with a return code indicating it found something it didn't like.

My case number is 707024. I'm not sure my support guy understands this enough to make the determination that it's a bug.

piyush_mit

Hello,
I am getting the NPE even on submitting the file for the first time to Staging :-(
Did anyone got some inputs regarding the strange behaviour of "submitDirect".

Cheers,
Piyush

Thank you. I am of the opinion that it is a bug as well. It's even worse in that the rest of the functions believe the files are modified, and so does the TeamSite UI as the modified (pencil) icons appear by the files. Yet the submitDirect() method is apparently using a different algorithm and thinks they are not modified. And even if the files were all unmondified, it shouldn't throw a NullPointerException - it should return gracefully with a return code indicating it found something it didn't like.

My case number is 707024. I'm not sure my support guy understands this enough to make the determination that it's a bug.

Migrateduser

Evidently a bug has been filed, but they would not give me the bug number.