[Prévia] [Próxima] [Prévia por assunto] [Próxima por assunto]
[Índice cronológico] [Índice de assunto]

Re: Duas d�vidas: uma sobre classloaders sacanas e outra meio off-topic



    Oi pessoal,

    Aproveitando para comentar um pouco sobre isso - esse problema � o 
do schema evolution - a solu��o pode ser incrivelmente complexa. O 
depurador at� que se esfor�a - mant�m uma lista de depend�ncias e 
objetos ativos e, quando voc� troca uma classe, ele at� reseta as call 
stacks dos m�todos que estavam executando aquele c�digo, presos em 
breakpoints, para que o usu�rio possa visualizar as mudan�as - � um 
lance s� pr� voc� poder ir brincando com o c�digo e vendo o que acontece.
    Agora, se o programa tem inst�ncias ativas de objetos com a vers�o 
antiga da classe e voc� detona alguma coisa muito feia (tipo um 
atributo), e o c�digo daquela classe j� foi executado ou estiver 
executando, a VM "sai de sincronia" - i.e. ele n�o atualiza a classe, ou 
atualiza e arrebenta tudo (porque, ao contr�rio do que acontece no 
JBoss, a JVMDI de fato arranca a classe antiga e substitui com uma nova 
- rola uma substitui��o de bytecode *naquele* binding de tipo).
    Ent�o, o "hot-swap" do debugger com certeza n�o serve ao mesmo 
prop�sito do hot-swap do JBoss - o primeiro serve para voc� poder 
brincar com o c�digo em modo debug, podendo inclusive arrebentar tudo e 
derrubar a sua aplica��o. O segundo serve ao prop�sito da flexibilidade, 
da conveni�ncia e da adapta��o e, idealmente, n�o deve derrubar a sua 
aplica��o. :-)
    Concluindo, o hot-swap da JPDA �  bem conveniente para quem est� 
depurando, mas, certamente, n�o se trata de uma tentativa de resolver o 
problema de schema evolution - ele n�o funciona e nem poderia funcionar 
perfeitamente.

    Abra�os a todos e at� amanh�,

       Giuliano

   

>Isso e muito legal. Tambem fiquei curioso quando usei. Mas este "hot replace"
>nao funciona perfeitamente, depende das alteracoes feitas no codigo (se voce
>alterar algo consideravel ja para de funcionar). Tive tambem algumas vezes paus
>na JVM (ela caia, imprimindo umas mensagens meio loucas) devido a este "hot
>replace".
>
>Abracos.
>
>  
>