Glassfish 2.1 ненадежного развертывания - PullRequest
1 голос
/ 18 июля 2010

у меня есть сервер glassfish 2.1, подключенный к моим затмениям (helious) и кажется, что это очень ненадежно, когда я разверну свой проект.

У меня очень простой EAR, который я хочу развернуть и просмотреть веб-службы изначально это удалось. С тех пор иногда был очень временным он будет развернут, а другие скажут, что он депонирован, но не отображается на консоли администратора

Я прошел процесс перезапуска, очистки, повторной публикации, добавления и удаления проекта, но ничего не получается.

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

Есть ли что-то, что я могу сделать, чтобы улучшить его эффективность, или есть более надежный способ депо приложений?

Спасибо Jon

1 Ответ

0 голосов
/ 18 июля 2010

У меня нет опыта работы с Glassfish, но я видел похожие проблемы с WebLogic и Tomcat.

Eclipse имеет плагины для интеграции с этими серверами приложений. Они обычно делают замечательную работу, но они не идеальны. В случае Tomcat Eclipse быстро копирует все скомпилированные файлы .class непосредственно в разорванный каталог приложений Tomcat, а Tomcat, работающий в режиме разработки, находит измененный код и перезагружает приложение. Когда это работает, это означает, что ваш новый код готов к работе через несколько секунд после нажатия Ctrl-S для сохранения измененного исходного файла. Но иногда сервер приложений плохо синхронизируется.

Альтернатива, которая мне хорошо послужила, - обойтись без тесной интеграции с сервером: используйте автономный сервер приложений (т. Е. Вне Eclipse), используйте ant для создания файла .ear и задачу ant deploy чтобы остановить приложение, нажмите на него обновленный .war и перезапустите приложение. Цикл развертывания занимает немного больше времени, чем то, что делает для вас плагин Eclipse, и вам потребуется больше усилий для настройки удаленной отладки. Но я считаю, что это лучший способ обеспечить повторяющееся эффективное и надежное развертывание.

...