Linked Java Object builder inputsAdded by IBM on June 28, 2011 | Version 1 (Original)
|This topic describes the inputs for the Linked Java Object builder.
This topic describes the inputs for the Linked Java Object builder.
- General input
Table 1. General input
|Name||Enter a name for this builder call. The WebSphere® Portlet Factory Designer displays this name in the builder call list.|
|Class Name||Enter the fully-qualified name for the class to use for your LJO. For example,
If there is no package (the class is either in IBM® WebSphere Portlet Factory WEB-INF/classes or work/classes directory), enter the class name.
Table 2. Overwriting input
|Rename Existing||This input is useful to change the behavior of code that was placed in the WebApp by a high-level builder or by an imported model. |
When set, this input causes the builder to replace an existing WebApp object with a new object. The builder locates the existing WebApp object (variable, LJO, and so on), renames it, and creates a replacement object.Note: This input is available on the following low-level builders that create WebApp objects: Action List, Imported Page, Linked Java Object, Linked Model, Method, Method Call, Page, Variable, and Schema.
Table 3. Advanced inputs
|Instantiation Method||Select a method that calls a constructor in your Java class and passes any necessary arguments. Use a no argument method in your web application that returns an instance of the LJO class after constructing it. |
|State and Failover||Select the failover behavior for the LJO. You can choose from the following values: |
This setting prompts the model to save the current value for the variable in the case of a failover event. This failover functionality does incur a small performance hit, so only use the default setting when necessary.Read-Write but not persisted for failover
This setting allows your variable value to change, but its value at the time of failover is not preserved.Read-only: shared across all users
This setting makes your variable behave like a constant. Its value never changes from the initial setting. As a result, some performance gains are realized because a copy of the variable is not made during generation and the variable is not processed during the failover event.Request Scope
This setting stores the variable value in a request attribute rather than in a class (WebAppInstanceData). Doing this can improve performance for large variables that are set and read within a single request, and not needed across multiple requests.
Note: Do not use Request Scope for items such as XML variables that are used in multiple requests. Doing so would clone and initialize the request copy of that variable for every use. Use Request Scope for infrequently used variables and variables that hold large objects or hierarchies of objects (such as XML). A typical use of Request Scope might be for a variable that contains data for a table that is displayed on only page of a multiple page application.
|Model Method Base ||Select whether you want the class generated for the model Method builder calls to extend the class specified for this LJO. Select either of these values: |
Use this Linked Java Object's class as a base for all methods in model
Don't extend model methods from this Linked Java Object class
Select this value to define the generated class for the model method as extending the class specified for this LJO. Doing so provides the following benefits:
- Methods in the LJO get displayed as top-level methods in the reference chooser.
- Calling methods in the LJO from other methods is simpler. For example,
- instead of:
Select this value if it does not make sense to extend the LJO class for the model methods. For example, if the LJO contains many member variables.
|Target Phase||Select the generation phase in which to execute the LJO as one of the following options. This useful only if existing elements are being modified. The LinkedJavaObject class uses this for the getTargetPhase method. |
Parent topic: Linked Java Object builder