Depends on @JMX mbean name

[starksm64]

I'm looking at moving the naming services over to a beans.xml deployment, and one problem I'm seeing is that the mbean name associated with the @JMX annotation is not associated with the bean. This causes dependencies on the mbean name to fail:

*** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}

WebServer
 -> jboss:service=Naming{Create:** NOT FOUND Depends on 'jboss:service=Naming' **}

jboss.admin:service=PluginManager
 -> jboss.jmx:name=Invoker,protocol=jrmp,service=proxyFactory,type=adaptor{Create:Configured}

jboss.ejb:service=EJB3TimerService
 -> jboss:service=Naming{Create:** NOT FOUND Depends on 'jboss:service=Naming' **}

How can we get these depends to continue to work?

[starksm64]

Actually this is working. I had forgot that beans deployments now need to end in jboss-beans.xml and so none of the naming beans were even being deployed.

[anil.saldhana]

Actually this is working. I had forgot that beans deployments now need to end in jboss-beans.xml and so none of the naming beans were even being deployed.

I spent 30 mins of my time yesterday in tracing the log wondering why my xxx-beans.xml was not getting processed. How can we help users with this? Maybe some warning message hinting at xxx-jboss-beans.xml?

I did spend another 30mins figuring out why the ENC to obtain the JBoss security manager was not working. I had forgotten the "java:/jaas" prefix in the jboss-web.xml security domain configuration.
https://jira.jboss.org/jira/browse/JBAS-6060

It is our own conventions biting us after few days/months. ;)

[adrian.brock]

I spent 30 mins of my time yesterday in tracing the log wondering why my xxx-beans.xml was not getting processed. How can we help users with this? Maybe some warning message hinting at xxx-jboss-beans.xml?

This really falls under the "missing deployer" category.
But I think this is broken because we are generating some default metadata
regardless of whether other deployers actually process the deployment.

AbstractDeploymentUnit has

 public Object addAttachment(String name, Object attachment)
 {
 DeploymentContext deploymentContext = getDeploymentContext();
 deploymentContext.deployed();
 return deploymentContext.getTransientAttachments().addAttachment(name, attachment);
 }

So when the classloader deployers adds attachments, e.g. create
a default ClassLoadingMetaData for this top level deployment,
it is treated as deployed.
The same goes for the classpath deployer.

I think to fix this, we need a new method that says the attachment we are
adding should not be considered as flagging the deployment as really processed/deployed.

[adrian.brock]

This really falls under the "missing deployer" category.
But I think this is broken

We definitely need a test for this behaviour in the testsuite.