@Override public boolean hasJndiName() { String name = getJndiName(); return ( (name != null) && !name.equals("") ); }
public boolean hasJndiName() { String name = getJndiName(); return ( (name != null) && !name.equals("") ); }
private String getRemoteEjbJndiName(EjbReferenceDescriptor refDesc) { String intf = refDesc.isEJB30ClientView() ? refDesc.getEjbInterface() : refDesc.getHomeClassName(); return getRemoteEjbJndiName(refDesc.isEJB30ClientView(), intf, refDesc.getJndiName()); }
&& ejbRef.getJndiName().startsWith("java:app/") && !ejbRef.getJndiName().startsWith("java:app/env/")) { String remoteJndiName = ejbRef.getJndiName();
resolved = true; } else if( ejbRefDesc.hasJndiName() && ejbRefDesc.getJndiName().startsWith("java:app/") && !ejbRefDesc.getJndiName().startsWith("java:app/env/")) { String remoteJndiName = ejbRefDesc.getJndiName();
/** * Actual jndi-name under which Remote ejb factory lives depends on * whether it's a Remote Home view or Remote Business view. This is * necessary since a single session bean can expose both views and * the resulting factory objects are different. These semantics are * not exposed to the developer-view to keep things simpler. The * developer can simply deal with a single physical jndi-name. If the * target bean exposes both a Remote Home view and a Remote Business * view, the developer can still use the single physical jndi-name * to resolve remote ejb-refs, and we will handle the distinction * internally. Of course, this is based on the assumption that the * internal name is generated in a way that will not clash with a * separate top-level physical jndi-name chosen by the developer. * * Note that it's better to delay this final jndi name translation as * much as possible and do it right before the NamingManager lookup, * as opposed to changing the jndi-name within the descriptor objects * themselves. This way, the extra indirection will not be exposed * if the descriptors are written out and they won't complicate any * jndi-name equality logic. * */ public static String getRemoteEjbJndiName(EjbReferenceDescriptor refDesc) { String intf = refDesc.isEJB30ClientView() ? refDesc.getEjbInterface() : refDesc.getHomeClassName(); return getRemoteEjbJndiName(refDesc.isEJB30ClientView(), intf, refDesc.getJndiName()); }
ejbRefDesc.getJndiName().startsWith("java:app/") && !ejbRefDesc.getJndiName().startsWith("java:app/env/")) { String remoteJndiName = ejbRefDesc.getJndiName();
/** * Actual jndi-name under which Remote ejb factory lives depends on * whether it's a Remote Home view or Remote Business view. This is * necessary since a single session bean can expose both views and * the resulting factory objects are different. These semantics are * not exposed to the developer-view to keep things simpler. The * developer can simply deal with a single physical jndi-name. If the * target bean exposes both a Remote Home view and a Remote Business * view, the developer can still use the single physical jndi-name * to resolve remote ejb-refs, and we will handle the distinction * internally. Of course, this is based on the assumption that the * internal name is generated in a way that will not clash with a * separate top-level physical jndi-name chosen by the developer. * * Note that it's better to delay this final jndi name translation as * much as possible and do it right before the NamingManager lookup, * as opposed to changing the jndi-name within the descriptor objects * themselves. This way, the extra indirection will not be exposed * if the descriptors are written out and they won't complicate any * jndi-name equality logic. * */ public static String getRemoteEjbJndiName(EjbReferenceDescriptor refDesc) { String intf = refDesc.isEJB30ClientView() ? refDesc.getEjbInterface() : refDesc.getHomeClassName(); return getRemoteEjbJndiName(refDesc.isEJB30ClientView(), intf, refDesc.getJndiName()); }