|
Page Edited :
OPENEJB :
JNDI Names
JNDI Names has been edited by Karan Singh Malhi (Aug 16, 2007). Content:What's My Bean's JNDI Name?The short answer is:
And typically, deploymentId will be your bean's ejb-name unless you've explicitly set it to something else via an openejb-jar.xml or set the openejb.deploymentId.format to something else. So if you have a bean like such: <session> <ejb-name>Calculator</ejb-name> <home>org.acme.CalculatorRemoteHome</home> <remote>org.acme.CalculatorRemote</remote> <local-home>org.acme.CalculatorLocalHome</local-home> <local>org.acme.CalculatorLocal</local> <ejb-class>org.acme.CalculatorImpl</ejb-class> <business-local>org.acme.CalculatorBusinessLocal</business-local> <business-local>org.acme.CalculatorBusinessLocalTwo</business-local> <business-remote>org.acme.CalculatorBusinessRemote</business-remote> <business-remote>org.acme.CalculatorBusinessRemoteTwo</business-remote> </session> The following names will be bound into JNDI and accessible via the LocalInitialContextFactory
This is the same list minus any interfaces of a local nature as they aren't accessible over a network. Changing the JNDI name formatThe JNDI name format can actually be changed. At current date this can be done on a server-wide basis, but in the future it will be changeable on an application and individual bean basis. To set it for the server, there is a system property called openejb.jndiname.format which understands the following variables:
More variables will be added in the future, such as prettier varieties of ejbType and interfaceType. If there are any you'd like added, feel free to write the dev list. With this you can create a layout for the ejbs in global jndi namespace how ever you like. A couple examples could be:
You are responsible for ensuring the names don't conflict. I.e. if you used something as simple as just "{interfaceClass.simpleName}" for your format it would only work as long as you didn't reuse the interface for any other beans in your app or any other app deployed in the server. If you used "{ejbName}{interfaceClass.simpleName}" you could reuse the interface in other beans but you'd have to guarantee that the ejbName is not already used by another bean in a different app. The default of "{deploymentId}/{interfaceClass.simpleName}" is a pretty safe bet as deploymentId is guaranteed to be globally unique across all apps and beans, however the use of simpleName could cause conflicts if the bean had two interfaces like org.package1.Foo and org.package2.Foo. The safest bet, though not the default as we wanted something short, is to use the fully qualified name of the interface "{deploymentId}/{interfaceClass}". JNDI Name DefaultsMore on the jndi name issue as it relates to proxies. You may recall our discussions[1][2][3] on what do to about all-in-one proxies and the fact that some spec compliant beans may have business interfaces that conflict[4] and therefore can't be all-in-one proxies requiring us to also support a one-proxy-per-interface approach. This is the part that has changed. *Now* we no longer have two separate approaches (all-in-one-proxy vs single-interface-proxy) we have a sort of hybrid approach. In the new approach we still create one proxy per each business interface, but we *also* include all the other business interfaces implemented by the bean class provided none of them conflict. So a bean with four business interfaces gets 4 proxies, each possibly containing all four business interfaces. Recap: each proxy has all the business interfaces your bean implements (provided no conflicts are found), plus the interface the proxy is dedicated to (regardless if the bean implemented it). We create one such proxy for each business interface you have. So what are these conflicts? Business interfaces extending java.rmi.Remote. If you do not have any business interfaces extending java.rmi.Remote *and* you implemented all your business interfaces in your bean class, you are good to go and do not need to be concerned; all your proxies will be guaranteed to be 'all in one' proxies you can cast it to any of the other business interfaces of the same type (type=local vs remote) that bean implements. What's the deal with java.rmi.Remote? The specific issue with java.rmi.Remote interfaces is that per spec rules many runtime exceptions (container or connection related) are thrown to clients as java.rmi.RemoteException which is not a runtime exception and must be throwable via the proxy. For example it's legal for a bean to implement two conflicting methods such as these: by leaving out exceptions from the throws clause that aren't declared in both interfaces methods. Implementation: void doIt(){} This is fine for a bean class as it isn't going to need to throw RemoteException. However if we create a proxy from these two interfaces it will also wind up with a 'doIt(){}' method that cannot throw RemoteException. This is very bad as the container does need to throw RemoteException per spec rules to any business interfaces extending java.rmi.Remote. If the container attempts to throw a RemoteException from the proxies 'doIt(){}' method, it will result in an UndeclaredThrowableException thrown by the VM. The only way to guarantee the proxy has the 'doIt() throws RemoteException {}' method of InterfaceB is to cut out InterfaceA when we create the proxy dedicated to InterfaceB. When we create the proxy dedicated to InterfaceA, InterfaceB is cut out. The important thing to remember is that if you implement all your business interfaces and do not use java.rmi.Remote, your life is super easy. |
Unsubscribe or edit your notifications preferences
