нету никаких хитростей. По умолчанию должно работать. Разрешение на доступ к файловой системе - policytool и файлы *.policy в конфиге. Собственно, какая ошибка выходит?

Tyo
Известны примеры практич реалиазции?
Да, представьте себе:-) Специально для Вас только что проверил. У меня чаще всего это встречалось, когда приложение использует файловую систему, и при установке на кластер это лень исправлять, приходится расшаривать сетевую папку. Единственный раз давно была проблема, с другим J2EE сервером (не WebSphere AS) связанная с тем, что я пытался писать в файл, на который не было доступа на запись, или хитро обращался, не указав пароля.
Когда Вы написали, что на встроенном сервере работает, а на продакшн нет, я подумал что разница лишь в настройках (policy) WAS, т.е. два почти одинаковых экземпляра WAS, один работает, а другой -нет. Эти настройки - стандарт для java и разграничивают возможности расширенной "песочницы" JVM (можно запретить писать в любую папку)- например по умолчанию Вы не можете в своем приложении вызвать System.exit. Возможно, в тест энвайронменте у Вас совершенно другой сервер.
Но если у Вас ошибка FileNotFoundException , то это может быть лишь по одной причине. По пути, указанном в конструкторе java не может найти файлы и Вебсфера (не подумайте что я ее защищаю ) здесь не причем. Здесь надо смотреть на настройки виндоувс и прочих вещей, которых я не знаю. Например, Виндоувс запомнила новый логин/пароль к папке,а для Вас прозрачный доступ. Самое крайнее средство здесь - мультиплатформенная обертка над smb(jcifs.samba.org)
Victor Metelitsa
Виктор, я, к сожалению не понимаю, что Вы пишете. Вы предполагаете, что я воткну 23 устройства в сервер, чтобы папка под буквой Z поменялась? О каких сервисах Вы говорите?
К сожалению, автор не написал ни версии продукта, ни стек трейс, ни куска кода, сложно понять какая у него проблема.
Всем хорошего отпуска :-)