Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Strange Error writing file with CSSDK
Bill Klish
TeamSite 6.5 SP1
Windows 2003 EE
I have an external task that is being called from a workflow that is based on the CS SDK and getClientForTrusted user method. As bowker has told me in other posts, you need to pass the username into the task to get the client. I have successfully done that. Here is the problem, if I basically make the command line "" in the workflow and run it from a cmd window, everything works correctly and the file is written back into TeamSite.
However, if I put the exact same command line into the wft and have it run normally, I get an exception thrown and the exception's message is null.
Here is the code that is throwing the exception (contents is just a String defined above)
try
{
OutputStreamWriter out = new OutputStreamWriter(simpFile.getOutputStream(true), "UTF-8");
out.write(contents);
out.close();
}
catch (Exception ex)
{
logger.error("Failed writing text file: " + ex.getMessage());
throw new IOException("Failed writing text file: " + ex.getMessage());
}
Some notes:
- The file already exists in TeamSite prior to attempting to write it back in. It is owned by the user Administrator (who is the same person running this task)
- The class is being invoked with the JRE provided by interwoven in iw-home/tools/java/jre/bin/java
- Using the JNI connection and the CSLocalFactory
Find more posts tagged with
Comments
Bowker
You have been bitten by the same bug I was.
Even though you have used "get trusted client" to sign on, the processes running in the background are still running as "system" or some other user. The file actions you are attempting to do are being executed as that user, not as yourself. I'm not sure what the ID is for an external task from a workflow, but as a test, set World:WR on that file (& path?) and see if that works.
I believe you will find this bug will be fixed in 6.7.
Dan Bowker
Northern Trust
Web Publishing Technology
Bill Klish
Yeah, I did a dump of the System properties and found that at the command line, user.name is Administrator, but when run through the workflow, user.name is System. I tried adding System to the security set at the top leve of Y:, but it wouldn't work. I did it at the main level, but the SYSTEM user only went down to the directory level, rather than the file level. Not sure how to fix that, but once I added SYSTEM to the specific file it was trying to right, all was well.
So, outside of waiting for 6.7 to come around, and then hoping my client will upgrade, there is no resolution for this?
Bill Klish
Had another thought. If I wrap the java call in Perl program, would that take care of the problem? I have written many perl external tasks that copy files and do other things and I don't remember permissions being an issue. I guess they may have been using the interwoven provided clts, which might be doing the user switching for me. Should I give this a try?
Bowker
I doubt that will work - CSSDK will still be doing the "work". Try it, I've been wrong in the past.
Dan Bowker
Northern Trust
Web Publishing Technology
Bill Klish
You are correct. JVM still being loaded as user SYSTEM. I guess we just have to wait for 6.7.