| Autor |
Mensagem |
|
|
fabberg wrote:coloquei o invalidade e funcionou certinho..
Mesmo assim preste atenção na dica do Rafael Guerreiro, pois teu interceptor pode não estar fazendo o bloqueio corretamente.
|
 |
|
|
|
A forma mais segura de fazer logout é chamar o métod invalidate do HttpSession. Injete ela no construtor, e chame o método, que invalida toda a HttpSession e remove todos objetos.
|
|
|
|
Você tem um método que recebe como parametro a foto:
E como você diz qual a foto usar, se no caminho passado no JSP você tem apenas o PATH sem o ID da foto?
Mágica ainda não funciona ;)
Faz assim... altera o @Path do método downloadFoto para /versao/visualiza/foto/{foto.id}, e no JSP coloca:
|
|
|
|
Ou então você pode usar a classe PersistentDateTimeTZ, que está no mesmo jar do JodaTime-Hibernate, que armazena junto o Timezone.
Basta ler os docs ;)
|
|
|
|
|
Se são sistemas diferentes, não consigo imaginar um motivo para usarem as mesmas tabelas/entidades. Isso para economizar código? Se sim, é o mesmo caso daqueles projetos que criam uma BaseAction apenas para ganhar alguns poucos métodos utilitários. Neste caso a amarração é tão forte que mais atrapalha do que ajuda.
|
|
|
|
Meu único problema no GAE é a questão de usar aquelas APIs proprietárias. Se um dia você quiser migrar para outro local, precisa reescrever muita coisa. E neste ponto tenho gostado muito do Openshift, pois é um ambiente JEE padrão. Então sempre que você optar pelo GAE, tem que levar isso em questão.
Além disso, eu não gosto de trabalhar com servlet container, sempre que possível prefiro trabalhar com appserver, por eu ter um leque bem maior de opções de gerenciamento como schedulers, JTA, etc. Muitas coisas que eu teria que me preocupar em um ambiente servlet container, eu não tenho em um appserver. Mais um motivo por eu ter gostado do Openshift.
Se você tem muitas ligações entre os módulos, será que realmente eles estão separados corretamente? Se as ligação são tão fortes, talvez eles não devam ser separados em módulos. Isso porque vai chegar um momento que serão tantas ligações fortes que você terá dependências ciclicas, e ficará complexo de manter. Enfim, sem saber o que é realmente, é complicado de prever. Entretanto eu te sugiro organizar os módulos para que tenham a menor quantidade de dependências, e quando mais fracas melhor. E de preferência evite que um módulo altere entidades do outro, pois assim é complicado até mesmo controlar a concorrência.
Eu só fiquei em dúvida: tua aplicação é separada em módulos ou são aplicações diferentes? Porque se são apenas módulos do sistema, você pode fazer algo parecido com o que eu fiz em um outro sistema. O projeto era empacotado em um EAR, e cada módulo do sistema era um módulo EJB, porém o banco de dados era o mesmo, já que a aplicação é a mesma. Porém tomei cuidado de organizar os módulos de forma que nunca um módulo alterada entidades de outro. Por exemplo, o módulo de Cliente poderia fazer tudo que queria com cliente, porém o módulo Vendas não poderia alterar os dados do cliente, ele apenas criava Orders e afins, mas nunca alterava diretamente Cliente.
Abraço
|
|
|
|
Eu particularmente não gosto de comprartilhar banco de dados. Isso porque você acaba criando uma dependência entre eles. Claro, talvez a dependência seja desejada, no caso de módulos, mas não sei se é teu caso.
Você quer compartilhar endereços, é?
Fiz algo assim em um sistema. A base de CEP é enorme, e eu não queria ficar replicando isso em cada app. Então eu criei uma aplicação de CEP que apenas possui métodos de pesquisa de CEP > Endereço e Endereço > CEP. Tudo isso em rest, sem autenticação já que era interno, além disso CEP não é algo tão restrito assim que precise autenticação.
Nas minhas apps, eu criei uma entidade endereço onde gravo os dados de endereço tão qual é um endereço, com os dados de logradouro, número, bairro, cep, etc... Não usei relacionamento porque senão eu teria que fazer consultas REST sempre que necessário exibir o endereço, o que me daria muito I/O na aplicação. Cliente possui um relacionamento 1:1 com Endereço, e quando um cliente é cadastrado, crio a entidade Endereço com os dados que veio do serviço REST.
Em um modo geral, nunca crie relacionamentos remotos. Tente evitar ao máximo comunicações remotas desnecessárias, então faça um cache local por demanda, ou grave os dados diretos em uma tabela local. Cada caso é um caso, então falo isso de uma forma bem genérica.
Quanto a autenticação... se for endereços, não vejo motivo. Mas de qualquer forma, o problema do GAE/J é que para usar uma autenticaçao a nivel de container você precisa ter um usuário cadastrado nos serviços do Google. Se fosse um servidor normal, eu diria para usar JAAS com autenticação BASIC ou DIGEST, ou até mesmo certificado digital. Mas como estamos falando do GAE/J, use a sugestão do Lucas, que é a mesma forma que muitos serviços usam por aí em suas APIs, como por exemplo o Akismet, Github, etc.
|
|
|
|
Singleton não é ruim não. O Singleton apenas não é usado da forma correta.
Uma classe ApplicationScoped, de certa forma, é um Singleton. Se você ler a especificação EJB 3.1, que saiu do forno a pouco tempo, entrou justamente uma anotação @Singleton, onde provê uma única instância da classe para cada instancia de VM. Ou seja, o mesmo comportamento do ApplicationScoped.
A diferença é que no VRaptor ApplicationScoped é inicializado quando a aplicação inicializa. Já no EJB inicializa somente quando é injetado em outra classe ou quando anotado com @Startup.
De qualquer forma, cuidado com isso. Gerar logs de forma "singleton" pode dar locks e até mesmo objetos do usuário alterados em threads diferentes, o que pode causar problemas bem desagradáveis.
|
|
|
|
Eu tinha os links aqui, porém não estou achando. Lembro que é algo relacionado com o commons-logging, não exatamente ao log4j. Porém como o log4j usa o commons-logging, ele herda o mesmo problema.
Em algumas aplicações tenho usado o java.util.logging por baixo do SLF4J, e nos mais atuais tenho usado o Logback (http://logback.qos.ch/), que a proprósito é do criador do LOG4J, o Ceki Gulcu.
Oops, enquanto escrevia o texto, achei: http://articles.qos.ch/classloader.html e http://articles.qos.ch/thinkAgain.html.
|
|
|
|
|
Basta usar o Results.representation(): http://vraptor.caelum.com.br/javadoc/br/com/caelum/vraptor/view/Results.html#representation()
|
|
|
|
Não precisa (e nem deve) usar o target=blank. Blank abre uma nova janela.
O que você precisa é simplesmente trocar o void para Download.
|
|
|
|
marcelolucio wrote:Estou com a versão 3.4.0
Este problema foi solucionado na versão 3.4.1. Você pode usar ela?
|
|
|
|
|
Nenhuma. Openshift é um ambiente JEE como outro qualquer. Rodo alguns projetos lá sem problemas.
|
|
|
|
f4314n0 wrote:esqueci de comentar que tambem anoto os metodos do dao que fazem alteração no banco com @Transactional.
Não é necessário, o vraptor faz todo o controle transacional.
|
|
|
|
|
O que eu comentei não é a questão de jars incompatíveis. Mas sim quantidade de jars que você não utiliza e que está no WEB-INF/lib. Ou seja, que poderiam ser apagados.
|
|
|
|