| Autor |
Mensagem |
|
|
Pessoal tudo bem !?
Gostaria de saber se é possível interceptar a invocação dos mutators no VRaptor sem apelar para AOP. Eu poderia fazer isso utilizando CGlib mas para isso eu preciso alterar o funcionamento do VRaptor para que ele utilize um construtor específico dos objetos do Modelo.
Abaixo o código que com AspectJ que faz o que eu quero (mas infelizmente depende do aspectj  )
[]'s
Rodrigo
|
 |
|
|
Valeu Lucas e Paulo.
Fiz um teste aqui de um HelloWorld do Struts 2 versus o VRaptor 3.2 com Guice no JMeter. VRaptor vence por 5%. Pode parecer pouco, mas comparado com a versão com Spring que era umas 30 vezes mais lenta é formidável. Isso torna o VRaptor elegível para as aplicações de Front.
Parabéns para a equipe do VRaptor.
|
|
|
|
Pessoal, estou com problemas para rodar a aplicação Blank do VRaptor 3.2 com o guice.
Peguei a versão 3.2 do VRaptor que acabou de sair do forno para testar a integração com o Guice.
Estou utilizando o Tomcat 6.02.
web.xml
ls
stacktrace
Agradeço muito se alguém puder ajudar.
|
|
|
|
|
Basta apagar a tag de Override (@Override ) que funciona.
|
|
|
|
Eu escrevi um artigo enorme sobre conversão para PDF. Se tiver paciência, dê uma olhada.
Agora, sobre seu problema em particular... cadê a parte que você coloca o o byteArray no ServletOutputStream e muda o Mime type?
Outra coisa, cadê a mensagem de erro?
[]´s
Rodrigo
|
|
|
|
Parece que os fabricantes já estão trabalhando em drivers para opengl 3.
A nvidia planeja para setembro o lançamento do seu driver.
E o pessoal do linux já está pensando nisso também. O projeto Gallium3d já prevê a utilização da nova especificação.
O que eu acho interessante no Gallium3d é a possibilidade do algoritmo de tesselar ser processado pela placa de vídeo:
_ Não, isso não é trivial. A renderização de uma imagem vetorial, digamos SVG precisa ser calculada para depois ser exibida... o que pode ser muito, muito lento quando utilizamos as pobre CPUs.
Mas, de fato, resta saber quando o JOGL será atualizado para que possamos explorar essa belezinha.
|
|
|
|
A notícia é de ontem, e meio esperada também... porque sabíamos que a especificação iria sair com o Siggraph 2008, mas...
Finalmente, saiu a terceira especificação do OpenGL. E a mudança é mesmo substancial. O openGL está trocando um modelo baseado em máquina de estados (lembram? Você atribui uma cor ... desenha o que quiser, atribui outra cor... desenha outra coisa...) por um modelo orientado a objetos.
De quebra, eles ainda lançaram a versão 1.3 do Shader language. E ainda, o grupo de trabalho do OpenGL promete unir forças com o OpenCL para acoplar computação com capacidades gráficas programáveis... GPGPU gente!!!
http://www.khronos.org/news/press/releases/khronos_releases_opengl_30_specifications_to_support_latest_generations_of/
off: (hahaha... para maiores informações falar com a beth - veja o link).
|
|
|
|
Vc passou longe do ponto.
Desculpa ai (1)... Eu estava só provando o que eu havia falado antes: que o padrão DTO NÃO dita um Objeto anêmico.
Eu não falei em javabean eu falei em bean.
Desculpa ai (2) ... Na literatura que eu conhecia, beans e Javabeans eram sinônimos. E um Javabeansprecisava ter construtor sem parâmetros público. Então apesar dos getters e setters, não poderíamos chamar aquele exemplo de Javabeans.
Mas nem é tão dificil assim:
O padrão Composite, por exemplo, nasce diretamente do conceito de composição que é uma forma de relacionar objetos. (...)
Eu não diria que esta essa é a demonstração mais formal que conheço. Na minha opinião seria preciso tomar o padrão composite, como apresentado pelo Gof e sua "Estrutura": Component, Composite and Leaf. Então, seria preciso demonstrar que aplicando os aximos do OO teríamos essas entidades e teríamos que tomar o cuidado para mostrar como cada uma dessas partes atuam não deixando dúvidas se Component pode ou não ter
métodos de manipulação de listas, se um autorelacionamento pode ou não desempenhar o papel de composição, etc.
Eu concordo plenamente que existe uma base teórica importante sobre os padrões de projeto.
Mas volto a enfatizar que o conceito é mais importante que a estrutura.
|
|
|
|
Eu não conheço Maven muito bem... mas vou falar de um problema que costumo resolver no eclipse.
Procure utilizar as mesmas bibliotecas que o servidor de aplicação usa. Se você procurar no servidor de aplicação encontrará os jar para uma série de recursos como o javax.mail. O Jboss tem um pacote, Jboss-all-client que já vem como um monte dessas bibliotecas. Sugiro fortemente utilizá-lo.
O eclipse WTP fornece uma lista de servidores pré-configurados. O ideal é utilizar a library (tem uma opção library na janela do classpath do eclipse) do servidor de aplicação que você está utilizando. Usar outras bibliotecas é certeza de encontrar problemas.
Como eu disse, eu não lembro muito bem do Maven mas tente configurá-lo para utilizar as bibliotecas do JBoss.
Se isso não tiver nada a ver então eu não entendi hehehe.... sorry.
[]´s
|
|
|
|
Esse assunto é muito jóia...
Eu enfatizo que o conceito do padrão é mais importante que a estrutura. Veja:
O que vc está dizendo é que se eu pegar um pojo da vida o fizer serializable
ok
e colocar um monte de codigo de validação,
A validação pode ficar nos setters, correto!? Se os getter e setters só atribuirem/devolverem os valores da propriedades seriam só idiossincrasia para acessar a propriedade internas do objeto.
colocar o construtor privado,
Huh(vamos ver...)
colocar get/set paras os atributos,
ok
colocar um método estático para retornar o objeto que eu crio dando clone de um atributo estático privado e final na classe
Ops...
eu estarei usando : Prototype (clone copy),
ok! Se é interessante clonar seu objeto, não tem nada de errado com isso. Ainda não vi a motivação mas pode ser que faça sentido. Sei lá, vai ver que você esteja fazendo um joguindo de carros e o servidor disponibiliza novos modelos de carros. Cada cliente recebe os modelos de carro e permite que usuário faça modelos personalizados a partir desses. (Serializável e clonável). Nesse caso o modelo segue o Prototype.
Factory-Method (método de criação),
Aí não. Eu falei que o conceito do padrão é importante, não a estrutura. Usar um método para criar outro não faz um "factory method". Existe uma motivação para o Factory Method e não existe nenhuma motivação na saladinha.
TO (serializable)
Pode ser que sim... desde que a motivação coincida com o padrão. No exemplo do jogo do carrinho seria uma estupidez os clientes serem informados de propriedade por propriedade de cada modelo. É mais inteligente o servidor enviar todo o objeto. Esse é um exemplo do uso do DTO.
e Bean (get/set).
Isso também não. Para começar que um Javabeans é um componente de software, não um padrão. E existe uma especificação que dita quando uma classe Java pode ser chamada de Javabeans... De forma simplificada:
The class must have a no-argument public constructor. This allows easy instantiation within editing and activation frameworks.
The class properties must be accessible using get, set, and other methods (so-called accessor methods), following a standard naming convention. This allows easy automated inspection and updating of bean state within frameworks, many of which include custom editors for various types of properties.
The class should be serializable. This allows applications and frameworks to reliably save, store, and restore the bean's state in fashion that is independent of the VM and platform.
Ainda no exemplo dos carrinhos, o código não precisa ser um padrão. Mas, alguns padrões podem ser encontrados na resolução desse problema.
ArrayLisr , etc... sim são estratégias de List que por sua vez é estratégia de Collection. Isso sim. Mas nunca "interface" per se será um padrão.
Concordo plenamente!!!
Sobre a parte de corolários, etc... acho que não podemos fazer tal afirmação. A demonstração rigorosa que um padrão deriva matematicamente de "axiomas de OO" não deve ser alguma coisa fácil, talvez nem seja possível... Seria realmente incrível provar que dado um contexto(limitações) e um problema (necessidades) não seria possível encontrar um modelo melhor do que o modelo de um certo padrão. Mas por enquanto isso é uma especulação (conjectura) não um teorema.
|
|
|
|
Tem um interessante artigo no serverside que fala sobre sistemas escaláveis.
Uma das coisas interessantes está nesses parágrafos:
Use collocated deployment instead of distributed one
Java EE technology, especially EJB, was born for distributed computing. Decoupled business functionality and reused remote components make multi-tier applications popular. But for scalability, reducing the distributed layers maybe a good choice.
The result was that the collocated structure scaled much better than the distributed one! Imagine in one method in your application you may be invoking a couple of EJBs. If you load balance on every one of those EJBs, you're going to end up with instances of your application spread out across the multiple server instances. As a result, you're going to have a lot of server-to-server cross talk that's unnecessary. And more, if your method is under a transaction, your transaction boundary will include many server instances which will impact performance heavily.
Quer dizer... às vezes soluções mais simples, são mais escaláveis. (ou você não precisa se matar para colocar um sistema em grid para conseguir escalabilidade). E, é sempre bom lembrar de exemplos como a Wikipedia que não utilizam nada como EJB e escalam super bem.
|
|
|
|
Desculpe... eu não compreendi direito.
Você está falando que usa o jar de email do geronimono Jboss... acho que isso não está muito certo não.... 
Seu projeto não deveria apontar para o jar de mail do próprio Jboss e não o jar o geronimo?
|
|
|
|
rs....
engraçadinho...
Ahhh...já ia esquecendo neste livro não fala de python. hahahahah!
|
|
|
|
Existe necessidade de ser agressivo quando se posta no forum???
Juro que não entendi a agressividade gratuita. 
De qualquer forma, seu argumento vai de encontro à definição de padrão. Se padrões são soluções recorrentes, identificado em situações diferentes... ninguém estava seguindo nada à risca. Nas palavras do fowler:
"One of the interesting things here is that a singular solution can often lead to a recurrent pattern. This usually crops up when you see two different singular solutions which look completely different on the surface, yet have a deeper similarity"
.
Padrões são sérios, e são coisas importantes. Mas é preciso entendê-los e não vê-los como receitas.
Um ótimo exemplo disso é o DTO. O padrão fala do problema de usar vários getters e setters entre sistemas distribuídos. Isso seria muito ruim.... Ao invés disso, sugere-se enviar um objeto que encapsule todas essas informações. Ponto.
O padrão não dita que você não pode colocar código de validação, comportamento, etc nos DTOs.
Outro excelente exemplo é o padrão strategy. Sugiro que as pessoas leiam a descrição do padrão e comparem com a idéia de Interface do Java. Observe que no C/C++ e no Smalltalk não existe Interface... O que você acham? O conjunto List + implementações (ArrayList, LinkedList, etc) não implementa o padrão Strategy? Pattern é isso, uma solução recorrente (um conjunto de melhores práticas) para problemas recorrentes.
|
|
|
|
Eu mantenho minha posição.
Quem sou eu para dizer para você escolher por uma tecnologia ou outra... Escolher uma tecnologia nova é assumir um baita risco.
Mas eu acho ( e não coloque a culpa em mim se alguma coisa der errado) que o Struts 2 já é uma tecnologia madura.
-- Editado: correção gramatical... ops...
|
|
|
|