Chapter 5 Defining Components

Configuring component properties

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

Tab	Description
General	Defines basic information about the component, including the supported IDL interfaces, the component type, and implementation details such as Java class name or the C++ library name.
Transactions	Defines the components transactional properties, such as how the component participates in transactions and whether the component explicitly commits its work.
Instances	Defines how instances of the component are managed, including instance creation, thread binding, and client/component bindings.
Run-As Mode	Specifies the user name and password that are used for intercomponent calls to components installed in the same server or cluster.
Resources	Configures properties that govern the component's use of server and database resources.
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.
All Properties	Allows you to manually edit component property settings in the Jaguar configuration repository. For advanced users.

General component properties

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 5-1: General 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. 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 Jaguar 1.1 require this option. PowerBuilder NVO A PowerBuilder Non-Visual Object adapted to run as a Jaguar component. COM/ActiveX An ActiveX component adapted to run as a Jaguar component. C++ A C++ class adapted to run as a Jaguar component. C A collection of C routines adapted to run as a Jaguar component.	EJB components must be implemented in accord with version 1.0 or 1.1 of the Enterprise JavaBeans specification. Version 1.1 is recommended for new development. ActiveX components are supported only in the Windows NT version of Jaguar. All other component types can run on any platform that is supported by Jaguar.
EJB Version only for EJB components	Choose 1.0 or 1.1 to match the EJB specification version number. Jaguar's interaction with the component is governed by the specification version. Version 1.1 is recommended for new development.
Bean Class only for EJB components	The name of the class that implements the Bean, in Java dot notation.
Bean Home 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 Bean Home 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 Jaguar 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.
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, use the All Properties tab, and set the `com.sybase.jaguar.component.key` property to the IDL type name.
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 Jaguar installation directory.
C++ Class (only for C++ components )	The name of the C++ class that implements the component.
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 NT 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 Jaguar 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 Jaguar 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 Jaguar Component Wizard.

Transactions tab component properties

The Transactions tab configures the component's transactional properties. Chapter 3, "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 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 a Jaguar 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, Jaguar 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, Jaguar 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 Jaguar 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, Jaguar 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.

Jaguar 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 Jaguar 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

Transaction isolation level property is not supported in EJB 1.1 The EJB 1.1 specification does not require servers to support configuration of transaction isolation level as a declarative property. Future Jaguar versions that implement the EJB 1.1 specification will not export this setting in EJB-JAR files.

Automatic demarcation/ deactivation

Applies only to non-EJB components only. When this option is enabled, Jaguar 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 Jaguar 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 Jaguar CTS System Administration Guide for more information.

Instances tab component properties

Properties on the Instances tab configure how instances of the component are created and bound to server-side threads and client-side object references. The properties are as follows:

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, Jaguar serializes all method calls to the component. Concurrency applies to execution of all instances 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 "Instances tab component properties"). 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 "Persistence tab component properties" 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. Enable this option if you are creating a service component. See Chapter 33, "Creating Service Components" for more information. 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. 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 "Persistence tab component properties").
Reentrant	Applies to EJB entity Beans only. 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.

Environment tab component properties

Applies to EJB 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.

EJB Refs tab component properties

Applies to EJB 1.1 components only. EJB references provide an alias mechanism for the home names used to create proxies for intercomponent calls. The home 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 home names to the references used by your component. See "Configuring EJB references" for more information.

Resource Refs tab component properties

Applies to EJB 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.

Role Refs tab component properties

Applies to EJB 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.

Resources tab component properties

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 a Jaguar transaction. See Chapter 3, "Understanding Transactions and Component Lifecycles" for more information on Jaguar transactions.
The timeout period is configured in seconds, with 0 indicating infinity (that is, no timeout). If the component's Transaction 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. Jaguar 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.

To set Transaction Timeout for a server, display the All Properties tab in the Server Properties window. Then set the com.sybase.jaguar.server.tx_timeout property.

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.
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 vs. stateless components" explains this term.) The setting has no effect for stateless components.
When the timeout period is exceeded, Jaguar 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.

Persistence tab component properties

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

Table 5-2 summarizes the Persistence settings. See Chapter 29, "Managing Persistent Component State" for detailed information on these fields.

Table 5-2: Persistence tab component properties
Field	Description
Persistence	Specifies whether component state is saved, and if so, how. The available options are: None The default. The component's state is not stored in a database. Java Serialization For EJB stateful Session Beans only. The component implementation class is serialized and deserialized to save and restore component state. Component Class Your component implementation manages persistence. Used for EJB entity Beans or for CORBA components that use the EJB entity Bean design pattern for state management. Generated Class A generated C++ or Java class saves and restores component state from a remote database. Jaguar Manager does not generate such classes, but third-party tool vendors can use this option. The generated class can inherit from or delegate to the component's implementation class to save and restore component state. Automatic Persistent State Jaguar manages the persistent state of your component.
Primary Key	The primary key for EJB entity Beans or for CORBA components that follow the EJB entity Bean style of state management. Specify the IDL type of the components primary key. For example: `foo::bar::MyPK` . Components with a primary key must have a findByPrimaryKey method in their home interface, and can have additional finder methods that allow clients to look up instances that match a desired primary key. See "Patterns for finder methods" for more information. Unless you have defined an entity Bean by importing class or EJB-JAR files, you must define the primary key type yourself. For a CORBA component, you can specify any valid IDL type as the primary key. For an EJB entity Bean, choose from the types listed in "Allowable primary key types".
State	When using automatic persistence, specifies the name of an IDL type or serializable Java class. The named type must encapsulate all data to be persisted.
State Methods	The names of methods in the implementation class that get and set the state datatype, specified as a 2-item comma separated list. The default is `getState,setState` . For EJB entity Beans, enter `default` .
Generated Class	The name of generated C++ or Java class that saves and restores component state from a remote database. Jaguar Manager does not generate such classes, but third-party tool vendors can use this option. The generated class can inherit from or delegate to the component's implementation class to save and restore component state.
Storage Component	Specifies the name of a component that reads and writes component state information from a remote database server. Required when using automatic persistence, or when using component-managed persistence with an implementation that delegates to Jaguar's built-in storage component. See "Storage components" for more information.
Connection Cache	Specifies the connection cache used by the storage component. The cache must be installed on all servers where your component runs and allow by-name access.
Table	Specifies the name of the database table to store component state information. If the table name is prefixed with "map:", as in "map:MyTable", field and column names must be mapped to implementation class fields as described in "Specify field to column mapping properties". If just the table name is specified, the table must have the schema described in "Table schema for binary storage".
Timestamp	When using a mapped database table, specifies the timestamp used for optimistic concurrency control. Specify one of the following: A column name The name of a column in the mapped table that is incremented in each update. By default, Jaguar uses 4-byte integer timestamp. You can also use a 16-byte binary value, but to do so, you must set the `com.sybase.jaguar.component.ts.length` property to `binary(16)` . "None" Enter "none" to disable optimistic concurrency control. This setting is not recommended. No value If you leave the Timestamp field blank, Jaguar uses all column values to perform optimistic concurrency control. For best performance, use a 4-byte integer timestamp column. The timestamp column need not be mapped to the component's persistent state fields. 16-byte binary timestamp values are not useable when other processes (besides Jaguar server) update a table.
Timeout	This setting is reserved for future use.

Run-As Mode tab component properties

This tab specifies the user name and password that are used when methods call other Jaguar 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 Jaguar CTS System Administration Guide.

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

All Properties tab

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

You can set properties as follows:

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.

Repository property names are listed in the documentation for the Jaguar::Repository IDL interface, in the description of the define method. To read this documentation, load your server's main HTML page into a Web browser, and follow the "Interface Repository" link.

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 Jaguar 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:

com.sybase.jaguar.component.keys For an EJB entity Bean, specifies the name of an IDL typedef for a sequence of the Bean's primary key structures. This type is used when generating the skeleton and implementation classes for the component.

When you manually specify a value for the Primary Key field on the Persistence tab, Jaguar Manager sets this property to module::componentKeys where module is the module containing the primary key type, and component is the component name. Jaguar Manager defines the type if it does not exist, using the following structure:

typedef <sequence pk> componentKeys

where pk is the primary key type, and component is the component name.

Set the com.sybase.jaguar.component.keys property only when you have manually defined a sequence that uses another naming convention or that is located in another module.

If you have used PowerJ or the Jaguar Manager import feature to import an entity Bean, the com.sybase.jaguar.component.keys typedef may use a different naming convention.

com.sybase.jaguar.component.list For an EJB 1.0 entity Bean, specifies the name of an IDL typedef for a sequence of the Bean's remote interface type. In an entity Bean's IDL home interface, methods that return a collection of instances must return the type name specified by this property.

When you manually specify a value for the Primary Key field on the Persistence tab, Jaguar Manager sets this property to module::componentList where module is the module containing the primary key type, and component is the component name. Jaguar Manager defines the type if it does not exist, using the following structure:

typedef <sequence ri> componentList

where ri is the remote interface name, and component is the component name.

Set the com.sybase.jaguar.component.list property only when you have manually defined a sequence that uses another naming convention or that is located in another module.

If you have used PowerJ or the Jaguar Manager import feature to import an entity Bean, the com.sybase.jaguar.component.keys typedef may use a different naming convention.

com.sybase.jaguar.component.tx_outcome Determines whether a CORBA::TRANSACTION_ROLLEDBACK exception is thrown to the client when a transaction is rolled back. The allowable settings are:

Setting	Description
always	The default. Jaguar server sends a CORBA::TRANSACTION_ROLLEDBACK exception to the client when a transaction is rolled back.
failed	Jaguar does not send the CORBA::TRANSACTION_ROLLEDBACK exception to the client when a transaction is rolled back. If you use this setting, you can code your components to raise a different exception with a descriptive message after calling the RollbackWork transaction primitive. With this setting in effect, Jaguar may still throw a CORBA system exception if unable to commit a transaction at your component's request.

Setting

Description

always

The default. Jaguar server sends a CORBA::TRANSACTION_ROLLEDBACK exception to the client when a transaction is rolled back.

failed

Jaguar does not send the CORBA::TRANSACTION_ROLLEDBACK exception to the client when a transaction is rolled back. If you use this setting, you can code your components to raise a different exception with a descriptive message after calling the RollbackWork transaction primitive.

With this setting in effect, Jaguar may still throw a CORBA system exception if unable to commit a transaction at your component's request.

You can set this property to failed if you require that no exceptions are sent to the client for rolled-back transactions or that an alternate exception is sent. This setting is useful if you require that the client be able to retrieve output parameters after a transaction is rolled back: if an exception is thrown, the output parameters are not available.

com.sybase.jaguar.component.cpp.debug When set to true , specifies that the component should be executed outside of the scope of Jaguar's internal C++ exception handling. The default is false . You must set this property to true in order to debug an executing C++ component in Microsoft Visual C++. Other C++ debuggers may require the same setting as well. See "Debugging C++ components" for more information.

com.sybase.jaguar.component.pb.debug When set to true , specifies that the component can be debugged from the PowerBuilder IDE. This property is set as a PowerBuilder deployment option, and should not be set in Jaguar Manager. See "Debugging C++ components" for more information.

com.sybase.jaguar.component.refresh This property specifies whether the component can be refreshed. If the value is false , the File | Refresh option has no effect for the component. Allowable values are true and false . The default is true .

com.sybase.jaguar.component.java.classes For Java components, this property lists additional java classes that must be reloaded when the component is refreshed as described in "Refreshing Java components". The property takes as values a list of fully qualified class names separated by commas. You can specify all classes in a package using wildcards, as in this example:

com.xyz.MyPackage.*

You can specify all classes in a JAR file by specifying the JAR file name, as in this example:

MyEntityBean.jar

The JAR file must be deployed in the Jaguar java/classes subdirectory.

Copies of the specified classes must be deployed under one of the following locations. When loading classes required by Java components, Jaguar searches for classes in this order:

Any JAR file that is listed in the com.sybase.jaguar.component.java.classes property and deployed in the Jaguar java/classes subdirectory.
The class tree based at the Jaguar java/classes subdirectory.
The class tree based at the Jaguar html/classes subdirectory.

Some shared classes should not be in the custom class list Classes that are shared by multiple component instances. and that keep volatile state in static instance variables (that is, have static variables that are set after class initialization completes), must not be listed in the com.sybase.jaguar.component.classes custom class list. If these classes are in the custom class list, instances loaded by different components have different views of static instance variables.

com.sybase.jaguar.component.control Specifies the name of the IDL control interface. The control interface defines methods called by the Jaguar server 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 Jaguar 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 Jaguar installation. If you use a control interface other than JaguarEJB::ServerBean, Jaguar generates the control interface methods in the implementation template when you generate a C++ or Java skeleton.

com.sybase.jaguar.component.files Specifies additional files that are included when the component is archived with the package export feature or replicated with the synchronize feature. See "Component files property" for more information.

Component files property

The com.sybase.jaguar.component.files property specifies a list of files that are to be included when the component is exported into a package archive file or replicated to another server 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 com.sybase.jaguar.component.java.classes property.
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 in the com.sybase.jaguar.component.files setting. Set or modify this property on the All Properties tab in the Component Properties window. 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 Jaguar java/classes subdirectory.
If a DLL or shared library is deployed in the Jaguar 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 Jaguar 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.