The commit will bring the following features : - An updated version of the underlying database. BDB JE 3.3 is now used. - Attribute API refactoring providing a better abstraction and offering improved performances. - A new GUI called the Control-Panel to replace the Status-Panel: the specifications for this GUI are available on OpenDS Wiki and contains a link to a mockup. See <https://www.opends.org/wiki/page/ControlPanelUISpecification>. - Some changes in the replication protocol to implement "Assured Replication Mode". The specifications are on OpenDS Wiki at <https://www.opends.org/wiki/page/AssuredMode> and section 7 described some of the replication changes required to support this. Assured Replication is not finished, but the main replication protocol changes to support it are done. As explained by Gilles on an email on the Dev mailing list (http://markmail.org/message/46rgo3meq3vriy4a), with these changes the newer versions of OpenDS may not be able to replicate with OpenDS 1.0 instances. - Support for Service Tags on the platforms where the functionality is available and enabled. Specifications are published at <https://www.opends.org/wiki/page/OpenDSServiceTagEnabled>. For more information on Service Tags see <http://wikis.sun.com/display/ServiceTag/Sun+Service+Tag+FAQ>. - The Admin Connector service. In order to provide agentry of the OpenDS server at any time, a new service has been added, dedicated to the administration, configuration and monitoring of the server. An overview of the Admin Connector service and it's use is available on the OpenDS wiki <https://www.opends.org/wiki/page/ManagingAdministrationTrafficToTheServer> - Updates to the various command line tools to support the Admin Connector service. - Some internal re-architecting of the server to put the foundation of future developments such as virtual directory services. The new NetworkGroups and WorkFlow internal services which have been specified in <https://www.opends.org/wiki/page/BasicOperationRoutingThroughNetworkGroup> are now implemented. - Many bug fixes... This set of changes may have an impact on current clients and deployments, however it should be possible to upgrade existing 1.0 instances. Some of the changes impacting the clients include : - Scripts using the command line tools including dsconfig will need to be updated (usually to remove some no longer required options).

Updated the copyright statement to reflect that Sun owns the full copyright on the project files.

This set of fixes mainly address the issues where the JE backend does not handle attributes with options and subtypes correctly when they are being indexed. With this fix: - All values of an indexed attribute type will be indexed correctly on modifies, adds, and deletes. - Updates to subordinate types will now update the superior type if its indexed. - Adding and deleting superior attribute types that are not allowed by any object classes (ie. name) will be correctly handled - Deleting all values from an attribute with no options will no longer delete the values from the same attribute but with options.

This commit is a step toward getting OpenDS internationalized. There are still issues to be resolved before we can declare that we are internationalized but this commit covers the bulk of changes needed at this time. In general this commit converts any string values that might potentially be shown to an end user (client or administrator) to a new class called Message. This includes exception messages, error log messages, alert and email text, labels, and CLI output. Message's main interface includes methods for rendering itself as a string in the default locale using toString() or a specified locale toString(Locale). In addition to addressing localization, this would allow us to potentially support controls allowing clients to set a preferred locale for server communication or output log messages in different languages. Message extends CharSequence so it can be used in some places where strings are currently used with not code change (e.g. writing to a buffer) as well as allowing messages to be composed of one another. In order to create localized messages, instead of adding them to the *Messages.java class, you define them in the corresponding properties files. In general the property file keys are used to derive the new messages severity, category, and ordinal. There are directives that can be used in the properties file in order to avoid doing this however. For instance all the properties files used internally include the 'global.category' directive at the top of the file that instructs the generator to make all the following message belong to a single category. So for internal messages the property value key will be as follows: [SEVERITY]_[DESCRIPTION]_[ORDINAL] See the properties files themselves for more information. Once your messages are in the properties file you can use the ant target 'generatemessages' to create create MessageDescriptor objects that are referred to in the Java code. In the code you might think of these objects as replacing the int-valued message IDs. To create messages you call MessageDescriptor.get() which replaces MessageHandler.getMessage(). It might be helpful then to try to define your messages before referring to them in your code since until you run 'generatemessages' you won't have any Java-code with with to create your message objects. In order to support non-localizable text in messages (host names, DN's, etc.) Message's can be created from String values by calling Message.raw(String). In this way it is also possible to circumvent the intention of changing the APIs to use Message objects instead of Strings which is to support writing of localizable messages. This method is currently used in the code as a crutch for areas of the code that need internationalization (tagged with a 'TODO: i18n' comment). It might also be used by 3rd party developers that don't intend to localize their products. However for internal use we should not be using this method to create Messages for text that is locale sensitive. Additionally this code includes a MessageBuilder that can be used in much the same way that a StringBuilder can be used. It has a method toMessage() that can be used to generate a message object when needed. At this time this method just converts the buffer contents to a raw, unlocalizable message so this will need to addressed in the future. Some other issues: - While all of the unit tests pass after this commit, there may be issues in the code where we have no or minimal test coverage. This includes much of the setup and GUI tools packages for which I have not done any testing but will begin after this commit. - The new message related Java sources are contained in package org.opends.messages and organized in a new module src/module modeled somewhat after the admin module: src/messages/src (non-generated Java source files) src/messages/generated (generated source files) src/messages/messages (properties files for messages) If you run the code from within your IDE you will have to mark all messages/src, messages/generated and messages as source directories. - To generated the MessageDescriptor files you invoke the 'generatemessages' target. - If you run the code from within your IDE you will probably ne - This commit would change the plugin API. Here are the changes caught by DirectoryServerPluginTestCase: doShutdown(String)->doShutdown(Message) doPostDisconnect(PostDisconnectPluginResult,ClientConnection,DisconnectReason,int,String) -> doPostDisconnect(PostDisconnectPluginResult,ClientConnection,DisconnectReason,Message); - This commit aligns the entire code-base behind the new Formatter class (printf style formattings like %s) as opposed to the older MessageFormat style (using curly braces for message arguments). This allows us to provide more type safety for message arguments. So for instance you can include a %c argument specifier in your format string and the MessageDescriptor will enforce specification of a Character as message creation time. - Not all of the config framework has not been converted to use Messages. Perhaps as some point we might have a 'message' syntax for locale-sensitive textural data. I'm sure Matt will have ideas about this. - In addition to Message, MessageDescriptor and MessageBuilder, the org.opends.server.message package includes enums for Category and Severity that replace the definitions formerly found in MessageHandler. - The interface for the ErrorLogger has been simplified to allow logging of messages using a single Message parameter. The severity and category of the message will be derived from the Message itself instead of specified as arguments when a message is logged. - I will provide more documentation about this plumbing on the Wiki shortly. - I will expand on the included tests soon.

Update all CDDL headers in source files to remove a typo.

Update files created or modified since the beginning of the year to include 2007 in their copyright notices.

Make a number of updates to schema processing, all of which fall under the umbrella of issue #1163. The individual issues addressed include: * 1139 -- Properly handle OBSOLETE flag in schema elements. The OBSOLETE flag is now recognized when processing matching rules, attribute types, object classes, name forms, DIT content rules, DIT structure rules, and matching rule uses. It essentially provides a way to "deprecate" a schema element so that existing data that makes use of them will still be treated properly, but the server will not allow newly-created elements to reference them. * 1145 -- Consider updating X-ORIGIN to reference newer RFCs. When the schema configuration files were originally written, there were a number of references to RFC 2252 and RFC 2256 that were updated in RFC 4512 and RFC 4519, among others. The X-ORIGIN extension for each element in the 00-core.ldif schema configuration file should now reference the latest specification that contains that element. * 1146 -- Consider enforcing object class inheritance restrictions. The server will now ensure that abstract classes can only inherit from other abstract classes, that auxiliary classes can only inherit from abstract classes and other auxiliary classes, and that structural classes can only inherit from abstract classes and other structural classes. Further, all structural object classes must include the "top" abstract class as the root of their inheritance chain. * 1147 -- Consider enforcing attribute type inheritance restrictions. The server will now ensure that a subordinate attribute type will have the same usage as its superior type. Further, the server will enforce that a subordinate attribute type may be collective if and only if its superior type is collective. Due to the subjective nature of the "refinement" clause for syntax inheritance, no check will be made regarding the syntax relationship between a superior and subordinate attribute type. * 1151 -- DIT content rule validation isn't handled correctly. The server will now allow attribute types to appear in an entry if they are included in the required or optional attribute type lists for a DIT content rule even if those attributes are not allowed by any of the entry's associated object classes. Further, the DIT content rule validation process will now ensure that none of the prohibited attribute types are required by the structural object class or any of the allowed auxiliary object classes. * 1158 -- Attribute syntaxes describing schema elements aren't strict enough. Previously, in most cases that one schema element referenced another element that was not defined (e.g., an object class allows an attribute type that is not defined in the server schema), the server would ignore the unresolved dependency. The server will now fail to validate schema elements that depend on other schema elements which are not defined in the server schema. Similarly, there were cases in which the server did not properly validate that an object class was of the appropriate type (e.g., for a DIT content rule, there was no check to ensure that the structural object class was actually declared structural, or that all of the allowed auxiliary objectclasses were actually declared auxiliary). The server will also fail to validate schema elements with these kinds of problems. * 1159 -- Incomplete attribute type usage constraints. The server did not properly ensure that COLLECTIVE attribute types had a usage of userApplications, and that NO-USER-MODIFICATION attribute types had an operational usage. * 1164 -- Need more complete DIT structure rule validation. The server did not properly ensure that if an entry's parent was associated with a DIT structure rule, that entry would only be valid if it was covered by a DIT structure rule which listed the parent's DIT structure rule as a superior rule. * 1165 -- Consider reduced name form and DIT structure rule checking. The server would often perform more schema validation than necessary for most types of operations. In particular, name form and DIT structure rule validation should not be required for modify operations, and DIT structure rule validation should also not be required for LDIF import operations since we cannot guarantee that the parent will be accessible.