| Autor |
Mensagem |
|
|
Percebi um comportamento estranho no Struts 2, que aconteceu esporadicamente, que é o seguinte:
Pegue, por exemplo, a seguinte action:
E o seguinte JSP (acontece com Freemarker também, que é o que eu utilizo normalmente):
Acontece que às vezes (sim, às vezes, não sempre) ao executar a JSP (ou ftl) e passar pelo ${meuObjeto} o método getMeuObjeto() não é invocado e não ocorre nenhuma exceção, nenhum erro, nada. A página é exibida normalmente, mas o objeto vem nulo e o método não é invacado. Sempre passa pelo execute() normalmente, mas pelo getter não.
Alguém tem alguma idéia do que pode ser isso?
|
 |
|
|
Olá Carol,
Comece pelos manuais de integração da SEFAZ, você primeiro precisa entender como funciona todo o processo.
Depois quando começar a desenvolver, se tiver dúvidas é só postar por aqui. Bastante gente aqui já trabalhou com isso (inclusive eu) e já passou por várias dificuldades iniciais. Mas é tranquilo no final das contas.
Boa sorte
|
|
|
|
Pessoal,
Estou gerando os xml e assinando. Tudo está passando normalmente na validação e sendo enviado com status de sucesso para a sefaz. Mas a situação fica sempre "Em processamento pelo SEFAZ".
Se eu pego o mesmo xml, importo para o sistema emissor da SEFAZ e assino nesse sistema, a situação vai para "Autorizada" imediatamente.
Como eu disse,eu não estou recebendo nenhuma mensagem de erro. Mesmo quando envio pelo meu sistema eu recebo a mensagem de "Lote recebido com sucesso", mas não consigo encontrar a NF-e nas consultas oferecidas no site da SEFAZ.
Alguém sabe o porque disso?
|
|
|
|
fabioebner wrote:g4j entao cara nao da para fazer com interface nao.. pq o nome do metodo vai ser sempre o mesmo porem o conteudo muda de classe para classe, e a classe q vai executar esse metodo sabe qual classe eu esou recebendo ou o conteudo do metodo.. apenas executar. entendeu
Seu problema é facilmente resolvido com a utilização de interface sim... você está confundindo as coisas.
|
|
|
|
marsola2k wrote:Pessoal,
Como eu faco para melhorar minha performace usando o hibernate !
Normalmente a 1ª chamada da sessao eu levo 4500 ms ou 4s. Será que esse valor pode ser reduzido, se eu melhorar minha consulta ? Mas nessa primeira ocasiao, eu consulto duas veezes dadso na tabela.
Estou usando o hibernate e o mysql
Obrigado
Você está criando a SessionFactory nesse momento? A criação da SessionFactory é realmente custosa. Você está consultando somente uma tabela ou fazendo joins entre várias tabelas? Nesse segundo caso, sempre é possível realizar otimizações, mas isso vai demandar uma análise do modelo e de como o hibernate funciona.
|
|
|
|
sergiotaborda wrote:Existe uma boa razão para não usar o hibernate : vendor lock in. Se você está criando um ERP espera-se que vc queira ter dominio
sobre a tecnologia que usa. Caso isso não seja um problema, ignore.
Uma menos boa razão, mas também um razão é o padrão Open Session in View, que básicamente signfiica que para que o Lazy loading funcione vc tem que manter conhecimento sobre a persistencia em outras camadas. ( o correto seria open session em model )
Este padrão é um tanto ò quanto parecido com uma gambiarra e até um anti-pattern. Sem ele , o hibernate não funciona como seria esperado.
Por estas duas coisas eu não usaria o hibernate.
A opção é então criar o seu próprio mecanismo. Não me venham com a estoria de inventar a roda porque o hibernate não é perfeito. O desafio aqui é se vc tem uma equipa com capacidade para fazer esse trabalho. Se a resposta não for um sim convicto, então use o hibernate, mesmo com os seus defeitos e limitações. Inclua-o na sua arquitura e invista em aprender a usar as suas funcionalidades avançadas.
Como tudo é uma questão de escolha (trade-off).
Não concordo com nada que foi exposto acima...
dooda, use hibernate tranquilamente, não há nenhum motivo que justifique você não usá-lo.
|
|
|
|
saoj wrote:A mensagem parece ser essa: "Programe como quiser, faça uma arquitetura bem interdependente e enroscada, onde tudo depende de tudo. E se der verdinho parabéns!"
Você está um pouco equivocado... testes unitários contribuem justamente no sentido contrário de que você afirmou.
|
|
|
|
victorwss wrote:Pode ser uma cópia do Maker também. 
Na verdade ela foi desenvolvida com o Maker, mas criou consciência própria e decidiu roubar o mercado do seu criador... rs 
|
|
|
|
peerless wrote:"leiaute" está errado. uma vez que layout é uma palavra composta de outras duas nativas da língua inglêsa. Leiaute seria a pronuncia e não deveria servir como uma tradução para isso, até pq não é! Comecem a chamar então de : camada espelho, hehe
Leiaute é aceito formalmente na língua portuguesa, procure num dicionário.
|
|
|
|
raf4ever wrote:se me mostrarem só um que tenha "leiaute",rasgo meu diploma da 4a série 
E aí, já rasgou o seu diploma?
|
|
|
|
Só pra espalhar um pouquinho de discórdia... 
http://www.linhadecodigo.com.br/Artigo.aspx?id=1723
PS.: Eu não concordo com o artigo.
|
|
|
|
Lezinho,
Aspectos era justamente uma das outras alternativas que eu tinha pensado além dos interceptors... vou dar uma olhada no seu post.
E calcado, eu continuo não entendendo o que você diz em "não ser comum". O próprio exemplo de Fowler sobre Repository mostra algo semelhante a isso e isso me parece bem lógico.
|
|
|
|
pcalcado wrote:Na verdade não é muito comum -apesar de não haverproblema real- ter uma Entity que acessa Repository diretamente.
Mas essa não é uma das idéias do Repository??? Se não, quem deveria retornar o saldo nesse caso? Cade os objetos "inteligentes"? 
|
|
|
|
|
Mas essa seria uma forma "usual" de se injetar reporitories em entidades de domínio?
|
|
|
|
Eu imaginei que você diria isso, por isso eu não fiz direto daoConta.get() e sim daoCliente.get().
Acho que fica complicado eu fazer isso no dao porque eu poderia ter cliente.getBanco().getConta().getSaldo(). Ou seja, quem vai criar todo esse grafo de objetos pra mim é o hibernate. Eu teria que sair varrendo eles pra injetar esse cara? E se eles estiverem vindo por lazy pra mim, vou forçar o seu carregamento? Ruim isso, né?
Uma idéia pra injetar o repository seria no interceptor. Funciona. Parece ser a solução menos intrusiva que eu encontrei até agora. Mas ainda assim não me agrada. O que acho ruim nesse caso é que saio um pouco do controle do spring (EU estou garantindo que ele será injetado) - e já que estou usando spring, ele deveria cuidar disso pra mim. Vou ter que criar uma fábrica pra isso, ou chamar um bean do spring diretamente... não gosto muito disso.
Ele também não funciona com um objeto em que EU dei new.
Mas aí entra outra questão: como este método deveria se comportar nesse caso? Talvez com uma das opções que eu disse no meu post anterior. Qual a sua opinião?
|
|
|
|