Здравствуйте . Подскажите, кто знает , как бороться с кэшированием апплета в Opera ? 
Делаю изменения в апплете , а в браузере -- без изменений . 
После удаления личных данных и закрытия - отрытия браузера - все нормально.
Нельзя ли подгружать новую версию апплета в Opera более простым способом.


С Mozilla и IE -- все нормально.

Это сообщение отредактировал(а) lihusha - 1.7.2009, 16:30

Ctrl+F5 не помогает?

имеется в виду в браузере ?
нет , не помогает

Что такое "личные данные"? Обновление кеша должно происходить так (при классическом описании апплета тагом applet) - браузер шлет запрос на сервер и получает время создания (версию) файла аплета (обычно это jar). Если версия отличается от имеющейся в кеше, то файл загружается и кеш обновляется. У меня было предположение, что иногда новая версия не запускается из-за ошибок в апплете и тогда запускается старая версия из кеша. После исправления ошибок (перекомпиляции) новая версия принималась. Но были также и случаи, что новая исправная версия не принималась некоторыми клиентами и им помогало очищение локального кеша (в панели java-plugin: ControlPanel->Java->General-> TemporaryInternetFiles). Для полного избавления от проблемы мы просто переименовывали jar файл, добавляя к его имени номер версии (соответственно надо редактировать html). Хлопотно, но надежно. 

А искать причину, почему именно в какой-то Опере что-то не срабатывает - тухлое дело. Пока разберетесь, выйдут новые версии и в Опере будет срабатывать, но не будет срабатывать в Оперетте. Хотя java-plugin и улучшен в последних версиях java (но и новых багов наверное добавили как водится), все же смешивать коктейль из технологий (html, апплет) лучше избегать. На мой взгляд. Надежнее что-то одно. Или html интерфейс, или java (например, WebStart).   

Спасибо , COVD, это действетельно надежный способ.


Что Вы имеете в виду ?
Вообще не использовать  апплеты ?

У Вас случайно не завалялась ссылка на туториал по WebStart для начинающих ?


Это сообщение отредактировал(а) lihusha - 3.7.2009, 12:25

Если значительная часть функциональности приложения приходится на апплет, то лучше перейти полностью на java WebStart. Наоборот, если апплет служит лишь небольшой добавкой к html интерфейсу (календарь какой-нибудь), то может быть лучше попытаться сделать то же самое на javascript. 

Однако Sun предприняло усилия по продвижению java в интернет и сейчас у апплетов уже нет былых ограничений по памяти и влияние браузера уменьшено, т.е. апплеты приблизились к возможностям WebStart приложения. Как на самом деле я не знаю, потому что мы давно отказались от апплетов в пользу WebStart. 

Кроме того, недавно появилась технология JavaFX, которая базируется на WebStart и работает в том числе и в браузере как часть html интерфейса. Это тоже альтернатива апплетам - http://javafx.com/samples/.



http://java.sun.com/docs/books/tutorial/de...tart/index.html





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

Весьма признателен Вам за информацию.

Добавлено через 14 минут и 30 секунд
Общая информация.
В моем случае в работе клиент-серверного приложения возникает исключение (повторюсь , только в опере).
Вот часть стектрейса данного исключения.



импорта com.opera.URLConnection и близко нет в моем исходнике...


Исключение возникло в сточке 



Так, апплет должен соединиться с сервером, но тут вмешивается браузер опера и подставляет какие-то свои данные.

Что сообщает исключение?

exception.getMessage() = имя сервера

Это сообщение отредактировал(а) lihusha - 3.7.2009, 23:57

  

Если это действительно проблема в Опере и люди с этим сталкивались, то поиск в интернете по тексту исключения даст ссылки на обсуждения. Также возможно это ваша неточность в применении HttpURLConnection - другие браузеры "прощают", а Опера - нет? Приведите код. 
Можно также посмотреть, что браузер отправляет-принимает с сервера для разных типов браузеров. Для этого надо установить анализатор сетевого трафика. Например, бесплатный http://www.wireshark.org/ .   

Часть кода метода , использующего HttpURLConnection

У вас ведь POST, а по умолчанию GET. Поэтому надо явно указать 

не помогло

Вы его в нужном месте поставили? 


Других гипотез у меня нет. Проверьте как-нибудь, отправляются ли данные на сервер. Это происходит в момент когда вы переходите к чтению,т.е. на вызове 

После этой строки уже ничего писать в данное соединение нельзя, поэтому writer можно перед чтением смело закрывать.

Это сообщение отредактировал(а) COVD - 4.7.2009, 19:24

Да , именно здесь.



Проверил , данные не отправляются.
Но -- не отправляются , опять же , именно в опере.







Это сообщение отредактировал(а) lihusha - 4.7.2009, 19:53

lihusha . Поздравляю! Вы не одиноки в вашей беде. С Оперой мучается и другие: 

Java Applet Development - Passing values from applet using POST method to PHP page - 



Коммерческий сайт предлагает решение java applet in Opera not sending POST values, но там надо подписаться на 30 дней trial c кредитной карточкой. И еще не известно, что они насоветуют.

Как я понял, Опера не использует java-plugin (как остальные "лохи"), а идет каким-то своим путем. Поэтому, наверное, в исключениях у вас и всплыло это com.opera.URLConnection. 

В общем, вам удачи в поиске решения. А я еще раз убедился как же правильно мы сделали, что полностью избавились от творчества разных энтузиастов браузеростроения.

Можно поподробнее -- что Вы имеете в виду ?

у нас почти 100% интерфейса приходилось на апплет и мы перешли на вебстарт. Теперь браузер (дефолтный) используется только на старте приложения для загрузки jnlp файла, т.е. минимально.  

Спасибо Вам за информацию

COVD, а можно ссылки на сайты , где используется web start ?
Я нашел несколько , мне показалось , они (приложения с web start) очень долго грузятся. 
Хотелось увидеть их побольше в действии.

Коково лично Ваше мнение о скорости их загрузки на клиента ?


P.S. Скорость моей линии -- 1 Мб/с

На мой взгляд проблема надумана. В реальности апплет будет меняться не часто, гораздо реже чем пользователь будет перезапускать браузер.

Не знаю , правильно ли я Вас понял. Если правильно -- решение данной проблемы и создание топика вызвано необходимостью РАЗРАБОТКИ апплета.
Например , если я меняю фон текстового поля с желтого на зеленый , то хочу сразу же увидеть это изменение при запуске апплета в браузере.

А что мешает вести разработку используя другой браузер, а Оперу использовать только в конце для окончательного тестирования?

Уже ничего.
Я понял , что самый эффективный способ -- менять версию в тэге апплета.



т.е., если изменить число 23235 , апплет будет подгружен новый.

Но, проблема с потоком все же остается для оперы.

Проблема (по крайней мере, о которой я писал) в том, что дефолтный (простой и удобный) механизм автоматического обновления версии апплета на клиенте иногда дает сбой - на сервере апплет (jar) поменяли, а клиент его не загружает (при перезапуске, конечно). Не только в Опере. Наиболее неприятна эта ситуация в клиент-сервер приложении, когда изменения сделаны и на сервере и на апплете (протокол обмена, например). В этом случае старая версия апплета не будет работать или, что хуже, будет работать некорректно. Конечно, при таком апдейте надо как-то форсировать клиентов обновить версию. Это дополнительные усилия. Субьективно, в WebStart, аналогичный дефолтный механизм работает лучше.  По крайней мере, так было ( сейчас, может, апплеты "подтянулись"?     )

Добавлено через 8 минут и 45 секунд


У апплетов и WebStart вроде нет принципиальных различий - время загрузки jar'a приложения зависит от его размера. Если приложение большое, то удобно его разбить на несколько более мелких jar'ов - библиотек. Тогда при обновлениях неизмененные библиотеки перезагружать не придется.
  

В свое время видел подобную рекомендацию для внешних JS файлов, но она в полной мере подходит и к апплетам (и Flash, и CSS и т.п.).
Просто добавлять к имени файла timestamp, т.е что-то наподобие того что предложил lihusha, но с некоторыми отличиями.

Разница состоит в том, этот подход требует обязательной согласованности HTML и апплета. С одной стороны дополнительная работа, с другой в случае такого рассогласования мы сразу увидим ошибку.