Curiosidade vaga, alguém usa hot deployment em produção? Indo mais fundo ainda, alguém já viu algum ambiente que funcione efetivamente?
Eu utilizo hot deploy onde trabalho e acho muito bom. Contudo, não são raros os casos em que tenho que dar um clean geral quando aparece um erro sem explicação.
abraços
Em producao nao se faz esse tipo de coisa. 
Ainda mais que quase nenhum class loader funciona direito
como eu disse gosto muito, apesar dos problemas (que todas as abordagens vão possuir).
Me ajudem a entender pq vcs não utilizam em produção, pq eu utilizo e tenho mais vatangens do que problemas.
Talvez isso venha a mostrar alguma coisa que possa prejudicar o projeto no futuro, acho bastante relvante entender pq vcs são contra.
abraços
Eu não gosto porque simplesmente não confio.
E como qualquer implementação em produção eu devo chegar o mais próximo dos 100% de confiança, eu não uso.
É justamente isso que estou questionando: Fato é diferente de opinião.
Estou querendo entender os fatos, experiências negativas por exemplo, que levam vocês a não inidicarem. Isso porque, como eu disse, eu uso e não tenho (pode ser ainda) tantos problemas que justiquem eu não utilizar hot deploy em produção.
Olá
Na minha opinião, isto deve ser estudado caso a caso e em muitos casos não vejo mal nenhum usar. Nem todas as aplicações são tão críticas assim que precisem de 100% de confiabilidade.
Não tenho muitas experiências com os problemas que alguns de você vivenciaram. Quando usei funcionou OK.
Tenho enorme curiosidade em saber quais casos deram problemas e quais os servidores de aplicação em uso.
[]s
Luca
Não uso simplesmente porque não funciona. A quantidade de problemas é enorme que se resume a não permitir que a versão anterior seja coletada pelo GC.
-A biblbioteca padrão da JRE possui leaks
-O container possui leaks, direta ou indiretamente, seja por ser mal implementado, ou pq usa bibliotecas mal projetadas.
-A aplicação causa leaks por fazer coisas além do normal (GCLIB e a maioria de class-loading conning).
Respeito seus anos e mais anos de experiência, Luca, mas eu acho que quando chega na ponta de implementar qualquer coisa em produção, a gente precisa tentar chegar perto dos 100% de certeza do que estamos fazendo.
Enfim, como disse o bob, no meu caso fica mais perto da opinião do que do fato. Não tive muitos problemas pq simplesmente não faço. Pra não dizer que nunca, tive problemas no Websphere 6.
Para quem não utiliza o hot deploy em produção, como vocês fazem o deploy? Removem a aplicação via mecanismo do app. server e depois fazem o deploy da mesma forma? Se sim, não seria o mesmo que um hot deploy faria automaticamente?
O que eu vi melhor funcionar foi deixar no war/ear apenas o mínimo necessário, como código e configuração básica (web.xml). Todo o resto, que se resume a configuração da aplicação e arquivos de templating, deixar em um local fora do controle do AS. Dessa fora fica muito mais facil para gerenciar alterações e executá-las com o mínimo de impacto na aplicação.
Pode ser uma perguntinha besta, mas como fazer para os arquivos de template usarem os dados disponbilizados pela aplicação se eles estão fora dela? No caso eu uso o mentawai, como acessaria o output?
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?
Fiz um questionamento parecido aqui.
Edufa, não tem diferença se estão dentro do war ou fora, o que muda é apenas a localização.
fatos mais do que suficientes para não se fazer.
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.
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.
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.
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
public void loader()throws MalformedURLException{
ClassLoader previous,current;
if(context.getValue("app.inside").equalsIgnoreCase("true"))return;
previous=Thread.currentThread().getContextClassLoader();
current=URLClassLoader.newInstance(
new URL[]{new URL(context.getValue("app.jar.url"))},previous
);
Thread.currentThread().setContextClassLoader(current);
}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?