| Autor |
Mensagem |
|
|
MVC é duca...
mas acho que MVC não tem muito a ver com web, pelo simples fato de ser orientado a requisições (tipo evento + dados). Pelo que eu conheci de filtros, acho que é mais simples e mais direto usá-los, pois não precisa de (tantas) configurações a mais apenas para fazer o controle de fluxo.
Alguém já usou? Em que situação eu iria preferir struts a filtros?
aquelão!
Tiago.
|
 |
|
|
Ueba!
Eu demorei muito pra entender porque eles inventaram uma interface Serializable, uma vez que vc não precisa implementar nenhum método dela. Ou seja, se os ObjectXXXStreams conseguem ler qualquer objeto, pra que eles querem uma interface?
Á primeira vista, a resposta não parece convincente: eles querem que você saiba o que está fazendo. Repare que todos os objetos que guardam dados são seriáveis (essa é a tradução : )): Integer, as collections, alguns eventos...
Se uma classe sua implementa Serializable, vc atesta saber o que está fazendo. Membros seriáveis da sua instância serão enviados junto com ela, a menos que vc os declare "transient". Pode ser o caso de um membro que guarda a hora local (que deve ser diferente no lugar/momento em que ele for lido), ou um número de porta de um socket, sei lá.
Normalmente, vc não deve implementar nada para realizar o processo de escrita e leitura. Mas há casos raros em que você quer especificar direitinho como ler um objeto. Por exemplo, você pode querer colocar um cabeçalho no arquivo, ou ler seu objeto de maneira diferente dependendo da plataforma que roda debaixo da sua VM. Nesse caso, vc tem que implementar os métodos abaixo:
Dentro do readObject, vc está num momento de pós-construção, e pode tratar membros como vc faz num construtor. Vc deve tomar cuidado ao chamar métodos que possam ser sobrecarregados, ou pode acontecer um efeito interessante: um método da subclasse ser executado antes que a superclasse tenha inicializado o objeto corretamente!
Num Bean é importante implementar essa interface pois do contrário vc não pode oferecer persistência a ele: um objeto que não implementa Serializable não serve como argumento para o método writeObject() do ObjectOutputStream, vc vai receber uma exceção, algo como "ei, vc não sabe o que está fazendo!" JavaBeans não são considerados brinquedo, ou seja, ao contrário dos objetos ordinários do Java, um Bean deve SEMPRE prever sua seriação. Assume-se que o criador do bean provavelmente vai querer a implementação padrão de leitura, o que é verdade.
|
|
|
|
A partir do Java 1.3, o javac transforma linhas assim:
em linhas assim:
Note que ainda assim vc tem uma alocação de memória e uma chamada ao toString() do buffer, que são dois métodos lentos.
Tive uma experiência num JSP que parseava mais ou menos 15 parâmetros pra montar uma query. O cara que escreveu o servlet antes de mim usava concatenação direta para coisas do tipo:
Esse trecho ia pra cada um dos parâmetros, e o ganho de performance ao passar pra um único StringBuffer foi imenso, mesmo num JSP.
vida longa aos buffers!!
|
|
|
|
Legal o tutorial!!
Mas eu gostaria de ver mais sobre a API nova, usando Calendar. Podia falar também de calendários lenientes e o que acontece se vc tem um Calendar no dia 28 de Fevereiro e chama
cal.add(Calendar.DAY_OF_YEAR, 1);
Aquelão!!
|
|
|
|
Até eu usar o amado e odiado (ao mesmo tempo!) Deploy Tool que vem junto com o J2EE, eu não fazia a menor idéia de o quanto é importante vc ter uma ferramente de apoio para instalar suas aplicações. Desse eu posso falar. Ele vem com o J2EE e dá pra rodar de um executável que fica no $J2EE_HOME/bin/deploytool (ou perto disso, procurem, seus preguiçosos!)
Usei o Deploy Tool para publicar uma aplicação em Servlets/JSP. Como ferramenta, ele é realmente fantástico, porque deixa de lado uma parte importante da cofiguração de uma aplicação web: a configuração do WEB-INF, que além de ser um tanto sacal, pode ser complexa demais para o novato.
Pois bem, o Deploy Tool permite que vc dê um nome à sua aplicação, e vá aos poucos especificando suas partes: toda configuração do web.xml é feita por baixo, sem a manipulação direta, vc pode adicionar bibliotecas (arquivos JAR) que sua aplicação necessita (por exemplo, o driver JDBC), os arquivos JSP usados, etc. Daí vem a parte realmente interessante.
Vc pode configurar EJBs (deixo a alguém mais experiente a explicação disso) e outros serviços usando a JNDI (ingles para Interface de Nomes e Diretorios do Java). Esses serviços ficam disponiveis no servidor e podem ser ate compartilhados por aplicações separadas. O server faz tudo, até permite especificar queries no BD que correspondem a chamadas de métodos do seu bean.
Uma vez que vc tenha o JAR com seu(s) EJB(s) e o WAR com sua aplicação web, o deploy tool cria um arquivo EAR (que chutaria ser o Enterprise Archive) com toda configuração e arquivos dentro, que vc salva onde quiser. Os arquivos EAR são padrão e podem ser instalados em Application Servers independentes, como o JBoss.
Aí vem a parte final: o Deploy Tool é capaz de instalar e desinstalar sua aplicação inteira (coisa que o AppManager do Tomcat não faz direito, obrigando o usuário a deletar os arquivos antigos manualmente) no servidor (geralmente um Catalina interno). Voilá, temos uma aplicação rodando.
No J2EE há muito mais, mas saber da existência deste utilitário, para quem tem uma paciência chinesa ou um micro realmente rápido, é muito útil. Recomendo
|
|
|
|
O Security Manager "sandbox" deve ter impedido de redirecionar o Stream, e faz sentido nao?
Na verdade, eh o su que reclama dos streams, e não o SecurityManager (to viajando?).
O que se pode fazer eh ter um script que se quer rodar como root e chamar (pelo Runtime.exec()) uma linha assim:
su tibco -c script.sh
Seu script tb precisaria de input??
|
|
|
|
 Gostei bastante da explicação sobre a api de logging do Java. Aliás, seria legal ver uma comparação entre essa API e o Log4J do Jakarta.
Alias de novo, o pessoal do jakarta tem um monte de pacotes legais pra quem usa Java na web, e mesmo pra quem não usa. Fica o toque para fuçar lá (a navegação do site deles é complicada, tem que fuçar mesmo).
Tiago.
|
|
|
|
|
|