websphere 中如何设置搜索bean的路径

将web应用程序设成按类名处理小服务程序
设置web应用程序的类路径为path/bean.jar就可以了 

解决方案 »

  1.   

    There are two different types of classpath for WebSphere, the Static Classpath and the Dynamic Classpath. The Static Classpath is specified as a commandline argument with the -classpath option for the Application Server Java Process and it is static in the sense that no new jars or directories can be added to this classpath once the Application Server is running. The classes in this classpath are loaded using the JVM primordial ClassLoader and hence this is also referred to as the System Classpath. The Dynamic Classpath is dynamic in the sense that new jar files or directories containing EJB or Servlet classes can be added to this classpath while the Application Server Java Process is running. The classes in this classpath are loaded by using a heirarchy of ClassLoaders which are defined within the Application Server Java Process. Static ClasspathThe static classpath for an Application Server Java Process is constructed in the following manner. 
    1. The first element in the static classpath is the classpath which is specified in the commandline arguments of the Application Server via the -classpath option. Alternatively, this classpath can be set from the Application Server property panel to the environment of the Application Server with the variable CLASSPATH. 
    2. The second element in the static classpath is formed by taking the list of JDBC drivers installed on the node and adding the jar files containing these drivers to the static classpath.
    3. The third element is formed by the classpath of the Adminserver process.  The Adminserver in turn, obtains its classpath in either of the two following ways. From the environment variable CLASSPATH (Note: that the CLASSPATH environment variable is set inside the script adminserver.[bat|sh], if it is started via the adminserver.[bat|sh] file or from the property com.ibm.ejs.sm.adminserver.classpath in the admin.config file, if it is started using the startupServer.sh script (Unix) or from the NT Services panel (NT). There is option to override this behavior, this can be achieved by setting the property com.ibm.ejs.sm.adminServer.managedServerClassPath in the admin.config file. This will force the Application Server Java Process to use the value of the aforementioned property instead of the classpath of the Adminserver. This classpath can be observed by enabling trace for the class “com.ibm.ejs.sm.active.ActiveEJBServerProcess=all=enabled” for the Adminserver or the Node. Dynamic Classpath
     
     The dynamic classpath for an Application server is accessed by a heirarchy of ClassLoaders within the Application Server Java Process. These ClassLoader objects are also responsible for creating and maintaining their respective portions of the Dynamic Classpath. The ClassLoaders are organized as follows:
    1. At the top of this hierarchy of ClassLoaders resides the EJBJarManager. This is a singleton i.e there is only one instance of this class in the Application Server Java Process. The EJBJarManager is responsible for maintaining the portion of the Dynamic Classpath which  contains the jars and directories necessary for all the EJBs deployed in the Application Server Java Process to which it belongs. These jars and directories are added during the process of deploying a EJB Jar into WebSphere. Users are allowed to specify directories and Jar files, which can contain dependant classes for EJBs via the Dependent Classpath property in the property panel of the Node. The Dependent Classpath is thus a part of the Dynamic Classpath and always precedes all the Jars and directories added during the process of deployment. The EJBJarManager singleton contains a  JarClassLoader which loads all the classes for all EJBs inside the concerned Application Server Java Process. This ClassLoader allows you to deploy EJBs to a running Application Server Java Process. This classloader can be debugged by enabling trace for the component: “com.ibm.ejs.util.jar.*=all=enabled” for the Application Server.2. Below the JarClassLoader in this heirarchy comes the PowerClassLoader. There is one instance of a PowerClassLoader in every Web Application. The PowerClassLoader is responsible for maintaining the portion of the Dynamic Classpath which contains all the jars and directories which are specified in the classpath of the Web Application. This ClassLoader is also reloadable in the sense that that when it detects any changes in the directories or Jars specified in the Web Application classpath, it quiesces all the instances of the classes loaded from this classpath and reloads all the classes with a new instance of the classloader. The automatic reloading property can be set to false from the advanced tab of a Web Application, for improved performance.  This classloader also detects an jar files in the directories specified in the Web Application classpath and automatically loads them. So it is not necessary to specify a jar file explicitly in the Web Application classpath. Instead, the jar file can be placed in any of the directroies e.g the <Web Application Document Root>/servlets (this directory is automatically placed into the Web Application classpath) and it shall be picked up automatically by the PowerClassLoader. This ClassLoader can be debugged by enabling trace for the component: “com.ibm.servlet.classloader.*=all=enabled” for the Application Server.The search order for loading a class
     
     The Application Server Java Process searches the aforementioned classpaths in the following order from top to bottom.
    &#376; Static Classpath
    &#376; Application Server commandline classpath or environment CLASSPATH
    &#376; Adminserver classpath (admin.config or adminserver.bat)
    &#376; Dynamic Classpath for the EJBJarManager
    &#376; Node Dependent classpath
    &#376; List of all the EJB Jars which have been deployed in the App Server
    &#376; Dynamic Classpath for the PowerClassLoader
    &#376; Web Application classpath.