Думаю, как лучше обновлять веб-приложение на удаленном сервере:

1) Не пойму, можно ли просто копировать обновленные файлы в папке, которая распаровывается из war архива?
2) Можно ли деплоить проект сразу на удаленный сервер? (NetBeans не позволяет добавлять удаленные сервера приложения, но, возможно, можно как-то это настроить через ant).

Можно задеплоить war архив через веб-страницу tomacat-manager-а. Еще вот тут можно почитать. 

NetBeans может управлять удаленным GlassFish в том числе деплоить приложения. Так же, при определенных настройках возможна удаленная отладка.



Это сообщение отредактировал(а) Vasay - 23.5.2010, 17:29

Да, это хорошо, тока где-ж найти дешевый хостинг с GlassFish ...

Лучше - без затей: удалить старый вар, дождаться сообшения об удалении приложения, положить новый вар. На любом сервере.

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

Andrey1, 

А зачем часто что-то на сервере менять? Разрабатываешь, дебажишь на локале, а на сервер только релизы. 

Любое законченное изменение - это и есть релиз .

Целиком обновлять - можно, но было б идеально, если можно было обновлять только то, что изменилось.

Вообще еще удобно держать исходники в репозитории типа svn и на сервере пересобирать. Тока вот ручками нужно это все настраивать... 
Вначале можно попробовать обновлять только скомпилированный веб-проект...

Это сообщение отредактировал(а) Andrey1 - 28.5.2010, 22:30

Веб-приложение можно строить как набор веб-проектов (варов), а каждый веб-проект может состоять из одной jsp.

Andrey1, 



Тут и заключается кардинальное отличие web приложения на Java от web приложения, скажем,  на php - в случае php время жизни приложения один запрос. При следующем запросе оно запускается вновь, как следствие, заменили вы один файл php на новый -  следующий запрос обрабатывает новая версия приложения.

В случае с Java, время жизни приложения с момента его деплоя до момента андеплоя. Некоторые объекты создаются при старте и существуют в единственном экземпляре все время жизни приложения. Некоторые объекты существуют в единственном экземпляре для каждой сессии. Какие-нибудь конфигурационные файлы читаются только при старте. 

Потому замена одного класса на другой - операция по смене органа на живом организме. Так просто ее не сделаешь.  Да есть возможность построения модульных приложений:
 - порталы с их портлетами
 - OSGI
 - использование скриптовых языков (например,  Groovy ). Кстати, есть фреймворк на базе Spring - Grails. Там Groovy  используется как основной язык. Изменения в Groovy классах фиксируются без перезагрузки приложения на сервере. Правда, иногда, все же требуется перезапуск. 

Да, согласен, перезапуск веб-приложения на java - отдельная не простая тема. 

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

Добавлено @ 07:41

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

Это сообщение отредактировал(а) Andrey1 - 29.5.2010, 07:47

Возможно, применим критерий "один ресурс - один проект". И вписывается в концепцию REST.