Product: Corepoint Telephony Toolkit for Java Version: 6.2.0 Level: J2066 Platform: WindowsNT Date: 25 July 2001 Service File: jtkwnt.exe Size: 1445628 (1.4Mb) Installation Instructions: -------------------------- Download the self-extracting file, jtkwnt.exe, into a temporary directory. Execute it from the command line and follow the prompts. This will start an InstallShield Wizard to guide you through the installation process. Fixes contained in this Service Package: ---------------------------------------- Name: APAR IC30895 Date: 10 Jul 2001 Detail: Assumption was that Java would throw exception in available when listening to a socket which fails. Exception was not generated so clean up code did not run. The result of this is any provider observers not getting notified of OUT_OF_SERVICE or SHUTDOWN. Solution: Added in function to allow the JTAPI client to start sending CallPath Enterprise heartbeat messages to the server any time the connection would otherwise be idle. If the heartbeats fail we assume the connection is lost, clean up and notify any interested provider observers. Name: APAR IC29823 Date: 09 Mar 2001 Detail: The JTAPI Daemon will fail to keep up with the telephony activity when using 20+ CPLineResources in an application. The slow down is due to the duplicate provider connections created by calling the .start() method on each CPLineResource. This created redundant connections into the JTAPI daemon and therefore the same event was sent to the application for each CPLineResource started in this manner. Workaround: The application must be recoded to chain the .start() method calls with the .start(event) call as outlined in the CallPath Enterprise Java Programmers Guide and Reference. Solution: To avoid the creation of duplicate provider connections to the JTAPI Daemon, the JtapiPeer class was updated to store all active connections. Therefore, the getProvider calls for the same user will only create a single connection to the JTAPI Daemon instead of a new one for each call. This change will eliminate the need to change applications and greatly improve the performance by avoiding creation of the duplicate event data. 9537 is an extension which fixes a minor problem with the original fix where the wrong state was being checked. Name: Defect 8921 Date: 21 Sep 2000 Detail: When using the BlindTransferBean within a DT/NT script, occasional errors could occur that would result in RC 100 on the transfer. Also, occasional nullpointer exceptions could cause DT channels to terminate abnormally. Workaround: None. Solution: BlindTransfer Bean was modified to wait for appropriate TerminalConnection objects to be associated with the call before completing the transfer request. LineResource class was modified to fix the nullpointer exception on the getConnections() method, which could sometimes occur under load conditions. Note: A new feature was also added to the BlindTransfer bean: setAutoRecover(boolean). This feature allows the user to determine whether they want the bean to attempt to retrieve the call if the transfer fails, or leave it in the current state. The default is to attempt to autorecover. Name: PMR 29491 Date: 20 Mar 2000 Workaround: None. Solution: A timing condition existed where when a call object was transitioning to the Call.INVALID state the connections were being updated before the state value. A client therefore could enter a timing window where a getConnections() or getState() request on the call could be answered after the connections were removed but before the INVALID state was set. In the case of getState() this would cause the state to be improperly reflected as ACTIVE. In the case of getConnections() a PlatformException will be thrown with the following message: "Call State ACTIVE with no connections." A critical section has been added to the code such that any getState()/ getConnections() request coming in will temporarily block until both the connections are removed and the state is updated. Name: Defect 8111 Date: 17 Jan 2000 Workaround: None. Solution: The JTAPI Daemon and client was updated to respond to a TadsRereadINI event that is sent when a reconfiguration occurs. The daemon detects the JTAPI user address and/or ACD address changes and will send a provider SHUTDOWN event and close the provider session only to the affected users. Configuration changes made to a JTAPI user exclusively for toolbars, speed dial buttons, or passwords have no effect on a session. This change introduces a new type of JTAPI user called a dynamic user. A dynamic user has no preconfigured addresses or ACD addresses. Users with addresses of either type are called static users. To handle dynamic users, this new JTAPI java client has a modified JtapiPeer.getProvider() request. The new JtapiPeer.getProvider() request allows two additional tags to specify addresses and/or ACD addresses to use for this session. The format is ... This new functionality is only available for dynamic JTAPI users. Static JTAPI users that attempt to use this request will be denied for security reasons. Existing JTAPI applications (see note 1) will continue to function as before without repackaging and will receive a SHUTDOWN event if reconfigured. Note 1: The existing release of CPPhone (as of the end of 1999) will not correctly respond to reconfiguration changes. It will receive a SHUTDOWN event, but the deleted addresses will still exist on the screen and the new ones will not appear. CPPhone must be shutdown and restarted in order to start operating with the new configuration changes. A new release of CPPhone is available in parallel with the new JTAPI Daemon that will correctly handle address reconfigurations. String myArgs = new String( "7600@cp01;login=george;passwd=gwc552;" + "addresses=1111,2222;acdaddresses=3333,4444;" ); Provider myProvider = getProvider(myArgs); Name: Defect 7918 Symptom: Some GIF images did not have a transparent backgound. Detail: Some GIF images did not have a transparent backgound. Some GIF files have been updated to have transparent backgounds. Name: Defect 7927 Symptom: The ConnectionItemTransferred event is not fired for originating party Detail: The ConnectionItem gets deleted too early causing the ConnectionItemTransferredEvent not to fire. Name: APAR IC27960 Symptom: Fix out of memory error due to connections not gettting cleaned up. Detail: The problem discovered was that the data structure used to maintain the list of connections associated with an address, under the right circumstances, would begin to grow. Once it started growing it would continue to grow indefinitely, continuing to add new connections but not removing the old connections. Eventually this caused the memory available to be consumed. The cause of this was that the data structure was changing due to connections coming and going at the same time we were enumerating on the structure. This caused the enumeration to not be consistent with the data structure so we were not processing every item in the data structure. Solution, We changed the way we process the data structure to copy it into an array and process the array rather than just enumerating on the original data structure. Name: APAR IC29835 Date: 21 Sep 2000 Problem: The toolkit does not allow disconnection of call parties (connections) outside the provider space. Solution: Allow such parties to be disconnected. Files contained in this Service Package: ---------------------------------------- ibmcctl.jar ibmcpath.jar readme.jtk