Chapter 4 Defining Components

Configuring component properties

The Component Properties window configures the settings that EAServer uses to load the component and invoke its methods. Component properties are organized on the following tabs:

Tab	Description
Component properties: General	Defines basic information about the component, including the component type and implementation details such as the Java class name or the C++ library name.
Component properties: Transactions	Defines the components transactional properties, such as how the component participates in transactions and whether the component explicitly commits its work.
Component properties: Instances	Defines how instances of the component are managed, including instance creation, thread binding, and client/component bindings.
Component properties: Environment	For EJB 2.0 or 1.1 components, allows you to specify read-only site specific data for use by the component.
Component properties: EJB Refs	For EJB 2.0 or 1.1 components, allows you to configure aliases for components called by this component.
Component properties: Resource Refs	For EJB 2.0 or 1.1 components, allows you to configure aliases for resources used by the component such as JavaMail sessions or JDBC connections.
Component properties: Resource Environment Refs	For EJB 2.0 components, configures logical names for objects administered by EAServer.
Component properties: Role Refs	For EJB 2.0 or 1.1 components, allows you to map role names used in method permissions to role names defined in the EAServer repository.
Component properties: Resources	Configures properties that govern the component's use of server and database resources.
Component properties: Persistence	Specifies the primary key type for EJB entity Beans, and configures properties used to save state information for stateful components that can fail over between servers in a cluster.
Component properties: Run-As Mode	For EJB 1.0 components, specifies the user name and password that are used for intercomponent calls to components installed in the same server or cluster.
Component properties: MDB Type	Applies to Message-Driven Bean (MDB) components only. See "Message-driven beans" for more information.
Component properties: Mirror Cache	Configures properties required to support in-memory failover for stateful components running in a cluster. See "Mirror Cache tab component properties" for more information.
Component properties: Java Classes	Configures the custom class list for Java and EJB components.
Component properties: Additional Files	Configures the file set to be included when the component is exported in Jaguar JAR format or replicated to another installation using the synchronize feature.
Component properties: JAXP	For EJB 2.0 components, configures the XML parser implementations used by the component.
Component properties: All Properties	Allows you to manually edit component property settings in the EAServer configuration repository. For advanced users.

Component properties: General

The General tab defines basic information about the component, including the supported IDL interfaces, the component type, and implementation details. If you imported a Java or ActiveX component, these properties have already been configured correctly by the import process. The following table describes the window controls.

Table 4-1: General tab component properties
Property	Description	Notes
Description	Specifies description of the component. The description can be up to 255 characters.	Enter a comment that describes the purpose of the component.
Code set (C/C++ components only )	Specifies the name of the coded character set used by a C or C++ component. By default, the component uses the server's coded character set (specified on the General tab in the Server Properties window). This field does not display for Java and ActiveX components. These components always use 16-bit Unicode.	Input values for string parameters (and string fields within complex datatype values) are converted to this code set before each method invocation. Upon return, output values are converted from the component's code set to the client's code set. If your C or C++ component uses Client-Library connection caches, you cannot specify a code set that is different than the server code set. Character data read over a cached Client-Library connection is always in the server's code set.
Component Type	Specifies the type of the component, which can be: EJB - Stateless Session Bean A stateless session bean EJB component. EJB - Stateful Session Bean A stateful session Bean EJB component. EJB - Entity Bean An entity bean EJB component. EJB - Message Driven Bean An EJB component that responds solely to JMS messages and lacks a client interface. Java - CORBA A Java component that uses the Java/IDL datatypes as defined by the CORBA specification for IDL-to-Java type mappings. Java - JDBC A Java component that uses the JDBC column types for parameter and return types. Java components that were developed for EAServer 1.1 require this option. PowerBuilder NVO A PowerBuilder Non-Visual Object adapted to run as an EAServer component. COM/ActiveX An ActiveX component adapted to run as an EAServer component. C++ A C++ class adapted to run as an EAServer component. C A collection of C routines adapted to run as an EAServer component.	EJB components must be implemented in accord with version 1.0, 1.1, or 2.0 of the Enterprise JavaBeans specification. Version 2.0 is recommended for new development. ActiveX components are supported only in the Windows version of EAServer. All other component types can run on any platform that is supported by EAServer.
EJB Version only for EJB components	Choose to to match the EJB specification version number. EAServer's interaction with the component is governed by the specification version.	Version 2.0 is recommended for new development.
CMP Version only for EJB 2.0 enity beans	For EJB 2.0 entity beans that use container-managed persistence (CMP), sets the CMP version number. If you do not specify a value, the default is 1.1.	In EJB 2.0 entity beans, you can use the CMP models from the EJB 2.0 or EJB 1.1 specifications. Version 2.0 is recommended for new development. Version 1.1 allows you to use existing implementation code that requires the EJB 1.1 CMP model.
Bean Class only for EJB components	The name of the class that implements the bean, in Java dot notation.
MDB Class only for EJB MDB components	The name of the class that implements the message-driven bean, in Java dot notation.
JNDI Name only for EJB components	The unqualified name used by client applications to look up the bean's home interface in the naming service. For example: finance/account The fully qualified name is obtained by appending the JNDI name to the server's initial naming context, for example: /finserver/finance/account	If you do not specify a name, the default is package/component, where package is the EAServer package name, and component is the component name.
Home Interface Class only for EJB components	The Java class that defines the bean's home interface, in Java dot notation.	This field is read only. The class name is determined from the IDL home interface. You can add, view, or edit the IDL home interface using the component's interfaces folder.
Remote Interface Class only for EJB components	The Java class that defines the bean's remote interface, in Java dot notation.	This field is read only. The class name is determined from the IDL remote interface. You can add, view, or edit the IDL remote interface using the component's interfaces folder.
Local Home Interface Class only for EJB components	The Java class that defines the bean's local home interface, in Java dot notation. Blank if the bean does not have local interfaces.	This field is read only. The class name is determined from the IDL home interface. You can add, view, or edit the IDL home interface using the component's interfaces folder.
Local Interface Class only for EJB components	The Java class that defines the bean's local interface, in Java dot notation. Blank if the bean does not have local interfaces.	This field is read only. The class name is determined from the IDL remote interface. You can add, view, or edit the IDL remote interface using the component's interfaces folder.
Primary Key Class only for EJB entity Beans	The Java class that defines the entity bean's primary key type, in Java dot notation.	This field is read only. The class name is determined from the IDL struct type that defines the bean's primary key. You can add a primary key type to a module listed in Jaguar Manager IDL folder. Typically the bean's primary key structure, home interface, and remote interface are defined in the same IDL module. To set the bean's IDL primary key type, enter the type name in the Primary Key field on the Persistence tab.
Fully Qualified Java Class only for non-EJB Java components	The fully qualified name of the Java class file that implements the component's methods, specified in Java dot notation, as in: com.yourcorp.YourCompImpl
DLL Name only for C and C++ components	The name of the Windows DLL or UNIX shared library that contains the component methods. You can omit platform standard file extensions if desired (such as .dll on Windows or .so on Solaris).	Before running the component, the library files must be copied to cpplib subdirectory in the EAServer installation directory.
C++ Class (only for C++ components )	The name of the C++ class that implements the component.
C++ Executable (only for C++ components )	The name of an external process in which the C++ component runs.	Run the component externally if you do not completely trust the implemenation not to crash. See "Running C++ components externally" for details.
Use Platform Independent Library Naming (only for C++ components )	If selected, the platform name is included in the component library and executable name, to allow deployment to mixed architecture clusters.	See "Creating C++ components for multiplatform clusters" for details on this feature.
COM Progid (only for ActiveX components )	The progid that the component uses in the COM Automation Server Registry.	Jaguar Manager does not register the ActiveX component DLL. Before running the component, you must register the DLL with the Windows regsvr32 command or by using the registration feature in your ActiveX development tool.
PowerBuilder Class Name only for PowerBuilder components	Matches the name of the non-visual object that implements the component's methods.	Set by PowerBuilder, defined in the EAServer Component Wizard.
PowerBuilder Library List only for PowerBuilder components	A list of the PowerBuilder library files that are required to run the object, separated by semicolons. For example: mylib.pbl;anotherlib.pbl	Set by PowerBuilder, defined in the EAServer Component Wizard.
PowerBuilder Application only for PowerBuilder components	The name of the PowerBuilder application that contains the NVO that implements the component.	Set by PowerBuilder, defined in the EAServer Component Wizard.

Component properties: Transactions

The Transactions tab configures the component's transactional properties. Chapter 2, "Understanding Transactions and Component Lifecycles" provides useful background for the transactional properties.

Transaction attribute values

The transaction attribute determines how methods in your component participate in transactions; at the component level, the setting affects all methods. You can also set a transaction attribute for methods within a component (see "Method properties"). Values set at the method level override the component setting.

Transaction attribute in imported EJB components EJB 2.0 or 1.1 components imported from an EJB JAR file have the transaction attribute set for each method. To use the component level setting, set the transaction attribute to Default to Component for each method.

The transaction attribute can have the following values:

Not Supported (The component-level default) The component's methods never execute as part of a transaction. If the component is activated by another component that is executing within a transaction, the new instance's work is performed outside of the existing transaction.
Supports The component can execute in the context of an EAServer transaction, but a connection is not required in order to execute the component's methods. If the component is instantiated directly by a base client, EAServer does not begin a transaction. If component A is instantiated by component B, and component B is executing within a transaction, component A executes in the same transaction.
Required The component always executes in a transaction. When the component is instantiated directly by a base client, a new transaction begins. If component A is activated by component B, and B is executing within a transaction, then A executes within the same transaction; if B is not executing in a transaction, then A executes in a new transaction.
Requires New Whenever the component is instantiated, a new transaction begins. If component A is activated by component B, and B is executing within a transaction, then A begins a new transaction that is unaffected by the outcome of B's transaction; if B is not executing in a transaction, then A executes in a new transaction.
Mandatory Methods may only be invoked by a client that has an outstanding transaction.
Never The component's methods never execute as part of a transaction, and the component may cannot be called in the context of a transaction. If a client or another component calls the component with an outstanding transaction, EAServer throws an exception.
Bean Managed For EJB session bean components only. The component can explicitly begin, commit, and rollback new, independent transactions by using the javax.transaction.UserTransaction interface. Transactions begun by the component execute independently of the client's transaction. If the component has not begun a transaction, the component's database work is performed independently of any EAServer transaction.

Stateless session Beans can use this attribute, but transactions begun in a method must be committed or rolled back before that method returns. Otherwise, EAServer logs an error and returns an exception to the client. Stateful session Beans can create transactions that remain open across several method calls.
OTS Style For non-EJB components only. The component can inherit a client's transaction. If called without a transaction, the component can explicitly begin, commit, and rollback transactions by using the CORBA CosTransactions::Current interface. See "OTS/XA transaction model" for more information.
Default to component (Method-level default) In the Transactions tab of the Method properties window, choose this option if the method should inherit the transaction attribute set in the component properties.

EAServer allows only one transaction per component instance A component instance may not execute in two transaction contexts. You cannot set a transaction attribute at the method level that conflicts with the component level setting. For example, you cannot set the component transaction attribute to Mandatory and a method transaction attribute to Requires New. If a method invocation would cause this rule to be violated, the server returns an exception to the client and logs the error in the server log file.

Transaction isolation level

Specifies the isolation level for transactions begun by the component's method. This setting can be configured for the component and for individual methods (see "Method properties"). The choices are:

Read Committed
Read Uncommitted
Repeatable Read
Serialized
None

The transaction isolation level is supported for EJB 1.0 components only.

Automatic demarcation/ deactivation

Applies to components that use a control interface in which the instance activation and deactivation correspond to transaction boundaries. In other words, the option does not apply to EJB components or any omponent that uses the control interface CtsComponents::ObjectControl (the control interface property is "Configuring a control interface").

For EJB components and components that use the CtsComponents::ObjectControl control interface, this option is ignored; for these compnents, the Stateless option on the Instances tab determines whether the component is deactivated after every method invocation.

When Automatic demarcation/deactivation is enabled, EAServer deactivates the component instance after every method invocation. Your component need not call the completeWork or rollbackWork transaction primitives when this property is enabled. If your component is transactional, calling rollbackWork or throwing the CORBA TRANSACTION_ROLLEDBACK exception aborts the transaction. Setting any other transaction state commits the transaction.

By default, this option is enabled for new components.

If component is stateful disable Automatic demarcation/deactivation If your component maintains state across method invocations, you must disable the automatic transaction demarcation property. For example, if you read and modify class member fields in response to method invocations, you must disable this option.

Automatic failover

When this option is enabled, client proxies for the component can transparently failover to alternate servers when a server becomes unavailable. This option cannot be enabled unless you have enabled the Automatic demarcation/deactivation option.

Automatic failover requires that your application use a cluster of servers, so that redundant servers are available to run the application's components. The cluster must include at least one name server and clients must resolve proxy references using naming services. See "Load Balancing and Failover" in the EAServer System Administration Guide for more information.

Component properties: Instances

Properties on the Instances tab configure how instances of the component are created and bound to server-side threads and client-side object references. Table 4-2 describes the settings:

Table 4-2: Instances tab component properties
Property	Description
Concurrency	Enabling this option allows multiple method invocations to occur simultaneously. Concurrent access can decrease the response time of client method invocations. Enable this option for any component that is thread safe. If this option is disabled, EAServer serializes all method calls to the component. Concurrency applies to execution of all instances. With concurrency disabled, a call to one instance cannot overlap the execution of another instance. If a PowerBuilder component is Shared, disable Concurrency. PowerBuilder is thread safe at the session level only. Concurrency option disabled If the Sharing and Bind Thread options are selected, the Concurrency option is implicitly disabled.
Bind Object	Applies to stateful components only (Automatic Demarcation/Deactivation must be disabled on the Transactions tab or the component must be a stateful session EJB). When this property is enabled, an instance is bound to a client's proxy reference until the client destroys or releases the reference. If you enable this option, your component must be thread-safe; that is, one instance must be able to execute on multiple threads concurrently. A client may call the proxy from multiple threads, or pass the proxy to another process or component; consequently, there is no guarantee that calls are serialized with Bind Object enabled. Component instances are destroyed when the client instance reference times out (the time out period is configured on the Instances tab-see "Component properties: Instances"). Instances are not pooled. Bind Object is most commonly used for storage components, which are used to store a component's state information in a database. See "Component properties: Persistence" for more information on storage components.
Bind Thread	When this option is enabled, component instances are bound to the creating thread. Enable this option if the component uses thread-local storage. For ActiveX components, this option must be enabled. For other component types, enable the option only if you are sure that your component uses thread-local storage. If the Bind Thread option is selected, multiple instances may still run concurrently on separate threads. To ensure that only one instance is active at a time, make sure that the Concurrency option is not selected. When Bind Thread is enabled, instances are pooled if the Pooling option is enabled. The thread is pooled with the instance in this case.
Pooling	When this option is enabled, component instances are always pooled after deactivation. For Java and ActiveX components, you can also configure pooling by implementing interfaces with a canReuse (Java) or canBePooled (ActiveX) method. If you enable the Pooling option in Jaguar Manager, your component is always pooled, and these methods are not called. See "Supporting instance pooling in your component" for more information on instance pooling.
Sharing	When this option is enabled, a single, shared instance of the component services all client requests. A shared component can store data in instance variables. However, if the component's Concurrency option is also selected, you must add code to synchronize access to instance variables. If a PowerBuilder component is Shared, disable Concurrency. PowerBuilder is thread safe at the session level only. Sharing setting overrides Pooling setting If you select both Sharing and Pooling, Sharing takes precendence.
Stateless	This option applies only to EJB session Beans and non-EJB components that use the control interface CtsComponents::ObjectControl. For EJB session Beans, the Stateless option is set correctly when the component type is set, and must not be changed. For other component types, the option must be set manually.
Transient	Applies to stateful components only. Specifies whether instances can be run on multiple servers in a cluster or survive a server restart. If this option is enabled, the server guarantees that proxy references can only be used within the same server process. For EJB stateful session Beans, this property must be enabled for the standard EJB passivation and activation to occur. It must be disabled if you want to configure a stateful session bean to support failover using the Persistence tab properties (see "Component properties: Persistence").
Reentrant	Applies to entity components only (including EJB entity Beans). When this option is enabled, an instance is allowed to participate in loopback call sequences, which are call sequences where one of the bean's methods calls another component which in turn calls a method in the calling bean instance. Most Beans are not implemented to support reentrancy, and you must not enable this option unless the bean developer has verified that the implementation allows it.

Component properties: Environment

Applies to EJB 2.0 or 1.1 components only. Environment properties allow you to specify read-only site specific data for use by the component. For example, you may have environment properties to specify the name of a logging file, or to tune cache usage, or to specify an email address for the site administrator. See "Configuring environment properties" for more information.

Component properties: EJB Refs

Applies to EJB 2.0 or 1.1 components only. EJB references provide an alias mechanism for the JNDI names used to create proxies for intercomponent calls. The JNDI names used in your compoent must be cataloged on this tab if the component is to run on other servers. When deploying the component, a site administrator can map site-specific EJB JNDI names to the references used by your component. See "Configuring EJB references" for more information.

Component properties: Resource Refs

Applies to EJB 2.0 or 1.1 components only. Resource references are used to obtain database connections and JavaMail sessions. The reference allows you to obtain resource factories using JNDI, rather than hard-coding connection parameters in your application. See "Configuring resource references" for more information.

Component properties: Resource Environment Refs

For EJB 2.0 components, resource environment references are logical names applied to objects administered by EAServer.

Adding or editing a resource environment reference

Open the Component Properties dialog box.
"Resource environment references" describes how to add and edit a resource environment reference.

Component properties: Role Refs

Applies to EJB 2.0 or 1.1 components only. Role references are required if you call the isCallerInRole Java method to restrict access. Each reference maps a string used in isCallerInRole calls to a J2EE role that is configured in the package Role Mappings. See "Configuring role references and method permissions" for more information.

Component properties: Resources

Properties on this tab govern the allocation and deallocation of resources required by the component.

Transaction timeout A component's Transaction Timeout property specifies the maximum duration of an EAServer transaction. See Chapter 2, "Understanding Transactions and Component Lifecycles" for more information on EAServer transactions.

You can set the timeout for components and at the server level, with server property com.sybase.jaguar.server.tx_timeout (set on the All Properties tab in the Server Properties dialog box). EAServer determines the transaction timeout period as follows:
- If the component Transaction Timeout property is set to a non-zero value, this is the timeout period.
- Otherwise, the server transaction timeout property is checked (the server transaction timeout is specified by the com.sybase.jaguar.server.tx_timeout property). If the server transaction timeout is non-zero, this specifies the timeout period.
- Otherwise, the component Instance Timeout value is checked. If this value is non-zero, this specifies the transaction timeout period as well as the instance timeout period.
- Otherwise, the transaction timeout is infinite.
For both the component and server setting, the timeout period is configured in seconds, with 0 indicating infinity (that is, no timeout). The default for a new server is 0. When specifying timeouts, a resolution of 5 seconds is recommended. Network transport time is included in the measured timeout period. You may need to configure a larger timeout period if clients connect over slow networks.

EAServer checks for timeouts after each method returns. Your component will not be deactivated in the middle of an invocation because of a timeout. When a transaction times out, the next method invocation in the client-side ORB throws the CORBA::TRANSACTION_ROLLEDBACK system exception.
Instance timeout Specifies how long, in seconds, an active component instance can remain idle between method calls before the client's proxy becomes invalid. If the timeout expires, the instance is automatically deactivated. Instance Timeout is useful for ensuring timely deactivation of stateful components. ("Stateful versus stateless components" explains this term.) The setting has no effect for stateless components.

When the timeout period is exceeded, EAServer deactivates the component and invalidates the client's object reference. If the client attempts another method invocation, the client-side ORB throws the CORBA::OBJECT_NOT_EXIST exception. At this point, the client must create a new proxy instance for the component.

This property is not set for new components; the component inherits a default value from the server properties. At the server level, configure the instance timeout by displaying the All Properties tab in the Server Properties window. Then set the com.sybase.jaguar.server.timeout property.

The timeout period is configured in seconds, with 0 indicating infinity (that is, no timeout). If the component's Instance Timeout property is not set, the default is inherited from the server properties. The default for a new server is 0. When specifying timeouts, a resolution of 5 seconds is recommended.

Network transport time is not included in the measured timeout period. You may need to configure a larger timeout period if clients connect over slow networks.
Maximum Active Instances Specifies the maximum number of instances that can exist at the same time. For a C++ component that runs as an external process, specifies the maximum number of simultaneously running external processes. If a request arrives when the maximum number of instances exist and are all busy, the request blocks, with blocking time constrained by the Maximum Wait setting.
Maximum Pooled Instances When instance pooling is enabled with the Pooling checkbox on the Instances tab, specifies the maximum pool size. If the maximum pool size is reached, EAServer destroys excess instances after deactivation. The default is 0, which means no maximum pool size is in effect.
Minimum Pooled Instances When pooling is enabled, specifies the minimum pool size. The default is 0.

When setting the Minimum Pooled Instances and Maximum Pooled Instances, consider the following:

Instance pooling can decrease client response time, but can also increase memory usage in the Jaguar server. You can configure the maximum and minimum pool size to constrain the memory used to maintain an instance pool. For example, a heavily used component should have higher minimum and maximum pool sizes than a less commonly used component.

Jaguar server does not preallocate instances for the pool. The pool size grows as additional instances are required to satisfy client requests, up to the maximum specified size (if a maximum size is specified). Once the minimum pool size is reached, the size will not shrink below this size. To release idle pooled instances, Jaguar server has a garbage collector thread that runs periodically. Each time it runs, the garbage collector removes one idle instance from the pool, unless the minimum pool size has been reached.

If you configure a minimum pool size, configure a maximum size that is slightly larger. The difference between the maximum and minimum size provides a damping factor that prevents repeated instance allocation and deallocation if the actual pool size hovers near the minimum size.
Maximum Wait Specifies the maximum wait time for method execution to complete. Enter a value in seconds. The default is 0, which indicates no time limit.

If the method does not complete in time, EAServer returns a CORBA::NO_RESOURCE_EXCEPTION to the caller. Network latency between client and server is not included in the measured method execution time. For C++ components running in an external process, the measured time includes interprocess communication latency.

Component properties: Persistence

The Persistence tab allows you to specify an EJB entity bean's primary key and configure settings that allow EAServer to save component state to a database server.

See Chapter 25, "Managing Persistent Component State" for information on these fields.

Component properties: Run-As Identity

This tab applies to EJB 2.0 components only. These properties specify the authentication credentials that are used when methods call other components. By default, the client credentials are used. You can specify an alternate credential with these settings:

Run as Choose specified to specify an alternate identity. The default, client , means the component calls made from this component inherit the client identity.
Role Specify a role name. The identity specified in the Mapped to Jaguar identity field should be in this role. This name is used if the component is exported to an EJB-JAR file.
Run as identity Specify a logical identity name.
Mapped to Jaguar identity Choose an EAServer identity from the pull down menu. This is the identity with which the component executes.
Description Enter an optional text comment. This field can be used to provide identity mapping instructions for the deployer when the component is deployed to another server.

The Existing Mappings on the Package table displays logical identity names that are mapped to EAServer identities by components in the same package.

To enable use of the run-as identity for EJB component calls to remote servers, you must specify corbaname URLs in the EJB Reference properties for the EJB component that issues the call. For more information, see "Interoperable naming URLs" and "Configuring EJB references".

Component properties: Run-As Mode

This tab applies to EJB 1.0 components only. These properties specify the user name and password that are used when methods call other EAServer components installed in the same server or server cluster. The setting in the Component Properties dialog box is the default for all methods in the component. You can override the component level setting for individual methods (see "Method properties").

The choices for Run As Mode are:

Value	Description
Client	Use the client's user name and password. This is the default setting.
System	Use the system user name and password. The system account effectively belongs to any role, and can execute any method on any component that is installed in the same server or cluster.
Specified	Use the user name and password associated with the identity name specified in the Run-as Identity column.

When Run-As Mode is set to Specified, you must enter a logical entity name, then map the logical identity name to an identity that is defined in the Jaguar Manager identities folder. If there are no identities defined, you must close the Component Properties dialog, go to the Identities folder, and create at least one identity to map logical identities to. For more information, see the Jaguar Manager online help or the EAServer System Administration Guide.

Mappings specified in the Component Properties dialog are stored as package properties and apply to all other components in the package.

Component properties: Java Classes

For CORBA/Java and EJB components, allows you to define the list of classes that must be custom loaded in addition to the component implementation class. Custom loading allows you to refresh the component installation without restarting the server, and to deploy classes in JAR files without changing the server CLASSPATH environment variable and restarting the server. For more information, see Chapter 28, "Configuring Custom Java Class Lists"

In versions earlier than EAServer 4.0, this property was configured by setting the com.sybase.jaguar.component.java.classes property on the All Properties tab.

Component properties: Additional Files

Configures the com.sybase.jaguar.component.files property, which specifies additional files that are included when the component is archived in Jaguar JAR format or replicated with the synchronize feature.

By default, the following files are included when you export packages or synchronize between servers:

The IDL files that define interfaces and types used by the component.
For C or C++ components, the DLL or shared library that is specified on the General tab of the Component Properties window. If your component requires additional DLLs or shared libraries, you must specify them in the list.
For Java components, the implementation class and any classes listed in the Java Classes tab.
For PowerBuilder components, the libraries starting with $ (dollar sign) that are referenced by the property com.sybase.jaguar.component.pb.librarylist.

Any additional files that are required to run the component must be listed on the Additional Files tab. Use the Additional Files wizard to enter a list of file names, separated by commas. Files may be specified as follows:

Specify Java classes and packages using the Java dot notation. For example, com.sybase.CORBA adds all files in the com.sybase.CORBA package. These classes must be deployed under the EAServer java/classes subdirectory.
If a DLL or shared library is deployed in the EAServer cpplib subdirectory, you can enter the filename itself. For example myutils.dll .
Other files must be specified using full paths or paths that are relative to the EAServer Repository subdirectory. For example, ../dll/debug/MyDebugLibrary.dll or d:\mydir\myfile.ext. If you use full paths, you will only be able to synchronize or import package archives on machines which share the same directory structure as your development machine.

Configuring the Additional Files list

When you include additional files, you can either enter the file names individually, or you can use the Additional Files wizard to add multiple files, packages, classes, and directories.

Entering file names individually

Click Add. This opens the Add a File Name to the List dialog box.
Enter the file name and click Ok.

Adding multiple items

Click Additional Files Wizard. This open the Additional Files dialog box. Each item that you add is appended to the list.
To add Java packages or classes:
1. Click Browse
2. Choose a *.class file and click Select.
The class files must be deployed under EAServer's java/classes directory.
To add files or directories:
1. Optionally, specify a file filter, such as *.txt.
2. Optionally, select to use the JAGUAR environment variable.
3. Click Browse.
4. Choose a file or directory and click Select.
To add property files from other entities:
1. Click Browse.
2. Choose a *.props file from under the Repository directory and click Select.
To add file lists from other entities:
1. Click Browse.
2. Choose an entity's *.files file and click Select.
Click Add Files to Additional Files List.

Component properties: JAXP

For EJB 2.0 components, configures the JAXP, DOM, and XSLT parser implementations used in the component. See Chapter 27, "Configuring Java XML Parser Support" for more information on these properties.

Component properties: All Properties

The All Properties tab allows you to edit component property settings as they are stored in the EAServer configuration repository. You can only delete properties that you have added--you cannot delete default properties, such as the Instance Timeout property.

For information on repository properties, see the chapter, "Repository Properties Reference," in the EAServer System Administration Guide.

Setting properties

Look for the property name in the list of properties. If it is displayed, highlight the property and click Modify. Otherwise, click Add.
If adding the property, fill in the Add Property fields as follows:
1. Enter the property name in the Name field
2. Enter the value in the Value field.
If modifying a property, edit the displayed value in the Modify Property window.

When to use the All Properties tab Though you can use the All Properties tab to set any property prefixed with "com.sybase.jaguar.component", Sybase recommends that you use this tab to set properties only as specified by the EAServer documentation or by Sybase Technical Support. Most properties can be configured graphically elsewhere in the Jaguar Manager user interface.

The following component properties can be configured only from the All Properties tab:

Configuring a control interface

The com.sybase.jaguar.component.control property pecifies the name of the component's IDL control interface. EAServer calls each control interface method in response to changes in the instance lifecycle. The choices are summarized in this table:

Control Interface	Description
JaguarEJB::EntityBean	For EJB entity Beans.
JaguarEJB::StatefulSessionBean	For EJB stateful session Beans.
JaguarEJB::StatelessSessionBean	For EJB stateless session Beans.
JaguarEJB::ServerBean	The EAServer 1.1 Java component lifecycle model. The default for Java/CORBA components that do not have persistent state (that is, when the Persistence field is None).
CtsComponents::ObjectControl	A CORBA lifecycle model based on the EJB entity bean model. The default for Java/CORBA and C++/CORBA components with persistent state (that is, when the Persistence field is Component Managed).
JaguarCOM::ObjectControl	For ActiveX components.

These interfaces are documented in the generated IDL documentation, which is available in HTML format in the html/ir subdirectory of your EAServer installation. If you use a control interface other than JaguarEJB::ServerBean, EAServer generates the control interface methods in the implementation template when you generate a C++ or Java skeleton.