| Autor |
Mensagem |
|
|
|
Acho que faz diferença (irrelevante) no tempo de compilação, somente.
|
 |
|
|
Eu acho que não, se você reutilizar código dele.
Nomes podem ser mudados (até onde eu sei), e você pode assumir o projeto sim, mas o escopo das suas alterações é que deve ser discutido - código reutilizado deve conter o devido crédito ao autor original.
|
|
|
|
Bem, agora que você se desculpou.... 
Caused by: java.rmi.RemoteException: null; nested exception is:
java.lang.IllegalStateException: Attempting to execute an operation on a closed EntityManager.
Preste atenção na exceção lançada. Uma busca rápida no Google e no Java tutorial vai te informar que você está tentando reutilizar um contexto de persistência que já foi fechado pelo container. Não tem como apontar exatamente o que você está fazendo de errado sem olhar código, mas com certeza é um problema relacionado a manutenção do estado do seu componente server side, bem como sua transação JTA. Quando você executa o método pela segunda vez, está usando uma referência antiga do EntityManager, já fechada. Na terceira você obtém uma referência nova, e aí o erro não acontece. Investigue também a referência que você está guardando do bean remoto.
|
|
|
|
Para ajudar com sua arquitetura, pesquise no Google por "MVC" - Model View Controller - e os resultados que você encontrar devem te dar bastante informação para você começar. Quando estiver confortável com o conceito de MVC, pode então dar uma olhada nas diferentes arquiteturas que existem por aí, e como elas fazem uso de diversas camadas, entre elas, as do MVC.
Para segurança de aplicativo, normalmente usa-se JAAS, mas existem alternativas também. O JAAS está presente em aplicativos Desktop (clientes comuns ou distribuídos), e aplicações/componentes server side. Pode ser um bom começo para você estudar.
Boa sorte.
|
|
|
|
Acho que o ônus do controle não cabe só ao moderador. A comunidade de usuários deve também ser vigilante.
É simples... Denuncie tópicos problemáticos... Evite polêmicas e comparações esdrúxulas que potencialmente geram flames e trolls... E principalmente: seja exigente com o conteúdo. Corrija os colegas que pisarem na bola. Saiba postar! Use bom português (ou inglês, espanhol, alemão... mas escreva direito). Seja conciso, relevante, e evite postar redundâncias.
Essa moçada pode, talvez aprender com o bom exemplo
Edit: Tô aqui no fórum desde 2005... e concordo com o autor do tópico. O público (e conteúdo) já foi mais interessante.
|
|
|
|
celsomarcos wrote:Quem nunca baixou um episódio do Lost que atire a primeira pedra!!!!
Té mais....
Pedrada na sua cara! Nunca baixei um episódio do Lost
Mas, claro, já fiz downloads ilegais de músicas. Mas só compro jogos originais. Sou contra a pirataria!... E concordo com a condenação desses senhores aí.
O que tem que ser revisto é esse modelo que gera tantos paradoxos... como os da minha frase acima.
|
|
|
|
Three letters - FUD!
Será que os fórums da Borland ficaram assim quando ela foi comprada? Vou dar uma olhada no web archive :p
|
|
|
|
Não vejo razão para toda esta preocupação. Qualquer companhia que tivesse comprado a Sun teria sua própria estratégia para a 'tecnologia' Java, e esta estratégia invariavelmente agradaria a alguns, e desagradaria à outros.
A nós, desenvolvedores, nos cabe apenas seguirmos o caminho pragmático. Não podemos nos dar ao luxo da dependência tecnológica. Temos que ser flexíveis para continuarmos sendo competitivos no mercado. E flexibilidade significa manter a mente aberta, analisar velhos problemas sob novas perspectivas.
Assim, sempre teremos alternativas, e com a flexibilidade, seremos mais úteis à linguagem que utilizamos e gostamos; novas idéias e conceitos nascem dessa idéia pragmática. Acho que o Java já amadureceu a ponto de não se tornar o novo C ou o novo COBOL. Graças a comunidade. E não acredito que empresas influentes como a Oracle vão desperdiçar esse potencial. Muito pelo contrário...
|
|
|
|
|
Google? Acho que não. Esse segundo player deve ser a HP.
|
|
|
|
Amigo, o meu mapeamento está funcionando sem nenhum problema. Acredito que você esteja enfrentando problemas não relacionados ao mapeamento em si. Sugiro testar o mapeamento separadamente, e depois incluir no seu caso de uso e tentar identificar problemas.
Desculpe não poder ajudar muito =)
|
|
|
|
Classe "A"
Classe "B"
Antes de persistir uma instância de "A", eu faço o relacionamento entre "A" e "B" via "a.set(b)".
|
|
|
|
|
Esse é o seu relacionamento. Eu peguei um exemplo pronto aqui do trabalho, na pressa. 'workOrder' é a propriedade que é de fato a entidade relacionada a seu POJO, a qual ele usa como valor da chave.
|
|
|
|
É muita inocência imaginar que essa compra não vai acontecer. Com os resultados que a Sun vem apresentando nos últimos anos - independente de crise financeira - eu acredito ser uma questão de tempo até que setores da companhia sejam vendidos para diferentes competidores.
Reforço a opinião de preferir que a IBM ou a Oracle compre, ao invés da Microsoft; não imagino que ambas consigam manter a "tecnologia Java" viva tal qual a Sun o fez; mas definitivamente, são opções melhores que a Microsoft.
E também acredito que uma compra da Sun por parte da IBM pode ter efeitos positivos. Apesar dos conflitos na linha de produtos de software, acredito que a IBM saberá fazer dinheiro com as ferramentas, coisa que a Sun não conseguiu. E para isso, a IBM estaria disposta a tomar medidas que a Sun não foi capaz de implementar; entre elas, o expurgo das APIs antigas/obsoletas da JDK, popularização do Java no client side, etc.
|
|
|
|
Problema chato pra caramba. A JPA pura não vai conseguir te ajudar. Se estiver usando Hibernate, tens uma chance:
Procure, portanto por generic generator no hibernate.
|
|
|
|
Não sei se você vai querer ou poder usar isto; mas bindings OpenGL costumam ser bastante práticos para essas tarefas. Os problemas são as desvantagens agregadas: código nativo, framework razoavelmente grande. Mas se você manipula imagens nesse nível, talvez se interesse em ao menos conhecer os recursos disponíveis. Procure por JOGL e LWJGL.
A API de manipulação de imagens em java é bastante competente, mas o fato é que a acelaração gráfica só é possível em ambientes windows, e ainda assim, com diversas exceções. Estas APIs que eu mencionei vão te dar um desempenho melhor e mais controle sobre os recursos gráficos, mas em contrapartida, trazem as desvantagens que eu mencionei.
|
|
|
|