I have been following with interest recent questions about how Orion's JNDI works in regard to the following scenarios: (1) one instance of Orion hosting web components, and another instance hosting ejb components (2) a client application accessing ejb components on an Orion server An analysis with a simple Hello example that also lists the various JNDI contexts under different configurations has been revealing. Under Orion 1.4.7, I was successful in running both scenarios. With the release of Orion 1.4.8 yesterday, I have rerun the tests. Inspecting the context listings, things make much more sense in 1.4.8 than 1.4.7, although the functional behavior is nearly identical. (Orion 1.4.7 allows a web application to access ejb's in different named application; Orion 1.4.8 does not, at least with the configurations I have tried. Neither application is the parent (orion specific) of the other.) Although the discussion below is somewhat lengthy, I hope it will help others who are looking into these questions. (The zip files are not attached to this post. If this is of interest, I will see about providing them to orionsupport.) -------------------------------------------- The tests involve a web component, an ejb component, and a client application. The ejb is a session bean that issues a greeting (Hello). The greeting is set as an environment entry in the ejb-jar.xml. This component is deployed under several applications and the greeting is used to distinguish which ejb is accessed in the different tests. Another method returns a list the context names relative to a given "root" name. This method delegates to a helper class, ContextProbe, that recursively lists the names in the context. ContextProbe is also called from the web component. The web component consists of a hello.jsp that uses a "title" environment entry to further distinguish the tests. Finally, there are two request parameters accepted by the jsp: ejbName - to dynamically try different ejb names (e.g. ejb/Hello, java:comp/env/ejb/Hello) to lookup in the context; and target: to specify the target of the greeting. To run the tests, I set up 3 separate instances of the orion server and one client. Four corresponding zip file contain the configuration files, web and ejb components, and the orion deployment files. Unzipping one of the server#.zip files in a fresh install of orion (plus the tools.jar file) gives a ready-to-run instance of orion, or client. Server 1: runs web and ejb components to test behavior within the same instance of orion - web site on port 8801 - rmi server on port 23801 - deploy ejb component under the default app as ejb/Hello - deploy ejb twice under hello app 1 as ejb/Hi and ejb/BonJour - deploy ejb under hello app 2 as ejb/Howdy - deploy web component under default app as /hello0-web - deploy web component under hello app 1 as /hello1-web - deploy web component under hello app 2 as /hello2-web From the url localhost:8801/hello1-web/?ejbName=name_to_lookup, the following results are observed: ejb/Hello - works, by virtue of parent application concept in orion ejb/Hi - works since in the same app ejb/BonJour - works since in the same app ejb/Howdy - fails, not in this app java:comp/env/ejb/Hello - fails, since no ejb-ref defined in web.xml java:comp/env/ejb/Hi - fails, since no ejb-ref defined in web.xml java:comp/env/ejb/BonJour - works with ejb-ref defined in web.xml java:comp/env/ejb/Howdy - fails, not in this app, not mapped in web.xml java:comp/env/ejb/xxx - works, ejb-link defined in web.xml java:comp/env/ejb/yyy- works, ejb-ref location="..." defined in orion-web.xml (location specified in orion-web.xml takes precedence over ejb-link in web.xml) This behavior seems correct. The resulting web pages include the contexts listings from both the web component and the ejb component. The context listings under orion 1.4.8 make much more sense than under 1.4.7. Yet there is one puzzling inconsistency (not that I understand the other parts of the context). Under 1.4.8 the subcontext java:comp starting with "" is disjoint with the context listed starting with "java:comp". From the url localhost:8801/hello0-web/ under the default context, the subcontext java:comp contains: Name: Administrator ClassName: com.evermind.server.administration.ApplicationAdministrator Name: ResourceFinder ClassName: com.evermind.server.administration.ResourceFinder Name: ServerAdministrator ClassName: com.evermind.server.administration.ApplicationServerAdministrator Name: ApplicationClientConnector ClassName: com.evermind.server.administration.ApplicationClientConnector while starting at java:comp Name: UserTransaction ClassName: com.evermind._du Name: RoleManager ClassName: com.evermind._hg Name: Logger ClassName: com.evermind._kwb Name: UserManager ClassName: com.evermind.server.XMLUserManager Name: env ClassName: com.evermind._hi Name: ThreadPool ClassName: com.evermind._hf Bug or feature? Server 2: runs web components to test orion-web to orion-ejb in separate instances using orion-specific features to perform remote ejb access - web site on port 8802 - rmi server on port 23802 - deploy web component under hello app 1 as /hello1-web - deploy web component under hello app 3 as /hello3-web (1) add to rmi.xml <server host="localhost" port="23801" username="admin" password="123" /> (Be sure the admin user is activated on Server 1) (2) create a jar file with the ejb interface classes and the ContextProbe helper class; then either (a) place this jar file under orion/lib, or (b) place this file under hello-app1/WEB-INF/lib and insert into the config/application.xml file the following line to point to the jar file: <ejb-module remote="true" path="../applications/hello-app1/hello-web/WEB-INF/lib/example.jar" /> (I started with the mini how-to that Jason Smith roughed out on April 3, 2001: http://www.mail-archive.com/orion-interest@orionserver.com/msg11905.html) From the url localhost:8802/hello1-web/?ejbName=name_to_lookup (Note the port for server 2), the results are almost identical to those run from server 1. The difference is that for those names looked up from java:comp/env/ejb/.... In these cases, the ejb-link in the web.xml file seems to have no effect. When the web app is deployed by orion, an exception is generated the first time saying "No location found". The corresponding orion-web.xml must be edited to add the location="..." attribute to the ejb-ref. I tried putting the <ejb-module remote="true" ... /> in the orion-application.xml file for hello app 1. This did not have the desired effect. The orion class loader seems to be looking in orion/lib (among other locations). When the path is specified in orion/config/application.xml as in (2) above, it is added to the path searched by the class loader. Bug or feature? Adding an ejb module under hello app 1 on server 2 as ejb/Hola shows that localhost:8802/hello1-web/?ejbName=ejb/Hola resolves as a local ejb, while localhost:8802/hello1-web/?ejbName=ejb/BonJour resolves as a remote ejb Interestingly, with no changes to server 1, localhost:8801/hello1-web/?ejbName=ejb/Hola resolves to the ejb on server 2! Bug or feature? Hello app 3 does not have any local or remote ejb's, so of course it cannot work. There is no corresponding app on Server 1. Null Pointer exception are generated on server 1 apparently when trying to access the RMI Context for hello app 3. Deploying an ejb component under hello app 3 also generates a Null Pointer Exception on Server 1. Removing the ejb reference from the jsp and removing and context probing that falls under the RMI context (ejb, jdbc, jms, mail, url), the web app works. So, there can be applications on server 2 that do not have a corresponding element on server 1. Removing the dependency on an ejb and the initial context, If an app on the web server uses any ejb components, then there must be a corresponding app on server 1. Server 3: runs web components to test orion-web to orion-ejb in separate instances using lookup via initial context based on jndi properties - web site on port 8803 - rmi server on port 23803) - deploy web component under hello app 1 as /hello1-web - deploy web component under hello app 2 as /hello2-web (1) rmi.xml file has no additions (same as server 1, except for port #) (2) same choices as for server 2 above The hello.jsp is modified to get the InitialContext based on setting jndi properties, with the PROVIDER_URL set to "ormi://localhost:23801/hello-app1" and the INITIAL_CONTEXT_FACTORY as "com.evermind.server.rmi.RMIInitialContextFactory". Note that a second InitialContext is required to retrieve the environment entry for the title. The location for the ejb-ref is again required in the orion-web.xml file and any ejb-link in the web.xml is ignored. The ejb/Hola in hello app 1 on server 2 is also available. For the first time in any of the tests, the method call to PortableRemoteObject.narrow(...) is required for the application to work properly. Previous tests work presumably because orion-orion uses "insider knowledge". To comply with the J2EE spec, this method call should be used in every case... Under orion 1.4.7, it was possible to set the provider url to another application. Under 1.4.8, orion is enforcing the requirement that only components in the same application can communicate (except for orion's concept of one application being parent to other apps). Client: The client consists of a single Java class: HelloClient. The client takes one argument, the name of the ejb to lookup. In this case, there is a jndi.properties file to specify the PROVIDER_URL and the INITIAL_CONTEXT_FACTORY. An application-client.xml gives the ejb-ref and a corresponding orion-application-client.xml maps the reference to a jndi location in analogy to the web.xml and orion-web.xml files discussed above. To run the client, the classpath must include orion.jar, ejb.jar from an orion directory, and the example.jar file in the client directory, e.g. java -cp .;./example.jar;../server1/orion.jar;../server1/ejb.jar HelloClient When using com.evermind.server.ApplicationClientInitialContextFactory, the test results parallel those under Server 2. When using com.evermind.server.rmi.RMIInitialContextFactory, however, the client must know the exact name of the ejb on the remote server to work. I would doubt that the application-client.xml or orion-application-client.xml files are read in this case. Bug or feature? Earl Marwil SCIENTECH, Inc. 1690 International Way Idaho Falls, ID 83402 208.525.3717
