-
Notifications
You must be signed in to change notification settings - Fork 6
/
UPGRADE2
158 lines (135 loc) · 8.82 KB
/
UPGRADE2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
Ganymede Logo
Ganymede 2.0 Upgrade Guide
Release 2.0 - April 1, 2008
This document discusses what's new in Ganymede 2.0, and what you'll need
to think about if you are upgrading from an installation of Ganymede 1.0.
By Jonathan Abbey
Welcome to Ganymede 2.0
While Ganymede 2.0 is more similar to Ganymede 1.0 than it is different,
the 2.0 series is the product of nearly ten years of development and
refinement, and essentially every facet of the product has been refined,
polished to a high shine, or at least tweaked, relative to the Ganymede
1.0 releases.
The major functional differences between the Ganymede 1.0 series and
Ganymede 2.0 are as follows:
* The entire source code tree has been refactored for clarity, and the
build system is now based on Ant.
* Ganymede now requires Java 6 or later, and can be built and
deployed properly with Sun's 5.x, 6.x, or later.
* All RMI client/server communications are now SSL encrypted, and any
RMI calls that were previously made from the server to the client have
been reversed so that clients will work properly on systems with local
firewalls. In addition, Ganymede no longer requires an external RMI
registry process.
* Ganymede 2.0 supports a new incremental XML build system that can
enqueue directory changes for transmission to external directory
services that support discrete change commands.
* Ganymede 2.0 has an SQL-like textual query language which is available
for programming in the Ganymede framework, as well as for doing direct
queries with the xmlclient.
* The Ganymede client, server, and admin console are internationalized,
and all user-facing message strings have been pulled into
language-specific resource files to support easy translation. A German
language translation is included.
* Scalability and performance is now very significantly improved,
particularly in XML processing. Overall memory usage of the server has
been reduced by at least 15%.
* A number of changes have been made to the Ganymede data model and APIs
to ensure correct and predictable behavior, including a new
requirement that all objects have guaranteed unique labels. There were
some minor changes to the XML schema used for data dumping and
loading. It is now possible to group object fields in custom tabs to
reduce clutter in the client.
* A significant number of fit, polish, and reliability improvements have
been made to every part of the Ganymede product. The client and admin
console now use the Java 1.4 Preferences API to remember window
position and other miscellaneous details. The Ganymede client can now
receive and transmit Ganymede XML data.
* The Ganymede server will now generate an 'externalerror' system event
if an external build returns a non-zero result code. You can take
advantage of this feature to properly monitor your builds.
* Ganymede now knows how to generate hash text for passwords in
OpenLDAP/Netscape's Salted SHA password hash format, as well as Ulrich
Drepper's Unix Crypt with Sha algorithm.
* Ganymede is now a U.S. registered trademark of The University of Texas
at Austin.
For a comprehensive list of changes in the 2.0 release, please see the
CHANGES file. You should be especially sure to consult this file if you
have any previous programming experience with the Ganymede framework, as a
good number of minor changes have accumulated over the last few years.
Schema Changes
* A number of fields have been renamed since Ganymede 1.0. These renames
should be handled automatically for you if you try to load a Ganymede
1.0 series database file with a Ganymede 2.0 server, but if you are
doing XML loading, you may need to be aware of the following name
changes:
+--------------------------------------------------------------------+
| Object | Field | Field Type | Old Field | New Field Name |
| | Number | | Name | |
|--------+--------+------------+------------+------------------------|
| System | 103 | boolean | Event Mail | Send Mail |
| Event | | | | |
|--------+--------+------------+------------+------------------------|
| System | 106 | boolean | Cc Owner | Cc Owners |
| Event | | | Groups | |
|--------+--------+------------+------------+------------------------|
| Owner | 105 | string | Mail List | External Mail List |
| Group | | | | |
|--------+--------+------------+------------+------------------------|
| | | permission | Owned | Objects Owned Access |
| Role | 101 | matrix | Object | Bits |
| | | | Bits | |
|--------+--------+------------+------------+------------------------|
| Role | 103 | permission | Default | Default Access Bits |
| | | matrix | Bits | |
+--------------------------------------------------------------------+
* If you have a Ganymede 1.x schema that does not force unique labels on
all object types, Ganymede 2.0 will give you a warning when you go to
load your old ganymede.db file. If you bring up the Ganymede schema
editor or use the xmlclient to tweak the schema, no changes will
accepted to your schema until you resolve the unique label issue.
* The Objects Owned Invid field in the Owner Group object has been
removed. This change makes it possible for multiple administrators to
create objects in a common Owner Group without experiencing lock-out.
This will again be handled for you automatically if you load a
Ganymede 1.0 db file, but if you are working with XML, you may need be
aware of this, particularly when loading Permission Matrix dumps.
* If you have custom plugin classes written against Ganymede 1.0, you
will absolutely need to make some changes in order to get your classes
working properly in Ganymede 2.0.
The most elementary change is that classes in the Ganymede server have
been shuffled around to different packages for clarity in the source
tree and build process. You will need to make sure you use
arlut.csd.ganymede.common for classes that are used on the server and
on the client, arlut.csd.ganymede.rmi for RMI interfaces, and
arlut.csd.ganymede.server for the classes that uniquely comprise the
Ganymede server.
A wide variety of methods in several classes in the Ganymede server
now throw an arlut.csd.ganymede.common.GanyPermissionException when
permission problems are encountered. This is a checked exception, so
you may need to modify your code to handle this exception
intelligently.
The DBEditObject 'deleting' boolean has been made private. You'll need
to use the DBEditObject.isDeleting() method to test the deleting
status of an editable object.
Otherwise, I believe the classes you'll use in writing your own plugin
subclasses for DBEditObject and GanymedeBuilder shouldn't need a great
deal of changes. Most of the other method changes have been done in a
backwards compatible fashion.
If you're writing a new set of plugin classes, you may find that there
are some more convenient methods to use when writing your custom logic
than were available in the 1.x time frame. For instance, many methods
that deal with fields allow you to look up or address fields by their
display name, rather than having to use numeric codes. Be aware that
if you use the name-based methods, you will make it difficult for
yourself if you want to produce a version of your schema kit in other
languages, however.
* Vector fields can no longer hold duplicates. This was implicit in some
of the code before, it is now explicit. If you attempt to load an old
ganymede.db file that includes duplicate values in a Vector field, the
system will allow the duplication, and this can surprise some code.
So, beware. When in doubt, use xmlclient in your Ganymede 1.x
installation to dump your data to disk, examine for duplicates, and
reload into your 2.x installation using the xmlclient.
--------------------------------------------------------------------------
Jonathan Abbey