| = App Clients and JNDI |
| :index-group: Unrevised |
| :jbake-date: 2018-12-05 |
| :jbake-type: page |
| :jbake-status: published |
| |
| There are some slight differences between the way OpenEJB |
| does app clients and the way Geronimo does app clients |
| |
| Neither uses the names created via the openejb.jndiname.format. So |
| changing that will (should) have no affect. The idea is that users |
| should be able to set it to be whatever they want it to be and that |
| should not break the App Client code. The openejb.jndiname.format is |
| specifically for "plain" clients and allows them to get the names as |
| they want them. |
| |
| Internally, we bind each EJB proxy under essentially a hardcoded and |
| predictable format and then again using the user supplied format. So |
| there are at minimum two JNDI trees with every EJB proxy. It used to be |
| two at least. Now we have quite a few because of Java EE 6 global JNDI |
| and the support we added for `@LocalClient` and allowing the same |
| interface to be used as both `@Local` and `@Remote`. |
| |
| Basically we have: |
| |
| * openejb/Deployment/<hardcoded internal format> |
| * openejb/local/<strategy format> |
| * openejb/remote/<strategy format> |
| |
| The 'openejb/Deployment' section is the non-changing fully qualified |
| name for use internally and by app clients. |
| |
| The 'openejb/remote' section is for "pretty" names looked up via plain |
| clients using the RemoteInitialContextFactory. The protocol can tell |
| the difference between app clients and plain clients and knows which |
| area to look in. |
| |
| The 'openejb/local' section is for "pretty" names looked up via the |
| LocalInitialContextFactory. |
| |
| The "pretty" names are defined by the openejb.jndiname.format and since |
| the user has control of that formatting it's possible that not all |
| proxies can be bound. Say the bean has both a local and remote |
| interface and the user has just "\{deploymentId}" or "\{ejbName}" as the |
| format. Hence those bind calls use the "optional" set of binding |
| methods. |
| |
| The format of the internal names bound into openejb/Deployment is |
| guaranteed to be unique. It's not pretty to look at obviously, but |
| every possible proxy will be bound there guaranteed. For binding into |
| 'openejb/Deployment' we don't use the "optional" set of binding methods. |
| If something can't be bound it's a deployment issue. |
| |
| The home interface is bound, but with the name of the corresponding |
| business interface rather than the home interface. |
| |
| To be a little bit more clear - Both OpenEJB and Geronimo build their |
| own JNDI trees for the App Client. Geronimo prefers to have its own |
| JNDI tree for the App Client as there are other things in it that are |
| not EJB related. Either way the OpenEJB EJBd protocol can carry the |
| "id" of the App Client and both Geronimo and OpenEJB rely on that. |
| |
| In Geronimo App Clients the id is set to "Deployments" and that tells |
| OpenEJB not to look in the "openejb/remote" section of JNDI as it |
| normally would. It will instead use the "openejb/Deployments" section |
| of JNDI were the names follow a predictable and unchanging format. |
| |
| In OpenEJB App Clients the id is set to the name of the App Client and |
| we instead look in "openejb/client//" where names are formatted by the |
| user via the application-client.xml. |
| |
| When calls are made from client to server and the App Client module id |
| is not present, we look in openejb/remote/ where names are formatted |
| using the openejb.jndi.format |