Just upgraded to Windchill 12.1 and I'm noticing an odd issue when additional files are downloaded from the representation. For some reason Windchill (or Apache) is dynamically replacing every space character with a plus sign (+). The additional files themselves do not include the plus sign in their names, and this can be seen by downloading the entire representation. I dug through the preferences thinking maybe this is something new, but I'm not finding anything. Please let me know if you have seen this before or have any idea what might be causing it. Thanks!
This is due to a code change in class: com.ptc.windchill.enterprise.wvs.repsAndMarkups.commands.ListRepFilesController
Within the download URL which constructed by the class:
Replace the class by the one from a previous release could temporally workaround this symptom, however, is not officially supported.
In some rare scenario, for example, whenever a filename is something like "xyz-balabala%.pdf" (filename has a '%' just before the '.') then without the 'URL encoder' method, such data will be failed to be downloaded. Considering in most of time, chance of such case is very small, so no worry about this new updates.
Then develop a solution that deals with that one special case but don't arbitrarily replace all spaces everywhere in every file downloaded. Don't use a sledgehammer when a scalpel is needed.
"%" is not a supported character for much of Windchill. I'm not sure why development is trying to add support for it during file downloads. Maybe someone needs to simply push back and say, 'don't use % in filenames per the existing documentation'. Single space characters ARE supported. Windchill should not be altering filenames that include single space characters.
The following characters have special meaning in the system and should be avoided...
Also adding more than one space between letters can also cause an error.
I would add one more thing.
Windchill is a commercial product, so problems should be solved from the perspective of benefiting customers and not developers.
For those who may be interested, an SPR has been filed and a corresponding KB article created.
I was able to use a class file from a 12.0 system to get around the issue for now.
Not sure. It was an intentional (undocumented) change by PTC, so first I have to convince them that it was a mistake to make the change in the first place.
This should be coding mistake with no doubt, although it has a good intention.
Before a Windchill CPS or MOR be released at sometime to fix this issue officially. Replace the class by one from 12.0 or ealier is the easiest way ( without URLEncoder method).
Replace with the attached class (with URLEncoder, and the 'space to +' issue fixed).
Btw, I'm not from R&D dep, just interested in this as a pure technical discussion : )
Replace the class by one from 12.0 or ealier is the easiest way ( without URLEncoder method).
Yeah, I did. I'm running the one from my previous 220.127.116.11 system for now. Thanks.