В большом swing приложении, состоящем из множества библиотек, выбрасывается исключение, в трассировке которого нет классов приложения, а только классы из пакетов  java. Как искать место, где исключение выбрасывается? Что-то менее трудоемкое, чем смотреть код всех компонентов и искать ссылки на BoxView, можно сделать? 

Пример:




Это сообщение отредактировал(а) COVD - 12.1.2011, 18:25

Без анализа всех признаков, знания, когда именно это происходит и исходных кодов по трейсу вряд ли что получится. Видимо где-то есть пустая коллекция, в которой есть попытка доступа к элементу. Может быть это ArrayList.

Странная ситуация. Исключение в UI-делегате текстового поля при попытке выложить составляющие этого текстового поля. А в каких случаях такое происходит?

Кстати, не пробовали версию Java менять?

COVD, код в студию!

Я подобные симптомы наблюдал в том случае, когда Swing-компоненты параллельно вызывались не только из EDT, но и из рабочих потоков. А Swing, как известно, однопоточный toolkit.
Мне удалось эту ошибку найти практически случайно, в общем случае могу порекомендовать воспользоваться профайлером.

Это исключение обнаружено в логах удаленных клиентов (WebStart). Уточнить обстоятельства события у пользователей нереально. И это далеко не у всех возникает. Воспроизвести даже не пытаюсь. Возможно, это один из компонентов, отображающих хтмл, потому что BoxView является родителем некоторых классов из  javax.swing.text.html . Напрямую он вроде нигде у нас не используется.


Там "зоопарк" начиная с 1.6-оем (мак, видимо) и до последнего апдейта. Спасибо, надо посмотреть, на какой версии срабатывает. 

PS. Зависимости от версии не обнаружил. Наблюдается на разных апдейтах 1.6
  

Слишком много его.


Такая ситуация не исключена. Спасибо, учту.



Это сообщение отредактировал(а) COVD - 13.1.2011, 18:29

Не возможно, а точно. BoxView используется для рендеринга HTML в том же JEditorPane или схожих компонентах содержащих "rich" content.

Вылетать такая вещь может в связи, с изменением содержимого такого компонента (например JEditorPane) вне AWT event dispatching thread'а.
(Об этом уже писали выше - "когда Swing-компоненты параллельно вызывались не только из EDT, но и из рабочих потоков")

Без непосредственного воспроизведения ситуации Вы врядли что-то сможете сделать с этой проблемой.
Начинать все смены контента пихать в "SwingUtilities.invokeLater" вероятно тоже не вариант.

Так что Вам необходимо конкретное воспроизведение проблемы, иначе это просто "пальцем в небо".

P.S. Эта ошибка что-то наворачивает, или Вы ее просто в логах усмотрели? 
Просто если она ни на что визуально (повисший интерфейс, кривая отрисовка и т.п.) не влияет и возможности воспроизвести у вас вообще нет - можете не обращать на нее внимания.
Если влияет, но никакой возможности ее отследить нет - не знаю какие еще можно предложить варианты... 
Только повториться - отслеживайте, как найдете корень - пишите 

Это сообщение отредактировал(а) mgarin - 13.1.2011, 17:32

Да, "просто в логах усмотрел" ( вроде пока никто не жаловался  ). Гипотеза убедительная, буду искать эти компоненты. Потом сообщу результаты. Спасибо.

Вообще насчет "Начинать все смены контента пихать в "SwingUtilities.invokeLater" вероятно тоже не вариант" я погорячился.
Зависит от того, где и как у вас используется замена текста в JEditorPane (если я угадал?).

Если это что-то наподобие Rich-text редактора с тулбаром, с которого могут заносится изменения - то это как раз тот случай, 
когда полюбому нужно оборачивать все изменения в SwingUtilities.invokeLater.
Впрочем то же самое и если у вас параллельно работает несколько потоков, изменяющих данные в поле.

Только не забывайте, что SwingUtilities.invokeLater добавляет исполняемый код из имплементации Runnable в AWT Event queue
и выполнение текущего потока продолжится сразу же после вызова, не дожидаясь исполнения кода из имплементации Runnable.
Если вам нужно дождаться непосредственно исполнения - есть 2ой вариант - SwingUtilities.invokeAndWait

Нашел JEditorPane.setText(), но "This method is thread safe, although most Swing methods are not."
Но возможно найду и другие варианты. 
В большинстве случаев делается асинхронный запрос на сервер и полученный ресурс отображается. Никакого редактирования текста пользователем не должно быть.

посмотрел я этот метод, там конечно написано, что он Thread safe... Но что-то терзаю меня смутные сомнения...

Плюс, возможно у вас где-то берется Document у JEditorPane и ведется работа с ним напрямую?
Потому Вы могли и не найти более setText...

да, я нашел setDocument(), про который ничего не сказано относительно потокобезопасности, но то, что нашел, в  EDT обрабатывается. Буду продолжать искать.  

Это сообщение отредактировал(а) COVD - 13.1.2011, 21:13