WAS v8.5 > Develop applications > Develop Startup beans

Use startup beans

There are two types of startup beans: application startup beans and Module startup beans.

Deprecated feature: The capabilities provided with startup singleton session beans (EJB 3.1 specification) causes the WAS proprietary startup beans function to be deprecated.

A module startup bean is a session bean that is loaded when an EJB Jar file starts. Module startup beans enable Java Platform Enterprise Edition (Java EE) applications to run business logic automatically, whenever an EJB module starts or stops normally. An application startup bean is a session bean that is loaded when an application starts. Application startup beans enable Java EE applications to run business logic automatically, whenever an application starts or stops normally.

Startup beans are especially useful when used with asynchronous bean features. For example, a startup bean might create an alarm object that uses the JMS to periodically publish heartbeat messages on a well-known topic. This enables clients or other server applications to determine whether the application is available. Refer to the Enabling an application to wait for a messaging engine to start article if you are using the default JMS provider.

  1. For Application startup beans, use the home interface, com.ibm.websphere.startupservice.AppStartUpHome, to designate a bean as an Application startup bean. For Module startup beans, use the home interface, com.ibm.websphere.startupservice.ModStartUpHome, to designate a bean as a Module startup bean.

  2. For Application startup beans, use the remote interface, com.ibm.websphere.startupservice.AppStartUp, to define start() and stop() methods on the bean. For Module startup beans, use the remote interface, com.ibm.websphere.startupservice.ModStartUp, to define start() and stop() methods on the bean.

    The startup bean start() method is called when the module or application starts and contains business logic to be run at module or application start time.

    The start() method returns a boolean value. True indicates the business logic within the start() method ran successfully. Conversely, False indicates the business logic within the start() method failed to run completely. A return value of False also indicates to the Application server that application startup is aborted.

    The startup bean stop() methods are called when the module or application stops and contains business logic to be run at module or application stop time. Any exception thrown by a stop() method is logged only. No other action is taken.

    The start() and stop() methods must never use the TX_MANDATORY transaction attribute. A global transaction does not exist on the thread when the start() or stop() methods are invoked. Any other TX_* attribute can be used. If TX_MANDATORY is used, an exception is logged, and the application start is aborted.

    The start() and stop() methods on the remote interface use Run-As mode. Run-As mode specifies the credential information to be used by the security service to determine the permissions that a principal has on various resources. If security is on, the Run-As mode needs to be defined on all of the methods called. The identity of the bean without this setting is undefined.

    There are no restrictions on what code the start() and stop() methods can run, since the full Application Server programming model is available to these methods.

  3. Use an optional environment property integer, wasStartupPriority, to specify the start order of multiple startup beans in the same JAR file. If the environment property is found and is the wrong type, application startup is aborted. If no priority value is specified, a default priority of 0 is used. It is recommended specified the priority property. Beans that have specified a priority are sorted using this property. Beans with numerically lower priorities are run first. Beans that have the same priority are run in an undefined order. All priorities must be positive integers. Beans are stopped in the opposite order to their start priority. The priority values for module startup beans and application startup beans are mutually exclusive. All modules will be started prior to the application being declared as "started" and therefore the start() methods for module startup beans within an application will be invoked prior to the start() methods for any application startup beans. Likewise, all application startup bean stop() methods for a specific JAR file will be invoked prior to any module startup bean stop() methods for that JAR.

    The wasStartupPriority environment property integer cannot be set through either a command or the dmgr console. This environment property integer is an EJB environment entry that is to be set by an application developer not an administrator. You set the integer value in the ejb-jar.xml file as shown in the example below:

      <env-entry> <env-entry-name>wasStartupPriority</env-entry-name> <env-entry-type>java.lang.Integer</env-entry-type> <env-entry-value>3</env-entry-value> </env-entry>
    As with any other EJB environment entry, you set a separate wasStartupPriority value for each EJB.

  4. For module startup beans, the order in which EJB modules are started can be adjusted via the "Starting weight" value associated with each module
  5. To control who can invoke startup bean methods via WebSphere Security do the following:

    1. Define the method permissions for the Start() and Stop() methods as you would for any EJB module. (See "Defining method permissions for EJB modules".)
    2. Ensure the user that is mapped to the Security Role defined for the startup bean methods is the same user defined as the Server user ID within the User Registry.

View the startup beans service settings.


Subtopics


Related concepts:

Applications with a dependency on messaging engine availability


Related


Use asynchronous beans


+

Search Tips   |   Advanced Search