Date: Fri, 29 Mar 2024 11:33:35 +0000 (UTC) Message-ID: <1738700607.25397.1711712015755@ae5f4610bf64> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_25396_1041577467.1711712015754" ------=_Part_25396_1041577467.1711712015754 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
In addition to the information provided in Upgrading your Applicati= on from Ice 3.4, users who are upgrading from Ice 3.3 should also revie= w this page.
On this page:
A discussion of backward compatibility in Ice involves many factors.
Ice maintains source-code compatibility between a patch release (e.g., 3= .4.2) and the most recent minor release (e.g., 3.4.0), but does not guarant= ee source-code compatibility between minor releases (e.g., between 3.4 and = 3.5).
The subsections below describe the significant API changes in this relea= se that may impact source-code compatibility. Furthermore, the subsections = Remov= ed APIs in Ice 3.4.0 and Deprecated APIs in Ice 3.4.0 summarize addit= ional changes to Ice APIs that could affect your application.
As for source-code compatibility, Ice maintains backward binary compatib= ility between a patch release and the most recent minor release, but does n= ot guarantee binary compatibility between minor releases.
The requirements for upgrading depend on the language mapping used by yo= ur application:
Ice always maintains protocol ("on the wire") compatibility with prior r= eleases. A client using Ice version x can communica= te with a server using Ice version y and vice versa.&nbs= p;
Several features introduced in Ice 3.5 require a new version of the Ice = encoding, encoding version 1.1. Older versions of Ice do not understand thi= s encoding: you need to use Ice encoding version 1.0 for communications bet= ween clients or servers using Ice 3.5 and clients and servers using older I= ce versions. See Encodin= g Version 1.1 for details.
Upgrading to a new minor release of Ice often includes an upgrade to the= supported version of Berkeley DB. In turn, this may require an application= to migrate its databases, either because the format of Berkeley DB's datab= ase files has changed, or due to a change in the schema of the data stored = in those databases.
For example, if your application uses Freeze, it may be necessary for yo= u to migrate your databases even if your schema has not changed.
Certain Ice services also use Freeze in their implementation. If your ap= plication uses these services (IceGrid and IceStorm), it may be necessary f= or you to migrate their databases as well.
Please refer to the relevant subsections below for migration instruction= s.
Although Ice always maintains compatibility at the protocol level, chang= ing Slice definitions can also lead to incompatibilities. As a result, Ice = maintains interface compatibility between a patch release and the most rece= nt minor release, but does not guarantee compatibility between minor releas= es.
This issue is particularly relevant if your application uses Ice service= s such as IceGrid or IceStorm, as a change to an interface in one of these = services may adversely affect your application.
Interface changes in an Ice service can also impact compatibility with i= ts administrative tools, which means it may not be possible to administer a= n Ice 3.4.x service using a tool from a previous minor release (or vice-ver= sa).
Starting with Ice 3.2.0, IceGrid registries and nodes are interface-comp= atible. For example, you can use an IceGrid node from Ice 3.2 with a regist= ry from Ice 3.4.
IceGrid registry replication is only supported between registries using = Ice 3.3 or later.
An IceGrid node using Ice 3.3 or later is able to activate a server that= uses Ice 3.2. The reverse is also true: an IceGrid node from Ice 3.2 is ab= le to activate a server built with Ice 3.3 or later, but only if the server= 's configuration properties do not rely on features added after Ice 3.2 (su= ch as the ability to escape characters in property names and values).
Topic linking is supported between all IceStorm versions released after = 3.0.0.
The Java2 language mapping, which was deprecated in Ice 3.3, is no longe= r supported. The Slice compiler and Ice API now use the Java5 language mapp= ing exclusively, therefore upgrading to Ice 3.4 may require modifications t= o your application's source code. The subsections below discuss the languag= e mapping features that are affected by this change and describe how to mod= ify your application accordingly.
The global metadata directives java:java2
and java:ja=
va5
are no longer supported and should be removed from your Slice fi=
les. The Slice compiler now emits a warning about these directives.
Support for the portable metadata syntax has also been removed. This syn= tax allowed Slice definitions to define custom type metadata that the Slice= compiler would translate to match the desired target mapping. For example:=
["java:type:{java.util.ArrayList}"] sequence<S= tring> StringList;
The braces surrounding the custom type java.util.ArrayList
=
directed the Slice compiler to use java.util.ArrayList<String><=
/code> in the Java5 mapping and
java.util.ArrayList
in the Jav=
a2 mapping.
All uses of the portable metadata syntax must be changed to use the corr= esponding Java5 equivalent.
Now that Slice dictionary types use the Java5 mapping, recompiling your =
Slice files and your application may cause the Java compiler to emit "unche=
cked" warnings. This occurs when your code attempts to assign an untyped co=
llection class such as java.util.Map
to a generic type such as=
java.util.Map<String, String>
. Consider the following e=
xample:
dictionary<string, int> ValueMap; interface Table { void setValues(ValueMap m); };
A Java2 application might have used these Slice definitions as shown bel= ow:
java.util.Map values =3D new java.util.HashMap(); values.put(...); TablePrx proxy =3D ...; proxy.setValues(values); // Warning
The call to setValues
is an example of an unchecked convers=
ion. We recommend that you compile your application using the compiler opti=
on shown below:
javac -Xlint:unchecked ...
This option causes the compiler to generate descriptive warnings about o= ccurrences of unchecked conversions to help you find and correct the offend= ing code.
The Slice type for request c=
ontexts, Ice::Context
, is defined as follows:
module Ice { dictionary<string, string> Context; };
As a dictionary, the Context
type is subject to the same is=
sues regarding unchecked conversions described for #Dictionaries. For example, each p=
roxy operation maps to two overloaded methods, one that omits the trailing =
Context
parameter and one that includes it:
interface TablePrx { void setValues(java.util.Map<String, Integer> m); // No context void setValues(java.util.Map<String, Integer> m, java.util.Map<String, String> ctx); }
If your proxy invocations make use of this parameter, you will need to c= hange your code to use the generic type shown above in order to eliminate u= nchecked conversion warnings.
The Java2 language mapping for a Slice enumeration generated a class who= se API differed in several ways from the standard Java5 enum type. Consider= the following enumeration:
enum Color { red, green, blue };
The Java2 language mapping for Color
is shown below:
public final class Color { // Integer constants public static final int _red =3D 0; public static final int _green =3D 1; public static final int _blue =3D 2; // Enumerators public static final Color red =3D ...; public static final Color green =3D ...; public static final Color blue =3D ...; // Helpers public static Color convert(int val); public static Color convert(String val); public int value(); ... }
The first step in migrating to the Java5 mapping for enumerations is to =
modify all switch
statements that use an enumerator. Before Ja=
va added native support for enumerations, the switch
statement=
could only use the integer value of the enumerator and therefore the Java2=
mapping supplied integer constants for use in case
statements=
. For example, here is a switch
statement that uses the Java2 =
mapping:
Color col =3D ...; switch(col.value()) { case Color._red: ... break; case Color._green: ... break; case Color._blue: ... break; }
The Java5 mapping eliminates the integer constants because Java5 allows =
enumerators to be used in case
statements. The resulting code =
becomes much easier to read and write:
Color col =3D ...; switch(col) { case red: ... break; case green: ... break; case blue: ... break; }
The next step is to replace any uses of the value
or =
convert
methods with their Java5 equivalents. The base class for all=
Java5 enumerations (java.lang.Enum
) supplies methods with sim=
ilar functionality:
static Color[] values() // replaces conve= rt(int) static Color valueOf(String val) // replaces convert(String) int ordinal() // replaces value()
For example, here is the Java5 code to convert an integer into its equiv= alent enumerator:
Color r =3D Color.values()[0]; // red
Note however that the convert(String)
method in the Java2 m=
apping returned null for an invalid argument, whereas the Java5 enum method=
valueOf(String)
raises IllegalArgumentException
=
instead.
Refer to the ma= nual for more details on the mapping for enumerations.
The Java API for Freeze maps = has been revised to used Java5 generic types and enhanced to provide additi= onal functionality. This section describes these changes in detail and expl= ains how to migrate your Freeze application to the API in Ice 3.4.
The Freeze API is now entirely type-safe, which means compiling your app=
lication against Ice 3.4 is likely to generate unchecked conversion warning=
s. The generated class for a Freeze map now implements the java.util.=
SortedMap<
K
,
V<=
/code>
>
interface, where K
is the key=
type and V
is the value type. As a result, applicati=
ons that relied on the untyped SortedMap
API (where all keys a=
nd values were treated as instances of java.lang.Object
) will =
encounter compiler warnings in Ice 3.4.
For example, an application might have iterated over the entries in a ma= p as follows:
// Old API Object key =3D new Integer(5); Object value =3D new Address(...); myMap.put(key, value); java.util.Iterator i =3D myMap.entrySet().iterator(); while (i.hasNext()) { java.util.Map.Entry e =3D (java.util.Map.Entry)i.next(); Integer myKey =3D (Integer)e.getKey(); Address myValue =3D (Address)e.getValue(); ... }
This code will continue to work, but the new API is both type-safe and s= elf-documenting:
// New API int key =3D 5; Address value =3D new Address(...); myMap.put(key, value); // The key is autoboxed to Integer. for (java.util.Map.Entry<Integer, Address> e : myMap.entrySet()) { Integer myKey =3D e.getKey(); Address myValue =3D e.getValue(); ... }
Although migrating to the new API may require some effort, the benefits =
are worthwhile because your code will be easier to read and less prone to d=
efects. You can also take advantage of the "autoboxing" features in Java5 t=
hat automatically convert values of primitive types (such as int) into their object equivalents (such as
Integer
).
Please refer to the manual for complete details on the new API.=
Java6 introduced the java.util.NavigableMap
interface, whic=
h extends java.util.SortedMap
to add some useful new methods. =
Although the Freeze map API cannot implement java.util.NavigableMap=
code> directly because Freeze must remain compatible with Java5, we have ad=
ded the
Freeze.NavigableMap
interface to provide much of the s=
ame functionality. A generated Freeze map class implements NavigableM=
ap
, as do the sub map views returned by map methods such as he=
adMap
. The NavigableMap
interface is described in the <=
a href=3D"/display/Ice35/Using+a+Freeze+Map+in+Java#UsingaFreezeMapinJava-m=
ap">manual, and you can also refer to the Java6 API documentation.
The Freeze Map API related to indices underwent some significant changes= in order to improve type safety and avoid unchecked conversion warnings. T= hese changes may cause compilation failures in a Freeze application.
In the previous API, index comparator objects were supplied to the Freez=
e map constructor in a map (in Java5 syntax, this comparators map would hav=
e the type java.util.Map<String, java.util.Comparator>
) =
in which the index name was the key. As part of our efforts to improve type=
safety, we also wanted to use the fully-specified type for each index comp=
arator (such as java.util.Comparator<Integer>
). However,=
given that each index could potentially use a different key type, it is no=
t possible to retain the previous API while remaining type-safe.
Consequently, the index comparators are now supplied as data members of =
a static nested class of the Freeze map named IndexComparators
=
. If your application supplied custom comparators for indices, you will nee=
d to revise your code to use IndexComparators
instead. For exa=
mple:
// Old API java.util.Map indexComparators =3D new java.util.HashMap(); indexComparators.put("index", new MyComparator()); MyMap map =3D new MyMap(..., indexComparators); // New API MyMap.IndexComparators indexComparators =3D new MyMap.IndexComparators(); indexComparators.valueComparator =3D new MyComparator(); MyMap map =3D new MyMap(..., indexComparators);
We also encourage you to modify the definition of your comparator classe= s to use the Java5 syntax, as shown in the example below:
// Old comparator class IntComparator implements java.util.Comparator { public int compare(Object o1, Object o2) { return ((Integer)o1).compareTo(o2); } } // New comparator class IntComparator implements java.util.Comparator<Integer> { public int compare(Integer i1, Integer i2) { return i1.compareTo(i2); } }
The second API change that might cause compilation failures is the remov= al of the following methods:
java.util.SortedMap headMapForIndex(String name, O= bject key); java.util.SortedMap tailMapForIndex(String name, Object key); java.util.SortedMap subMapForIndex(String name, Object from, Object to); java.util.SortedMap mapForIndex(String name);
Again, this API cannot be retained in a type-safe fashion, therefore
Please refer to the manual for complete details on the new = API.
In previous releases, Freeze for Java used finalizers to close objects s= uch as maps and connections that the application neglected to close. Most o= f these finalizers have been removed in Ice 3.4, and the only remaining fin= alizers simply log warning messages to alert you to the fact that connectio= ns and iterators are not being closed explicitly. Note that, given the unce= rtain nature of Java finalizers, it is quite likely that the remaining fina= lizers will not be executed.
All Freeze-related classes are now stored in a separate JAR file named <= code>Freeze.jar. As a result, you may need to update your build scri= pts, deployment configuration, and run-time environment to include this add= itional JAR file.
The Ice extension for PHP has undergone many changes in this release. Th= e subsections below describe these changes in detail. Refer to the PHP Mapping for more information about = the language mapping.
In prior releases, Slice files were deployed with the application and lo= aded at Web server startup by the Ice extension. Before each page request, = the extension directed the PHP interpreter to parse the code that was gener= ated from the Slice definitions.
In this release, Slice files must be translated using the new compiler <=
a href=3D"/display/Ice35/slice2php+Command-Line+Options">slice2php. This change offers several advantages:
Ice_UnknownLocalException
. See the section =
Run=
-time exceptions in PHP below for more information.All of the Slice files for Ice and Ice services are translated during an=
Ice build and available for inclusion in your application. At a minimum, y=
ou must include the file Ice.php
:
require 'Ice.php';
Ice.php
contains definitions for core Ice types and include=
s a minimal set of generated files. To use an Ice service such as IceStorm, include the appropriate generate=
d file:
require 'Ice.php'; require 'IceStorm/IceStorm.php';
With the transition to static code generation, you no longer need to dep=
loy Slice files with your application. Instead, you will need to deploy the=
PHP code generated from your Slice definitions, along with Ice.php=
code>, the generated code for the Ice core, and the generated code for any =
Ice services your application might use.
In prior releases, each PHP page request could access a single Ice commu=
nicator via the $ICE
global variable. The configuration of thi=
s communicator was derived from the profile that the script loaded via the =
Ice_loadProfile
function. The communicator was created on dema=
nd when $ICE
was first used and destroyed automatically at the=
end of the page request.
In this release, a PHP script must create its own communicator using an = API that is similar to other Ice language mappings:
function Ice_initialize() function Ice_initialize($args) function Ice_initialize($initData) function Ice_initialize($args, $initData)
Ice_initialize
creates a new communicator using the configu=
ration provided in the optional arguments. $args
is an array o=
f strings representing command-line options, and $initData
is =
an instance of Ice_InitializationData
.
An application that requires no configuration can initialize a communica= tor as follows:
$communicator =3D Ice_initialize();
More elaborate configuration scenarios are described in the section #PHP configura= tion below.
A script may optionally destroy its communicator:
$communicator->destroy();
At the completion of a page request, Ice by default automatically destro= ys any communicator that was not explicitly destroyed.
PHP applications may benefit from the ability to use a communicator inst= ance in multiple page requests. Reusing a communicator allows the applicati= on to minimize the overhead associated with the communicator lifecycle, inc= luding such activities as opening and closing connections to Ice servers.= p>
This release includes new APIs for registering a communicator in order t= o prevent Ice from destroying it automatically at the completion of a page = request. For example, a session-based application can create a communicator= , establish a Glacier2 session, and= register the communicator. In subsequent page requests, the PHP session ca= n retrieve its communicator instance and continue using the Glacier2 sessio= n.
The manual provides more information on this feature, an=
d a new sample program can be found in Glacier2/hello
.
Prior releases supported four INI settings in PHP's configuration file:<= /p>
ice.config
ice.options
ice.profiles
ice.slice
The ice.slice
directive is no longer supported since Slice =
definitions are now compiled statically. The remaining options are still su=
pported but their semantics are slightly different. They no longer represen=
t the configuration of a communicator; instead, they define property sets t=
hat a script can retrieve and use to initialize a communicator.
The global INI directives ice.config
and ice.options<=
/code> configure the default property set. The
ice.profiles
di=
rective can optionally nominate a separate file that defines any number of =
named profiles, each of which configures a property set.
As before, the profiles use an INI file syntax:
[Name1] config=3Dfile1 options=3D"--Ice.Trace.Network=3D2 ..." [Name2] config=3Dfile2 options=3D"--Ice.Trace.Locator=3D1 ..."
A new directive, ice.hide_profiles
, overwrites the value of=
the ice.profiles
directive as a security measure. This direct=
ive has a default value of 1, meaning it is enabled by default.
A script can obtain a property set using the new function Ice_getP=
roperties
. Called without an argument (or with an empty string), the=
function returns the default property set:
$props =3D Ice_getProperties();
Alternatively, you can pass the name of the desired profile:
$props =3D Ice_getProperties("Name1");
The returned object is an instance of Ice_Properties
, which=
supports the standard Ice API.
For users migrating from an earlier release, you can replace a call to <= code>Ice_loadProfile as follows:
// PHP - Old API Ice_loadProfile('Name1'); // PHP - New API $initData =3D new Ice_InitializationData; $initData->properties =3D Ice_getProperties('Name1'); $ICE =3D Ice_initialize($initData);
(Note that it is not necessary to use the symbol $ICE
for y=
our communicator. However, using this symbol may ease your migration to thi=
s release.)
Ice_loadProfile
also installed the PHP definitions correspo=
nding to your Slice types. In this release you will need to add requi=
re
statements to include your generated code.
Finally, if you wish to manually configure a communicator, you can creat=
e a property set using Ice_createProperties
:
function Ice_createProperties($args=3Dnull, $defaul= tProperties=3Dnull)
$args
is an array of strings representing command-line opti=
ons, and $defaultProperties
is an instance of Ice_Proper=
ties
that supplies default values for properties.
As an example, an application can configure a communicator as shown belo= w:
$initData =3D new Ice_InitializationData; $initData->properties =3D Ice_createProperties(); $initData->properties->setProperty("Ice.Trace.Network", "1"); ... $ICE =3D Ice_initialize($initData);
This release includes optional support for PHP namespaces, which was int=
roduced in PHP 5.3. Support for PHP namespaces is disabled by default; to e=
nable it, you must build the Ice extension from source code with USE_=
NAMESPACES=3Dyes
(see Make.rules
or Make.rules.ma=
k
in the php/config
subdirectory). Note that the extens=
ion only supports one mapping style at a time; installing a namespace-enabl=
ed version of the extension requires all Ice applications on the target Web=
server to use namespaces.
With namespace support enabled, you must modify your script to include a= different version of the core Ice types:
require 'Ice_ns.php'; // Namespace version of Ice.p= hp
You must also recompile your Slice files using the -n
optio=
n to generate namespace-compatible code:
% slice2php -n MySliceFile.ice
This mapping translates Slice modules into PHP namespaces instead of usi=
ng the "flattened" (underscore) naming scheme. For example, Ice_Prope=
rties
becomes \Ice\Properties
in the namespace mapping.=
However, applications can still refer to global Ice functions by their tra=
ditional names (such as Ice_initialize
) or by their namespace =
equivalents (\Ice\initialize
).
As mentioned earlier, prior releases of Ice for PHP only supported a lim=
ited subset of the standard =
run-time exceptions. An occurrence of an unsupported local exception wa=
s mapped to Ice_UnknownLocalException
.
This release adds support for all local exceptions, which allows an appl= ication to more easily react to certain types of errors:
try { $proxy->sayHello(); } catch(Ice_ConnectionLostException $ex) { // Handle connection loss } catch(Ice_LocalException $ex) { // Handle other errors }
This change represents a potential backward compatibility issue: applica=
tions that previously caught Ice_UnknownLocalException
may nee=
d to be modified to catch the intended exception instead.
In prior releases, to downcast a proxy you had to invoke the ice_c=
heckedCast
or ice_uncheckedCast
method on a proxy and s=
upply a type ID:
$hello =3D $proxy->ice_checkedCast("::Demo::Hell= o");
This API is susceptible to run-time errors because no validation is perf=
ormed on the type ID string. For example, renaming the Hello
i=
nterface to Greeting
requires that you not only change all occ=
urrences of Demo_Hello
to Demo_Greeting
, but also=
fix any type ID strings that your code might have embedded. The PHP interp=
reter does not provide any assistance if you forget to make this change, an=
d you will only discover it when that particular line of code is executed a=
nd fails.
To improve this situation, a minimal class is now generated for each pro=
xy type. The purpose of this class is to supply checkedCast
an=
d uncheckedCast
static methods:
class Demo_HelloPrx { public static function checkedCast($proxy, $facetOrCtx=3Dnull, $ctx=3Dn= ull); public static function uncheckedCast($proxy, $facet=3Dnull); }
Now your application can downcast a proxy as follows:
$hello =3D Demo_HelloPrx::checkedCast($proxy);
You can continue to use ice_checkedCast
and ice_unche=
ckedCast
but we recommend migrating your application to the new meth=
ods.
This section describes additional changes to the Ice API in this release= :
$ICE
is no longer defined. An applicat=
ion must now initialize its own communicator as described above.Removed the following communicator methods:
$ICE->setProperty() $ICE->getProperty()
The equivalent methods are:
$communicator->getProperties()->setProperty() $communicator->getProperties()->getProperty()
Removed the following global functions:
Ice_stringToIdentity() Ice_identityToString()
The equivalent methods are:
$communicator->stringToIdentity() $communicator->identityToString()
These functions have also been removed:
Ice_loadProfile() Ice_loadProfileWithArgs() Ice_dumpProfile()
Refer to PHP configuration for more information.
A thread pool sup=
ports the ability to automatically grow and shrink as the demand for thread=
s changes, within the limits set by the thread pool's configuration. In pri=
or releases, the rate at which a thread pool shrinks was not configurable, =
but Ice 3.4.0 introduces the Th=
readIdleTime
property to allow you to specify how long a thread =
pool thread must remain idle before it terminates to conserve resources.
With the addition of the ConnectionInfo
classes in this rel=
ease, the IceSSL::ConnectionInfo
structure has changed from a =
native type to a Slice class. This change has several implications for exis=
ting applications:
IceSSL::ConnectionInfo
cannot provide th=
e X509 certificate chain in its native form, therefore the chain is provide=
d as a sequence of strings representing the encoded form of each certificat=
e. You can use language-specific facilities to convert these strings back t=
o certificate objects.IceSSL::=
ConnectionInfo
called IceSSL::NativeConnectionInfo
. Thi=
s class provides the certificate chain as certificate objects.CertificateVerifier
interface now uses NativeCon=
nectionInfo
instead of ConnectionInfo
. If your applicat=
ion configures a custom certificate verifier, you will need to modify your =
implementation accordingly.In C++, also note that NativeConnectionInfo
is now manag=
ed by a smart pointer, therefore the signature of the certificate verifier =
method becomes the following:
virtual bool verify(const IceSSL::NativeConnectionI= nfoPtr&) =3D 0;
The getConnectionInfo
helper function has been removed =
because its functionality has been replaced by the Connection::getInf=
o
operation. For example, in prior releases a C++ application would d=
o the following:
Ice::ConnectionPtr con =3D ... IceSSL::ConnectionInfo info =3D IceSSL::getConnectionInfo(con);
Now the application should do this:
Ice::ConnectionPtr con =3D ... IceSSL::ConnectionInfoPtr info =3D IceSSL::ConnectionInfoPtr::dynamicCast(c= on->getInfo());
Alternatively, the application can downcast to the native class:= p>
Ice::ConnectionPtr con =3D ... IceSSL::NativeConnectionInfoPtr info =3D IceSSL::NativeConnectionInfoPtr::dynamicCast(con->getInfo());
No changes were made to the database schema for IceStorm or IceGrid in t= his release. However, you still need to update your databases as described = below.
No changes were made that would affect the content of your Freeze databases. However, we upgraded the version= of Berkeley DB, therefore when upgrading to Ice 3.4 you must also upgrade = your database to the Berkeley DB 4.8 format. The only change that affects F= reeze is the format of Berkeley DB's log file.
The instructions below assume that the database environment to be upgrad=
ed resides in a directory named db
in the current working dire=
ctory. For a more detailed discussion of database migration, please refer t=
o the Berkeley DB Upgrade =
Process.
To migrate your database:
Make a backup copy of the database environment:
> cp -r db backup.db (Unix) > xcopy /E db backup.db (Windows)
Locate the correct version of the Berkeley DB recovery tool (usually=
named db_recover
). It is essential that you use the db_=
recover
executable that matches the Berkeley DB version of your exis=
ting Ice release. For Ice 3.3, use db_recover
from Berkeley DB=
4.6. You can verify the version of your db_recover
tool by ru=
nning it with the -V
option:
> db_recover -V
Use the db_recover tool to run recovery on the database environment:=
> db_recover -h db
Force a checkpoint using the db_checkpoint
utility. Not=
e that you must use the db_checkpoint
utility from Berkeley DB =
4.8 when performing this step.
> db_checkpoint -1 -h db
This section describes APIs that were deprecated in a previous release a= nd have now been removed. Your application may no longer compile successful= ly if it relies on one of these APIs.
The following APIs were removed in Ice 3.4.0:
Glacier2.AddUserToAllowCategories
Glacier2.Filter.Category.AcceptUser=
code>
instead.Glacier2.AllowCategories
Glacier2.Filter.Category.Accept
instead.Ice.UseEventLog
I=
ce::Service
) always use the Windows event log by default.Communicator::setDefaultContext
Communicator::getDefaultContext
ObjectPrx:ice_defaultContext
nonmutating
keywordFreeze.UseNonmutating
nonmutating keyword.
Ice::NegativeSizeException
UnmarshalOutOfBoundsException
or slice2docbook
Ice::AMD_Array_Object_ice_invoke
ice_response
in the AMD_Object_ice=
_invoke
class makes AMD_Array_Object_ice_invoke
obsolet=
e.This section discusses APIs and components that are now deprecated. Thes= e APIs will be removed in a future Ice release, therefore we encourage you = to update your applications and eliminate the use of these APIs as soon as = possible.
The following APIs were deprecated in Ice 3.4.0:
Glacier2.AddSSLContext
Glacier2.AddConnectionContext
.Standard platform methods should be used instead of the following:= p>
Ice.Object.ice_hash() // Use hashCode Ice.ObjectPrx.ice_getHash() // Use hashCode Ice.ObjectPrx.ice_toString() // Use toString
In Java, use hashCode
and toString
. In C=
#, use GetHashCode
and ToString
. In Ruby, use ice_getHash
.
Ice.Util.generateUUID()
java.util.UUID.randomUUID().toString()
. In C# use=
System.Guid.NewGuid.ToString()
.=20