Valeu Handerson,
Pela sua resposta sobre "SESSION / SERVLETS" posso guardar o conte�do
das vari�veis do tipo "Login/Senha" LOCALMENTE e, havendo qualquer
necessidade de recuperar novamente as vari�veis (put/get) da sess�o
posso testar previamente a mesma com o m�todo "session.isNew()" antes de
redirecionar para a p�gina de (Re)Autentica��o. Outra op��o que me
ocorre � colocar o m�todo "getValue()" num bloco "try/catch" capturando
a exce��o "IllegalStateException" antes de redicrecionar para a p�gina
de (Re)Autentica��o. Correto???
Um grande abra�o e Obrigado por tudo!!!
Carlos Campos
> ----- Mensagem original -----
> De: Handerson Ferreira Gomes [SMTP:[EMAIL PROTECTED]]
> Enviada em: Quinta-feira, 14 de Outubro de 1999 22:10
> Para: Carlos Campos; 'Albertao, Felipe {IT~Sao Paulo}'; 'Lista
> Java BR'
> Assunto: Re: Servlet & Remote User
>
> Opa, eu de novo.
>
> > 2) Corre��o: Quando mencionei um artigo do Handerson sobre PASSWORD
> > utilizei a express�o "public" para comentar que as vari�veis
> assumiriam
> > um papel "persistente" no ambiente do browser podendo ser acessadas
> > pelas demais classes. Na verdade, relendo o artigo, as vari�veis de
> > classe devem ser definidas como "static". E, se n�o estou novamente
> > enganado, devem ser carregadas pelo browser no seu cache e estarem
> no
> > mesmo diret�rio das demais classes que compartilhar�o o acesso. Se
> for
> > assim, uma solu��o de logar uma vez e checar a vari�vel em outros
> > applets ou servlets aparentemente N�O deve funcionar. Me corrija o
> > Handerson se estou equivocado.
> Voce est� certo. Os dados e m�todos est�ticos fazem parte da classe e
> n�o do
> objeto. � um pouco dif�cil de explicar, mas por exemplo:
> class estatica{
> static String nome;
> static String login;
> }
> Ent�o quando voc� faz algo do tipo estatica.nome="Maria" voc� est�
> colocando
> este valor dentro da classe.. voc� n�o precisa utilizar algo como
> estatica x
> = new estatica() e depois fazer x.nome="Maria".
> No caso de Servlets, se tivermos vari�veis est�ticas, significa que o
> valor
> desta vari�veis ser� o mesmo para todos os threads dos servlets que
> estejam
> no ar.
>
> > 3) Por fim a solu��o muito bem detalhada no artigo do Handerson
> sobre
> > "SESSIONS / SERVLETS" me parece muito boa, quando vc concentra o seu
> > processamento nos SERVLETS. Mas a� me ocorreu uma d�vida:
> > O VqServer atribui por default o tempo de 30 minutos para um
> "SESSION
> > TIMEOUT" que pode ser reconfigurado. Isto significa que, esgotado
> este
> > tempo, � autom�ticamente ativado o m�todo "invalidate()" ???
> Mais uma vez exato!!!
> Uma sess�o � invalidade quando seu tempo de vida expira.
>
> > Isto significa tamb�m, que numa Intranet, o Usu�rio que esquecer o
> > browser conectado com a aplica��o e esgotar o "timeout" ter� as suas
> > vari�veis de identifica��o (put/get) destru�das ou permanecer�
> > dispon�vel o �LTIMO conte�do das mesmas ???
> Elas estar�o destru�das, a n�o ser que voc� utilize cookies, que s�o
> persistidos no cliente. Quando uma sess�o � terminada, seus valores
> tamb�m
> s�o perdidos.
>
> Espero ter ajudado...
> Nos vemos aqui na Web.
>
> [ ]'s
> Handerson Ferreira Gomes
> Taos Consultoria
> http://www.taos.com.br
>
* Para n�o receber mais e-mails desta lista envie um e-mail para
[[EMAIL PROTECTED]]
e no corpo do email escreva [unsubscribe <seu-email>]
Veja as mensagens antigas em http://www.mail-archive.com/javabr%40cits.br/
