-
2. Re: Kill Default Remote Binding if 1+ @RemoteBinding is spec
"ALRubinger" wrote:
Given:@Stateless(name="MyBean") @Remote(MyRemote.class) @RemoteBinding(jndiBinding="MyBean") class MyBean{...}
Right now this would produce:/MyBean - Explicit from @RemoteBinding /MyBean/remote - Default Remote Business Interface Proxy Binding
From what i had seen this far, if @RemoteBinding was specified, the the default binding would not be done. Let me give this a try again and see if i am mistaken. -
3. Re: Kill Default Remote Binding if 1+ @RemoteBinding is spec
"jaikiran" wrote:
From what i had seen this far, if @RemoteBinding was specified, the the default binding would not be done. Let me give this a try again and see if i am mistaken.
For this bean:@Stateless @Remote (UserManagerRemote.class) @RemoteBinding (jndiBinding = "RemoteUserManagerBean") public class UserManagerBean implements UserManagerLocal, UserManagerRemote {
deployed in ZEJB3Persistence.ear, this is what i see in JNDIView+- ZEJB3Persistence (class: org.jnp.interfaces.NamingContext) | +- UserManagerBean (class: org.jnp.interfaces.NamingContext) | | +- local-org.myapp.ejb.UserManagerLocal (class: Proxy for: org.myapp.ejb.UserManagerLocal) | | +- remote-org.myapp.ejb.UserManagerRemote (class: Proxy for: org.myapp.ejb.UserManagerRemote) +- RemoteUserManagerBean (class: Proxy for: org.myapp.ejb.UserManagerRemote)
So i don't see that when the @RemoteBinding is specified, the Default binding too is done. I am on JBoss-5 CR2. I haven't tested this on Trunk. -
4. Re: Kill Default Remote Binding if 1+ @RemoteBinding is spec
I now understand how to reproduce this. Your workaround description in that JIRA issue helped me reproduce this issue :-)
So i changed my bean to:@Stateless @Remote (UserManagerRemote.class) @RemoteBinding (jndiBinding = "ZEJB3Persistence/UserManagerBean") public class UserManagerBean implements UserManagerLocal, UserManagerRemote {
The ZEJB3Persistence is the name of my EAR file in which this bean is deployed.
And it fails during deploy time with CCE (on CR2 and trunk) as you mentioned. But from what i see, it fails while binding the business interface specific proxies at ZEJB3Persistence/UserManagerBean/remote-org.myapp.ejb.UserManagerRemote and not the default business proxy. -
5. Re: Kill Default Remote Binding if 1+ @RemoteBinding is spec
What happens if:
@Stateless(name="MyBean") @Local(MyLocal.class) @Remote(MyRemote.class) @RemoteBinding(jndiBinding="MyBean") class MyBean{...} -
6. Re: Kill Default Remote Binding if 1+ @RemoteBinding is spec
"jaikiran" wrote:
So i don't see that when the @RemoteBinding is specified, the Default binding too is done. I am on JBoss-5 CR2
That's because in CR2 the rule was incorrect:
* Take JBossSessionBeanMetaData.getRemoteBindings()[]0] (First entry)
* If there, replace the default remote business binding
This didn't account for N bindings.
S,
ALR -
7. Re: Kill Default Remote Binding if 1+ @RemoteBinding is spec
"wolfc" wrote:
What happens if:@Stateless(name="MyBean") @Local(MyLocal.class) @Remote(MyRemote.class) @RemoteBinding(jndiBinding="MyBean") class MyBean{...}
I thought of something similar to this after going to bed last night.
We need to reserve the namespace used by default bindings. Your example above shows a collision:MyBean - Explicit from MyBean MyBean/local - Default Local Business
...but also there's the stuff under the namespace:MyBean/remote-MyRemote.class
So the rule's gotta be twofold:
* If at least 1 @RemoteBinding is specified, skip binding of default remote business location
* @LocalBinding and @RemoteBinding must not interfere with the namespace
This is all dependent upon the binding namespace; I'm assuming a JAR packaging above. In an EAR this all becomes prefixed w/ "[earName/".
Keep in mind that the idea of a "namespace" is provided by our implementation details ie. BasicJndiBindingPolicy, and other JNDI Binding Policies may not have this restriction. So we cannot validate against the namespace itself as a validation check; we'd have to validate all of the targeted JNDI bindings against each other to check for conflicts. Skipping the validation check just throws a CCE from Context.bind, which doesn't tell the user too much.
S,
ALR