|
Release Notes 2.0.8 |
|
|
New logon properties |
- jco.client.alias_user
An alias user name may be used instead of a normal user name or even
together with a jco.client.user. But if both - jco.client.user
and jco.client.alias_user - are used together they have to match.
- jco.client.idle_timeout
Prerequisites for using this feature: Minimum ABAP Kernel Release 6.20,
Patchlevel 623 and RFC native library, Patchlevel 623.
The connection property jco.client.idle_timeout sets the maximum
idle time interval (in seconds) for a client connection. The SAP backend
system will close the connection after the specified time of inactivity
and will destroy the according ABAP context. The associated JCO.Client
instance will not be notified about the destruction of the connection. The next
attempt to use the connection will cause a JCO.Exception: RFC_ERROR_SYSTEM_FAILURE.
Note that using this feature makes only sense in some special scenarios.
Explicitly releasing connections is always more efficient and should therefore
be the preferred way (see OSS note 593513).
|
|
|
Bugfix in JCO.Record.hashCode() |
JCO.Record.hashCode() could fail with a NullPointerException or
an ArrayIndexOutOfBoundsException.
|
|
|
Bugfix in JCO.Pool |
JCO.Pool.getClient() could fail with a JCO.Exception: JCO_ERROR_RESOURCE,
if previous calls to JCO.Pool.getClient() failed with a
JCO.Exception: JCO_ERROR_LOGON_FAILURE.
|
|
|
Release Notes 2.0.7 |
|
|
Bugfix in JCO.Table |
The row fields were not set to initial values after a call to JCO.Table.append()
or JCO.Table.insert(). This bug is only known in 2.0.6.
|
|
|
Release Notes 2.0.6 |
|
|
Added new method JCO.Client.isPooled() |
Method isPooled() is added to JCO.Client. The method returns true
if the client connection was allocated from a pool or false otherwise.
|
|
|
Added new method JCO.setTracePath(String path) |
JCo now offers a static method JCO.setTracePath(String path). With this method
the application can define a directory for the JCo trace output files.
|
|
|
Support for IBM JDK 1.3.1 |
JCo on IBM JDK 1.3.1 stopped with the error FATAL ERROR in native method: Try to unpin an object that is not pinned.
This error occurred on AIX and Linux with J2RE 1.3.1 IBM build cxia32131-20020302.
|
|
|
Bugfix in JCO.Record.equals(...) |
JCO.Record.equals(...) threw an ArrayIndexOutOfBoundsException
in some cases because of an incorrect handling of internal buffers.
|
|
|
Bugfix in Table.ensureBufferCapacity() |
A JCO.Table with one column (also known as 'vector') has overwritten
its own content in some cases if new rows were appended or inserted.
|
|
|
Bugfix in unmarshalling of parameters (ABAP -> Java) |
If a complex parameter (data type of structure type 2, table, string
or xstring) has not been filled a called JCO.Server could not convert the
empty parameter. This caused the exception "JCO.Server could not unmarshall
import parameters" or in some cases an ACCESS_VIOLATION occurred
within the JVM native code.
|
|
|
Release Notes 2.0.5 |
|
|
Bugfix in repository: handling of complex nested types |
The handling of complex nested types in JCo's repository was improved. All
possible data dictionary (DDIC) definitions are supported now including any
combinations of vectors with nested tables and nested structures.
|
|
|
Bugfix on error handling of JCO.Client |
If an error or exception occurs within a method of a JCO.Client
object, it may become unusable. In this case the object will always throw a
JCO.Exception of the error group JCO_ERROR_CONCURRENT_CALL
on all further method calls.
|
|
|
Bugfix on incompatible API method |
The signature of the method JCO.PoolManager.addPool(...) that was
modified with release 2.0.4 is now compatible to the release 2.0.3 again.
|
|
|
|
Release Notes 2.0.4 |
|
|
New methods in JCO.Pool |
The pool size, the maximum number of connections, the connection time-out and the check
period for timeout can be configured for each pool independently.
JCO.Pool.getMaxPoolSize / JCO.Pool.setMaxPoolSize - returns / sets the
maximum number of connections to keep open in the JCO.Pool.
JCO.Pool.getMaxConnections / JCO.Pool.setMaxConnections - returns / sets
the maximum number of connections that can be obtained from the pool.
JCO.Pool.getConnectionTimeout / JCO.Pool.setConnectionTimeout - returns / sets
the timeout value for the connection pool. A pooled connection will be closed if it has
not been used for the specified timeout time.
JCO.Pool.getTimeoutCheckPeriod / JCO.Pool.setTimeoutCheckPeriod - returns / sets
the timeout check period in (ms), i.e. the time after which all pooled connections will be
checked for timeouts periodically.
|
|
|
Now throwing an exception on concurrent calls |
If the same connection/client object is used from two or more threads simultaneously,
a JCO.Exception of the error group JCO_ERROR_CONCURRENT_CALL
will be thrown now. In previous JCo releases such multithreaded behavior lead to CPIC
errors and/or memory access violations crashing the whole java process (see OSS note 513386).
|
|
|
Bugfix in JCO.Server.handleRequest |
Within a tRFC request the method JCO.Server.getAttributes() did not
return the correct RFC attributes and the internal codepage converter was not set
properly leading to incorrect codepage conversions under some circumstances.
|
|
|
Bugfix in JCO.Table |
JCO.Table.previousRow() returned false if the cursor was
pointing to the second row.
|
|
|
|
Release Notes 2.0.3 |
|
|
Improved tracing mechanism |
JCo's trace can now be turned on by setting the following java environment
properties on startup:
-Djco.trace_level=N, where 0 ≤ N ≤ 10
and optionally
-Djco.trace_path=PATH
If a trace path is set the trace will be written to files that will be created in
the PATH directory. Otherwise the trace is written to the standard output
stream (default: the console).
The trace could also be turned on by calling the following java methods:
JCO.setTraceLevel(N), where 0 ≤ N ≤ 10
and optionally
com.sap.mw.jco.util.TraceWriter.start(PATH)
|
|
|
Bugfix in repository: handling of vectors |
The handling of vectors and nested tables in JCo's repository was improved.
|
|
|
Bugfix on conversion of double to BCD types |
The conversion of double values to BCD values was wrong if either the double
value had more than 5 predecimal places or more than 3 decimal places.
|
|
|
Bugfix on notification of server exception listeners |
Registered JCO.ServerExceptionListener objects were not
notified about all internal JCO.Server exceptions.
|
|
|
|
Release Notes 2.0 - 2.0.2 |
|
|
JCo 2.0 requires Java JDK 1.2 or higher |
JCo 2.0 requires a Java JDK or JRE of version 1.2 or higher.
Customers who still need JDK 1.1 support have to use JCo 1.1.x.
|
|
|
Support for SAP Unicode releases |
Support for SAP systems running in Unicode mode has been added.
|
|
|
Support for request/response model |
In addition to the class JCO.Function, two new classes JCO.Request and JCO.Response have
been added to support the request/response model. See Javadoc for details.
|
|
|
Enhanced XML support |
XML support has been enhanced. From the request/reponse containers XML documents
can be generated which are in compliance with the SAP Interface Repository.
|
|
|
New methods IMetaData.getInternalLength(...) |
The interface IMetaData has been augmented by the methods
IMetaData.getInternalLength(int field_index) and IMetaData.getInternalLength(String field_name).
These return the internal length of a field in bytes.
When being connected to SAP non-Unicode systems the methods getLength(...) and getInternalLength(...) will
return the same value whereas on Unicode systems they will differ for certain data types.
|
|
|
New methods JCO.Client.send(..) |
In order to support the IDoc add-on package, the methods JCO.Client.send(...) have been added.
These methods will send Intermediate Documents generated by the IDoc package to the SAP system.
|
|
|
New constructors in class JCO.Server |
Two new constructors JCO.Server(Properties properties, IRepository repository) and
JCO.Server(Properties properties, IServerThread thread, IRepository repository)
have been added.
|
|
|
Renaming and loading of runtime libraries |
In order to avoid name conflicts, the JCo runtime libraries have been renamed.
The Java archive sapjco.jar contains the JCo runtime classes. The operating system-dependent
native runtime library sapjcorfc.dll | libsapjcorfc.so | libsapjcorfc.sl
contains the JNI bridge to the RFC library.
JCo 2.0 loads its native runtime library from the same directory where the sapjco.jar
file resides. If it cannot be found there, JCo will search the native runtime library along the path
defined by the java.library.path system property and finally it will use the Java built-in
mechanism for loading it.
The RFC library librfc32.dll | librfccm.so | librfccm.sl is always
loaded by the operating system depending on the appropriate system-defined path.
|
|
|
New version dialog |
JCo's version information can now conveniently be determined by using the command
java -jar {sapjco-install-path}/sapjco.jar
or
java -classpath {sapjco-install-path}/sapjco.jar com.sap.mw.jco.About
in the installation directory. The command will pop up a dialog with the relevant version
information. On non-windowing systems one can get the same information
printed to the console by typing
java -jar {sapjco-install-path}/sapjco.jar -stdout
or
java -classpath {sapjco-install-path}/sapjco.jar com.sap.mw.jco.About
-stdout
|
|