[starksm64]

The following has been added and will be in the jboss-metadata-1.0.0.Beta11 release. calling determineContainerName() is what you would do to reliably get the name the container was registered under.

Added:

 /**
 * Get the kernel name for the ejb container. This is the managed property
 * version admin tools may use to control the name. Generally its not set
 * and the server will set the name via the generatedContainerName
 * non-managed property.
 *
 * @see #setGeneratedContainerName(String)
 * @return containerName property value.
 */
 public String getContainerName()
 public void setContainerName(String containerName)

 /**
 * Get the generated kernel name for the ejb container. This is the
 * non-managed property version that the server would use to set the name
 * it generated when no containerName property existed.
 *
 * @see #getContainerName()
 * @return generatedContainerName property value.
 */
 @XmlTransient
 public String getGeneratedContainerName()
 public void setGeneratedContainerName(String containerName)

 /**
 * Get the kernel name for the ejb container. This is either the
 * containerName managed property, or a runtime generated name set via
 * the non-managed generatedContainerName property.
 * @return the kernel name for the ejb container
 */
 public String determineContainerName()

[heiko.braun]

According to http://jira.jboss.org/jira/browse/EJBTHREE-1334 EJB3 core is not going to assign that name anymore, but instead pull from the meta data as well. How and when is it going to be created? I am asking in terms of deployment order. Would it be sufficient to depend on

addInput(MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME);

to get qualified meta data that contains the container name already?

[starksm64]

The name will still typically be set by the Ejb3Deployers/EjbDeployers, so one of their outputs needs to be used to order the ws deployer. The MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME name is an input into the ejb deployers and so cannot be used.

You can depend on the KernelDeployment.class output that both ejb deployers now produce for the mcbeans. The only potential problem with this is if the ws deployer itself was trying to produce metadata for kernel/bean deployments. Does it?

Alternatively, I guess each deployer could just add a boolean indicating its processed the deployment under a EJB_DEPLOYER_CONSTANTS.DEPLOYER_COMPLETE key. We should probably have a more natural way to depend on non-unique output from a prceeding deployer by simply depending on the deployer, but I'll add the DEPLOYER_COMPLETE if the KernelDeployment output will not work.

[starksm64]

The jboss-metadata-1.0.0.Beta11 release is out.

[wolfc]

The name will still typically be set by the Ejb3Deployers/EjbDeployers, so one of their outputs needs to be used to order the ws deployer. The MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME name is an input into the ejb deployers and so cannot be used.

No, the EJB deployers should consume complete consumable metadata and output some MC beans (/ EJB containers). We should just paste an extra deployer in between. Aren't we doing the same with JNDI names?

[heiko.braun]

Carlo can you take care of it?

http://jira.jboss.org/jira/browse/EJBTHREE-1335

[starksm64]

"wolfc" wrote:

The name will still typically be set by the Ejb3Deployers/EjbDeployers, so one of their outputs needs to be used to order the ws deployer. The MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME name is an input into the ejb deployers and so cannot be used.

No, the EJB deployers should consume complete consumable metadata and output some MC beans (/ EJB containers). We should just paste an extra deployer in between. Aren't we doing the same with JNDI names?

Essentially, yes, the MappedReferenceMetaDataResolverDeployer provides the resolved jndi name and could specify the default container names as well, externalized via a policy plugin if needed.

[wolfc]

The current implementation relies on the start of Ejb3Deployment to fill in the appropriate meta data, but there is no explicit dependency defined anywhere on the Ejb3Deployment object. So the WebServiceDeployerEJB can run before the Ejb3Deployment is started hence a NPE (https://jira.jboss.org/jira/browse/JBAS-5968).

I think the logic in WebServiceDeployerEJB should be moved to WebServiceDeployment, so it can have that dependency defined.

In reality the web service end point should depend on the ejb container.
I don't know yet how to resolve it to that point. Having an object name lying around somewhere is not the way to go (https://jira.jboss.org/jira/browse/EJBTHREE-1335).

[semanticlance]

I am seeing this error in 5.0.0.GA with an ear that deployed successfully in 4.2.0.GA.
Any advice for tracking down the offending code?

08:48:41,910 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/home/lwbyrd/pkg/jboss-5.0.0.GA/server/default/deploy/blackbook.ear state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: java.lang.NullPointerException: name cannot be null
 at org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerEJB.internalDeploy(WebServiceDeployerEJB.java:100)
 at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
 at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
 at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
 at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
 at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
 at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
 at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
 at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
 at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
 at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
 at org.jboss.Main.boot(Main.java:209)
 at org.jboss.Main$1.run(Main.java:547)
 at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException: name cannot be null
 at javax.management.ObjectName.construct(ObjectName.java:342)
 at javax.management.ObjectName.<init>(ObjectName.java:1314)
 at org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerEJB.internalDeploy(WebServiceDeployerEJB.java:96)
 ... 21 more