A exceção é da forma:
javax.management.InstanceAlreadyExistsException: jboss.management.local:<MBEAN NAME> already registered. at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233) at sun.reflect.GeneratedMethodAccessor107.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
O JBoss, atendendo à JSR-77, registra sobre o domínio jboss.management.local todos os pacotes deployados. O problema ocorre quando dois pacotes com o mesmo nome estão presentes. A princípio isso nunca aconteceria, os OS não permitem isso. Mas o JBoss tem a capacidade de fazer deploy de pastas aninhadas, além de poder ser configurado para possuir várias pastas de deploy.
Então a solução mais simples seria alterar o nome dos pacotes (pode ser também uma Persistence Unit ou qualquer outro deployable) conflitantes. Se essa não for uma opção, é possível também desabilitar a implementação JSR-77 do JBoss, que não deve trazer maiores consequências (a não ser que esses MBeans estejam sendo explicitamente usados).
Para tanto basta remover ou desabilitar (adicionando a extensão .rej) o arquivo $JBOSS_CONF/deployers/jsr77-deployers-jboss-beans.xml




