[jboss-metadata] EJB mappedName as a Base?

[alrubinger]

@see ResolveJndiNameDecoratorUnitTestCase.testResolvedJndiNameWithMappedName.

@SuppressWarnings(value="deprecation")
 public void testResolvedJndiNameWithMappedName()
 {
 // Obtain MD, set mappedName, and define expected values for resolution
 JBossSessionBeanMetaData beanMD = getDecoratedEjbMetaData();
 beanMD.setMappedName("testResolvedJndiName-mapped-name");
 String expectedHome = "testResolvedJndiName-mapped-name/home";

 // Resolve
 String resolved = beanMD.getHomeJndiName();

 // Test
 assertEquals(expectedHome, resolved);

 // Test Deprecated, backwards-compat behavior (may be removed when these methods no longer exist, JBMETA-68)
 String resolvedDeprecated = beanMD.determineResolvedJndiName(KnownInterfaces.HOME, null);
 assertEquals(expectedHome, resolvedDeprecated);
 }

Here we're testing that when a mapped-name is specified, that value is used for the base upon which we'll bind a Home (ie "x/home"). The same concept applies for interface-specific bindings.

The problem is that mappedName cannot both be a base *and* the default business interface target; otherwise there will be a JNDI "NotContextException" when using it as a base.

JIRA is http://jira.jboss.com/jira/browse/JBMETA-75.

This is the issue preventing another jboss-metadata release, its integration with EJB3 Core, and finally the integration of EJB3 Proxy.

S,
ALR

[alrubinger]

So my question is:

What does mappedName represent?

1) Default Remote Business JNDI Bind Name
2) JNDI Base Name (not all JNDI Policies are required to use a base in this fashion)

It cannot be both 1) and 2).

If 1), we must ignore the mappedName value and use the default base for Home/Local/Interface-specific bindings.

If 2), we must update the jboss-metadata TestSuite

S,
ALR

[alrubinger]

Commits in r75783 to use mapped-name only for default remote business interface, and not use it as a base upon which to build.

Updated the failing (incorrect) test cases as well.

S,
ALR

[starksm64]

I think it should be the base jndi name, the equivalent of the jboss.xml jndi-name.

[starksm64]

Have we stated a concise summary of every binding that can result given?

- only a mappedName/jndi-name (these should be equivalent)
- only the default jndi binding policy
- both a mappedName and jndi binding policy

[alrubinger]

I think it should be the base jndi name, the equivalent of the jboss.xml jndi-name.

jboss.xml jndi-name isn't a base..?

If the mappedName is a base name, then we can't bind anything directly to it. It'd be misleading for a bean provider to say "mappedName=MyBean" and then have to access "MyBean/remote". So mappedName should be similar to our @RemoteBinding handling, no?

Carlo and I discussed this earlier, where mapped-name/jndi-name directly specify remote business binding, and all others use the default base. So given "mapped-name=MyBean" and a BasicJndiBindingPolicy:

Default Remote Business Interface: "MyBean"
Remote Home: "ear/jar/ejb-name/home"
Remote Specific Business Interface: "ear/jar/ejb-name/remote-interfaceName"

S,
ALR

[alrubinger]

Have we stated a concise summary of every binding that can result given?

I don't believe so, though once finalized we should update the Wiki at:

http://wiki.jboss.org/wiki/DevJNDIBinding

- only a mappedName/jndi-name (these should be equivalent)

mapped-name/jndi-name assigned to default remote business interface. All others to fall back on Default JNDI Binding Policy (which is required, if not specified at the EAR/JAR/EJB level then we default to BasicJndiBindingPolicy)

- only the default jndi binding policy

Policy responsible for generation of all JNDI targets.

- both a mappedName and jndi binding policy

mapped-name/jndi-name overrides default remote business interface only.

S,
ALR

[starksm64]

"ALRubinger" wrote:

I think it should be the base jndi name, the equivalent of the jboss.xml jndi-name.

jboss.xml jndi-name isn't a base..?

Its the remote home for ejb2, not sure what it has been used as for ejb3.

"ALRubinger" wrote:

If the mappedName is a base name, then we can't bind anything directly to it. It'd be misleading for a bean provider to say "mappedName=MyBean" and then have to access "MyBean/remote". So mappedName should be similar to our @RemoteBinding handling, no?

Carlo and I discussed this earlier, where mapped-name/jndi-name directly specify remote business binding, and all others use the default base. So given "mapped-name=MyBean" and a BasicJndiBindingPolicy:

Default Remote Business Interface: "MyBean"
Remote Home: "ear/jar/ejb-name/home"
Remote Specific Business Interface: "ear/jar/ejb-name/remote-interfaceName"

In my view its similarly strange that there is no relationship to the other bindings. I see the issue with using a simple mappedName like MyBean not allowing uses like both MyBean and MyBean/home.

I took a look at the glashfish ejb faq:
https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html

and it seems they have adopted a similar usage to have mappedName be the remote business interface, or at the level of xml its just the same as jndi-name for the reference global binding. So, remote business interface(s) proxy global jndi name it is.

[wolfc]

I consider http://wiki.jboss.org/auth/wiki/DevJNDIBinding to be authoritative on resulting JNDI names. The policy is just another means to get these results. If we want to change or expand these, that should be done first.

The only thing that differs from Glassfish is how we handle a bean with 1 home interface. That's why we have the (unsupported) option to disable JBMETA-11 checking.

In future I want to go to a mapped name which can contain expressions:

@Stateless(mappedName="java:global/env/$s:optional(${appName}/)${moduleName}/${beanName}#${interface}")

Which we should be able to realize with another policy implementation and then it should be EJB 3.1 compliant.

[alrubinger]

For now I've deprecated the "determine" logic from the Object Model (see JBMETA-68) but EJB2.x still relies on these methods. So the new EjbMetadataJndiPolicyDecoratorDeployer will decorate EJB3 deployments only with a JNDI Binding Policy. So adding new JNDI Policies later should be a natural progression towards providing an EL-based implementation.

The hitch here is that jboss-metadata tests are not for EJB2, and these are not backwards-compatible (because they're not wrapped ie. getJndiName uses the old logic). So MappedReferenceMetadataResolverDeployer must still reference the @Deprecated methods I'd like to remove.

S,
ALR