Hot deployment em produção

Edufa, não tem diferença se estão dentro do war ou fora, o que muda é apenas a localização.

bobmoe wrote:não são raros os casos em que tenho que dar um clean geral quando aparece um erro sem explicação.

bobmoe wrote:como eu disse gosto muito, apesar dos problemas

fatos mais do que suficientes para não se fazer.

Parece interessante justamente devido a alterações q o pessoal de designer sempre gosta de fazer em algumas páginas mais dinamicas (dinamicas no sentido de design), fica inviável ter de fazer um novo deploy só pq um css mudou. Aí como faria, carrega o jsp, template externo a aplicação, preenche e mostra?

Para o caso particular de css, bem como conteúdo estático em geral, vc. pode utilizar um servidor ou contexto separado. Como é estático, não há problema de redeploy, por definição.

Isto é comum no caso de servidores J2EE operando atrás de um Apache ou IIS. Estes últimos servem o conteúdo estático enquanto os primeiros atendem a solicitações com conteúdo dinâmico.

Se for usar este esquema recomendo ainda utilizar um virtual host separado para o conteúdo estático, já que isto permite aumentar o número de conexões simultâneas que os browsers abrem (se não me engano, o default é de 4 conexões por host).

Quanto a ter o máximo de recursos "fora" da aplicação, eu particularmente prefiro evitar. Nada contra do ponto de vista técnico - aliás é provável que em determinados cenários isto até seja o mais recomendável. Apenas acho que ter um ear/war fechado e completo torna mais simples o gerenciamento de mudanças, por permitir um procedimento padronizado de deploy/redeploy das aplicações que irão rodar no servidor.

louds wrote:
Edufa, não tem diferença se estão dentro do war ou fora, o que muda é apenas a localização.

Ops, heheh falha minha então, eu sempre achei q os jsp acessados pelo war tinham de estar dentro do war. Vivendo, errando e aprendendo.

Então estando fora a responsabilidade é minha de atuaalizar no caso de re-deploy, ótimo era bem isso mesmo. Os jsp relativos a administração ficam dentro pq design não tem de ficar mexendo, os relativos a aparencia da aplicação ficariam no diretório externo, e todo mundo fica feliz no final.

psevestre wrote:
Para o caso particular de css, bem como conteúdo estático em geral, vc. pode utilizar um servidor ou contexto separado. Como é estático, não há problema de redeploy, por definição.

Nesse caso específico o css se aplica a própria parte dinamica, e é passivel de alterações pelo pessoal de design. Não consite da parte estática. Ou seja é um design dinamico (através de css), numa página dinamica (jsp)

Edufa wrote:
Nesse caso específico o css se aplica a própria parte dinamica, e é passivel de alterações pelo pessoal de design. Não consite da parte estática. Ou seja é um design dinamico (através de css), numa página dinamica (jsp)

Se eu entendi direito, seu css é gerado de forma dinâmica. É isto ?

Neste caso o css terá que ficar sob as "asas" do servidor de aplicação. Ainda assim, imagino que a parte realmente dinâmica do css não seja muito grande e, portanto, talvez valha a pena quebrá-lo em duas ou mais partes, passando o que for estático para o apache ou iis e deixando apenas o "css dinâmico" no serv. app.

Thread.start() Membro desde: 24/02/2005 13:33:14 Mensagens: 47 Offline

Não utilizo o hot-deploy do JBoss 4 porque não sei usar

Alguém explica?
Ele funcionaria pra qualquer mudança de classes ou apenas para JSPs?

Relamente não é comum Hot Deploy no ambiente de produção. O ideial é manter um ambiente de desenvolvimento e outro de produção.

Hot Deploy bem feito também não existe, por exemplo, o JBOSS Tools não aceita alteração na assinatura de um método e a adição de outros métodos, ele é bem fresquinho e me parece que por qualquer motivo é necessário clicar no horrendo botão restart.

A saída é criar seu próprio ClassLoader

Apesar disso, a customização do ClassLoader torna-se inviável na grande maioria dos Framewoks, porque fazem da camada de apresentação e comando uma verdadeira caixa preta.

Essa necessidade de reiniciar o servidor de aplicações JAVA para qualquer miserável vírgula que se troque no fonte é, sem dúvida, a coisa mais nojenta do desenvolvimento JAVA na WEB. Não é a toa que aplicações PHP e ASP ainda reinam nesta área. Afinal, qual é o problema dessa atualização de classe? É um bug, é uma limitação? Tem a ver com a arquitetura da JVM? DEZ anos de JAVA não é tempo suficiente para resolver essa pendenga?

Thread.start() Membro desde: 28/11/2009 00:46:40 Mensagens: 41 Offline

De acordo com o manual do IBM Web Sphere:

Important: Do not use hot deployment to update components in a production deployment manager managed cell. Hot deployment is well-suited for development and testing, but poses unacceptable risks to production environments. Full or partial resynchronization might erase hot deployed components. Also, running the restoreconfig command might overwrite changes made to expanded application files. Further, hot deployed components are not migrated between versions of WebSphere Application Server. To add new components or modules to an enterprise application, reassemble the application EAR file so it has the new components or modules and then redeploy the EAR file.

http://publib.boulder.ibm.com/infocenter/wsdoc400/v6r0/index.jsp?topic=/com.ibm.websphere.iseries.doc/info/ae/ae/trun_app_hotupgrade.html

Outra leitura interessante: http://felipe.blog.br/2007/06/hotdeploy-no-tomcat/

Notícias, artigos e o maior fórum brasileiro sobre Java