| Autor |
Mensagem |
|
|
Legal, aquele problema foi solucionado então.
O trecho que você publicou aqui não diz nada sobre o erro. Cole aqui um bom pedaço da stack trace sobre erro que ocorreu na hora que o deploy foi feito para vermos oque pode ser, ou anexe seu server.log
|
 |
|
|
Então esta caindo para o que você apontou "Ou você realmente tem duas PUs com o mesmo nome (talvez em diferentes aplicações),.... " como eu verifico estas PUs?
PU = Persistence Unit -> http://docs.jboss.org/ejb3/docs/reference/build/reference/en/html/entityconfig.html
Ela deve estar dentro do diretório META-INF de suas aplicações.
O atributo "name" deve ser exclusivo para cada arquivo persistence.xml instalado sobre o JBoss, se não é gerado o erro que você esta tendo. No entanto, ao que me parece o seu caso é devido algum problema com o plugin do eclipse. Se for isso, meu post anterior deve ajudar.
|
|
|
|
No JBoss se configura datasources assim:
http://community.jboss.org/wiki/configdatasources
Porém, dentro da pasta jboss-as/docs/examples/jca você já vai ter templates de datasources prontos para a maioria dos bancos de dados, é só completar com as informações do seu banco e mover para a pasta deploy.
Fui nas configurações do Jboss e a opção "Use workspace metadata (does not modify JBoss deploy folder)" está desabilitada, ou seja, já não estava usando esta opção. A opção que está marcada é a "Use the Jboss deplay folder".
Então existe algo inconsistente entre sua aplicação e a configuração do plugin "Servers". Veja o seu log:
vfsfile:/home/danilo/ambiente_dev/workspaces/workspace_XXX/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_Runtime_Server1303252185488/deploy/XXXX.war/ -> org.jboss.deployers.spi.DeploymentException: Error deploying: persistence.unit:unitName=#XXXX_VPM_ENTITYMANAGER
... existe um war deployado dentro do .metadata e é lá que esta ocorrendo o erro. Pode ser que em algum momento esta aplicação estava sendo deployada neste local e agora esta correto (na pasta deploy do JBoss mesmo) e isso esta causando este conflito (ele lê o deploy real do JBoss encontra uma Persistence Unit depois olha para o .metadata e encontra a mesma Persistence Unit, então dá erro dizendo que já foi instalado)
Tente corrigir esse erro da seguinte forma:
- Com o JBoss parado, pelo Eclipse clique sobre seu JBoss em "Servers" com o botão direito, na opção Add and Remove... e remova sua aplicação.
- limpe o conteúdo da pasta /home/danilo/ambiente_dev/workspaces/workspace_XXX/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_Runtime_Server1303252185488/deploy/
- Certifique-se novamente que o JBoss esta configurado no Eclipse para "Use the JBoss deploy folder"
- Inicie o JBoss (sem a aplicação)
- Vá novamente em "Add and Remove.." e adicione sua aplicação pelo eclipse.
Se você não estiver realmente duplicando nomes de PersistenceUnits dentro do JBoss este erro deve desaparecer
|
|
|
|
A InfoQ-BR publicou o conteúdo da entrevista com o Gavin King traduzido.
Para quem se interessar:
http://www.infoq.com/br/news/2011/04/ceylon
|
|
|
|
"empresaImgHome.instance" lhe dará uma nova instancia de EmpresaImg (like new EmpresaImg()), a qual possui o atributo imgBanner nulo.
|
|
|
|
Olá Santos,
Acho que o maior ponto aqui é "porque" perder o cliente? Você pode ter vários modelos de negócio trabalhando com JBoss.
Você tem algum vínculo com a Borland?
|
|
|
|
Olá Danilo,
Na realidade a documentação refere-se a outra coisa, seu erro esta em outro lugar.
A mensagem de erro diz que vc possui duas persistence units "deployadas" com o mesmo nome no JBoss:
"persistence.unit:unitName#XXXX_VPM_ENTITYMANAGER is already installed"
Ou você realmente tem duas PUs com o mesmo nome (talvez em diferentes aplicações), ou é um problema de sincronização com o .metadata do plugin "servers" do Eclipse.
Cara, uma dica importante - NUNCA USE o deploy em .metadata, isso pode dar uma canseira danada.
Com o servidor parado, vá no Eclipse e clique na view "Servers". Lá de dois cliques no seu JBoss, isso irá abrir a configuração do servidor. No rodapé desta view você tem a aba Overview e Deployment, clique em Deployment.
Lá você vai ver três opções, no seu caso deve estar selecionado "Use workspace metadata". Altere isso para "Use the JBoss deploy folder" e clique em salvar.
|
|
|
|
asrsantos wrote:Borland Enterprise Server. Sei muito pouco também. Até onde sei é um servidor de aplicações Java. O cliente quer trocar para JBoss.
Obrigado pelo interesse na thread.
Claro, o Borland AppServer!!! Nem passou pela minha cabeça que alguém utilizasse isso hoje em dia.
Realmente difícil pensar em um argumento sequer que justifique o uso de um servidor tão defasado.
|
|
|
|
Tem certeza que você esta comparando dois projeto que possuem o mesmo objetivo?
Eu nunca ouvi falar sobre o acrônimo "BES", mas com uma rápida busca na internet não achei nada referente a "Java EE Application Server" com este nome.
Do que de fato se trata?
|
|
|
|
Apenas como info, quem esta implementando o compilador é Andrew Haley, membro do OpenJDK team.
O Andrew tem uma bagagem excelente em linguagens e compiladores: http://www.jboss.com/about/leadership/jsr/haley.html
Ele estando no time do Ceylon é mais um motivo para acreditar que o projeto tem tudo para decolar.
|
|
|
|
Cris, Clebio, poste o erro novamente.
Com a configuração que postei não faz mais sentido ocorrer algum erro em ..\.metadata\.plugins\org.jboss.ide.eclipse.as.core\JBoss_5.1_Runtime_Server1287597914017\deploy
[]'s
PS: qual a versão do Seam+JBossTools+Eclipse+JBoss AS que vocês estão utilizando?
|
|
|
|
marcosalex wrote:Já que o assunto do tópico voltou e os ânimos amenizaram, alguém sabe se é possível usar o Seam sem usar EJB? Se for possível, tem vantagem?
É muito comum utilizar Seam sem EJB. Para falar a verdade, no livro Seam in Action de Dan Allen a maioria dos exemplos são focados em sua utlizaçao sem EJB.
No Seam2 (JavaEE5), independente de usar EJB, você ainda tem:
- DI com gerenciamento de contexto (idéia que gerou o CDI e outros frameworks como Spring WebFlow)
- Escopo adicional de conversação
- EL extendida com JBossEL
- Várias melhorias ao JSF
- Sistema de eventos (Component-driven events, aka Observer model)
- Frindly URL
- Exception Handling
- Framework interno para autenticação e segurança
- Framework interno para consultas e persistência
- Scafolld apartir de entidades ou através de tabelas de banco
- Integração extremamente simplificada e goodies para diversas tecnlogias ( jBPM, Drools, Hibernate/JPA, jFreeChart, Captcha, envio de Email, JMS, iText, jExcel, RSS, RestEasy )
E mais várias outras coisas como desenvolvimento de componentes em Groovy, trocar view JSF por Wicket ou GWT, mesclar o sistema de DI ou trocar completamente por Guice ou Spring ... enfim, coisa pra caramba 
No Seam 3, vários componentes ainda estão para serem lançados. Várias idéias presentes no Seam 2 já foram incluídas no próprio CDI e suas extensões foram para o Seam 3, como os citados em http://relation.to/Bloggers/Seam300FinalReleased
-
|
|
|
|
fredferrao wrote:Noticia sobre Seam 3.0.0, e 6 paginas de discussão sobre WELD!!! Maravilha em!!!!
Você tem razão Fred. Eu já disse umas 4 páginas atrás que essa discussão não era para ser o foco desta thread e para iniciar um novo tópico caso alguém quisesse debater sobre isso (Weld). Mas não funcionou.
Minha participação sobre o assunto "weld" neste tópico esta encerrada.
|
|
|
|
Mas esta tudo no repositório público, sempre esteve chun. Compile, faça diff, teste e use, de nenhum jeito você terá suporte de alguma empresa mesmo, afinal de contas você não esta pagando por isso. Então arregasse as mangas e faça o backport.
... mais uma vez, no JBoss 6 o Weld 1.1.0 esta redondo e passando com louvor no TCK desde Janeiro.
Se você esta tendo problema com o peixe de vidro, se entenda com a Oracle 
|
|
|
|
Uma rápida busca no Google achei esta thread que pode lhe ajudar em aplicar o fix para a sua versão do Weld:
http://www.sfwk.org/Community/LeakingOrNot
Do resto, me desculpe caso eu tenha citado o MySQL em não ter backport, realmente ele possui. O que disse mencionando Hibernate, Spring, Primefaces, Seam, Struts, GWT e poderia citar outros frameworks Java como Guice, Axis, Mvel, EclipseLink, etc... é que essa política não é uma obrigatoriedade e nem uma prática comum em qualquer projeto open source. Particularmente falando de bibliotecas/frameworks Java, é algo muito raro. Como disse, isso não impede de você aplicar um patch que esta no uptsream para sua versão atual. Afinal de contar o código é aberto - ou pagar alguém para fazer isso.
Não quero minimizar problema algum, só estou afirmando o tempo todo que o responsável por escolher uma tecnologia e seus componentes é o arquiteto da aplicação. Se o arquiteto da aplicação que você trabalhou optou por usar o Weld 1.0 no Glassfish, sem suporte algum, ele deveria saber dos riscos q estaria assumindo. Optar em usar JavaEE6, mesmo você reafirmando que não se tem opção em escolha, também foi uma escolha dele, não foi? Entende agora o que eu digo por "conta e risco".
O comprometimento da equipe que trabalha com o Weld é corrigir os bugs, implementar features e fazer passar no TCK. Se ele passou no TCK mas não esta se integrando muto bem com o Glassfish (a mudança da versão 1.0.1 para 1.1 não tem impacto no JBoss 6), talvez o problema não seja exclusivamente do Weld, não é mesmo? 
|
|
|
|