DeploymentScopeBaseName from JAR prepending JNDI Name

[alrubinger]

From JNDIView, we've got:

+- ejbthree1066 (class: org.jnp.interfaces.NamingContext)
 | +- CalculatorBean (class: org.jnp.interfaces.NamingContext)
 | | +- remote (proxy: $Proxy96 implements interface org.jboss.ejb3.proxy.JBossProxy,interface org.jboss.ejb3.test.ejbthree1066.Subtractor,interface org.jboss.ejb3.test.ejbthree1066.Adder)

Previously, this looked like "ejbName/remote", and I don't see any discussions on the forum for "jarName/ejbName/remote".

The PackagingBasedJndiBindingPolicy.getDefaultRemoteJndiName() is prepending the DeploymentScopeBaseName:

String name = summary.getEjbName() + PackagingBasedJndiBindingPolicy.JNDI_SUFFIX_REMOTE;
 if (summary.getDeploymentScopeBaseName() != null)
 name = summary.getDeploymentScopeBaseName() + "/" + name;
 return name;

We need this to uniquely scope EARs, but is this the desired behaviour for JAR deployments? Another issue affecting a large percentage of our TestSuite. :)

If correct, I'll update the tests, if incorrect, we'll fix.

S,
ALR

[starksm64]

I changed the resolution logic in the container to always delegate to the DeploymentScope, so there always is one now. Previously this only existed for ears. As to whether the base name should be empty for non-ears is a detail that can be changed.

[starksm64]

I changed the JBoss5DeploymentScope to use an empty "" base name if the deployment is not an ear, so that should help with legacy expectations for the jndi name.

[starksm64]

Whoops, didn't read the logic carefully enough. Now its null if its not an ear.

[alrubinger]

Scott's fixes have led to ~113 regressions resolved in EJB3 TestSuite:

http://jboss.hudson.alrubinger.com/job/EJB3_Plugin_AS_TRUNK/116/

S,
ALR

[wolfc]

Not reproducible here and on QA.

[wolfc]

This is becoming ugly.

A deployment scope was meant to denote a JavaEEApplication (/ EAR) and thus it implements it as such. If the usage has changed we should at least disconnect DeploymentScope from JavaEEApplication.

Furthermore the determination of whether there is an EAR or not appears to be broken. As the jboss-seam-dvd application gets deployed with a deployment scope with a null base name.

[brian.stansberry]

See also related discussion at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=135477

[starksm64]

"wolfc" wrote:
This is becoming ugly.
A deployment scope was meant to denote a JavaEEApplication (/ EAR) and thus it implements it as such. If the usage has changed we should at least disconnect DeploymentScope from JavaEEApplication.

Its a resolution context/api now. Is the JavaEEApplication still useful?

"wolfc" wrote:

Furthermore the determination of whether there is an EAR or not appears to be broken. As the jboss-seam-dvd application gets deployed with a deployment scope with a null base name.

I'll have to see why that is. I see Ales has added back in a hack to check the deployment unit suffix for ".ear" to get the jboss-seam-dvd application to work.

[alesj]

I see Ales has added back in a hack to check the deployment unit suffix for ".ear" to get the jboss-seam-dvd application to work.

That was Carlo.

[alesj]

"alesj" wrote:

I see Ales has added back in a hack to check the deployment unit suffix for ".ear" to get the jboss-seam-dvd application to work.

That was Carlo.

But it was a good hack. :-)
We at least saw that we're on the right path with making Seam run in AS5.

[starksm64]

The main complication is that the Ejb3Deployer is processing an ear deployment unit for essentially no reason. In the past I guess this is what was creating the root ejb3 DeploymentUnit to be able to resolve nested ejbs, but this is handled by other deployers.

Its also still doing too much processing that prepares for annotation scanning that is also done elsewhere. At some point this needs to be overhauled. For now I have just corrected the check for a nested/scoped ejb jar and the seam booking testcase is running.

[wolfc]

That has to do with persistence units at ear level.

As for the deployment scope or some sort of JavaEEApplication, that should come from some EAR deployer, not the Ejb3Deployer.

[starksm64]

"wolfc" wrote:
That has to do with persistence units at ear level.

Can't that be moved out?

"wolfc" wrote:

As for the deployment scope or some sort of JavaEEApplication, that should come from some EAR deployer, not the Ejb3Deployer.

Easy to do.

[wolfc]

I think it must be moved out to a separate JPA deployer, which does persistence deployment for ear, war and jar.

This should not be done in AS trunk, it should happen in a new project. In trunk there should be a switch to turn off persistence deployments, which should then be picked up by the new JPA deployer. That allows for a gradual transition.

The interesting integration point will be the persistence unit injection facilitator.