Стока всего наплели. Используйте отладку. Локализуйте проблему. Она в SOAP? Тогда при чему тут JSF и БД?
Покажите как именно портится текст.

Тут очевидно что UTF8 прочитан как CP1251, но кто не в курсе
берем
http://www.artlebedev.ru/tools/decoder/
и оно нам подтверждает.

Тем более удивительно что это происходит в Windows->Linux. В другую сторону я бы ещё мог понять.
Какими средствами происходит работа с SOAP?
Можете ли сделать дамп SOAP/HTTP в файл, и проверить содержимое файла на правильность кодировки.
Какое отношение к этому может иметь фильтр и что значит "перекодирует"?

Может у вас формируется текст под виндой в CP1251, ломая UTF-8, и вы своим фильтром восттанавливали обратно CP1251,
а при переходе не Linux отправка стала работать в UTF-8, но ваш фильтр всё ещё не верно трактует это как CP1251?
Что конкретно делает фильтр и как это относится к SOAP?

denis11111Вияснилось, що String в JAVA по умолчанию UTF-16.

facepalm... Это представление данных в памяти, оно к вашей проблеме вообще никакого отношения не имеет


denis11111


Это бред, потому что getBytes() использует текущую кодировку.
В вашем случае


Т.е. у вас был текст в UTF-8 и вы его невалидно интерпретировали где-то как CP1251.
Этой операцией вы пытаетесь восстановить данные делая преобразование в обратном порядке.
Получить из String CP1251 и интерпретировать как UTF-8.
Это костыль, при чем со своими побочными эффектами. Какие-то символы могут не восстановится в таком преобразовании. "Щ" что ли... не помню точно.


denis11111То крякозябры пропадают.
Вроде как и решение, но на каждую строку ставить такое как-то не выход...
Может есть какие идеи?
Всё традиционно. Проблему нужно локализовать и устранить. Локализация происходить двоичным поиском. Делим попалам - справа Win, слева Линь. Посередине SOAP. Далем дамп запроса и ответа. Смотрим кодировку. Определяем кто набочил.
Затем на нужном сервервере делем транзакцию пополам. Дебажим в середине и определяем текст сломан раньше или позже.
И так пока не выявим где именно проблема.

denis11111Так если так поставить то уже в Linux будут проблемы.
Во-первых. Я не говорю что это нужно делать. Это заплатка, причем, возможно, не работающая.

Во-вторых, вы где-то лукавите.
"РґРєРёР№" это UTF-8 текст, прочитаный как CP1251.
Charset.defaultCharset() везде UTF-8.
Тогда в вашем случае


это всё равно что


Что никак не может видоизменить текст.

В случае "РґРєРёР№" текст можно "исправить" как раз кодом
String unWrapAnswer = new String(unWrapAnswer.getBytes("CP1251"), "UTF-8");
Выходит Charset.defaultCharset() у вас где-то CP1251 и вы нас обманули.

denis11111Charset.defaultCharset() - это я делал проверку в простой програме с методом main, там "UTF-8".
Когда я закинул Charset.defaultCharset() в код веб приложения, то оказалось что там "windows-1251".
Да, только windows-1251 это нативное имя для NIO. Кроссплатформеное для ваших нужд именно cp1251.
Вот тут полный список
http://docs.oracle.com/javase/7/docs/technotes/guides/intl/encoding.doc.html
Иногда стоит по нему сверятся.

Это глобальное свойство JVM file.encoding. Вряд ли оно конфигуриуется на уровне отдельного модуля.
-Dfile.encoding в параметрах запуска glassfish