Remove unused messages

Fix for OPENDJ-58 : cn=schema attribute store twice in 99-user.ldif schema file. Prevent replication from adding cn and other schema attributes to the extra-attribute that are added to the schema entry written to the LDIF file. Fix also some messages (and translations)

Make sure completed tasks retention limit is respected upon server restarts.

Minimize Historical Data (dsreplication/client side). The purge historical can be executed on the local server even when it is stopped. This is matches the functionality provided by utilities such import-ldif, backup, etc.

Fix for defect 4058: Schema backend backup/restore inefficiencies.

issue# 4120:Provide an implementation for enumeration syntax

issue 4102: Provide implementation for substitution syntax

- fix regression introduced by the fix for issue 3773 in revision 5243. - fix task scheduler completed tasks cleanup. - fix task scheduler retention time calculation. - fix task scheduler to no longer throw alerts if recurring task is not found when scheduling next iteration and remove related alert messages. - fix recurring task unit test to be less prone to timing issues by scheduling test tasks way ahead.

- move notice messages where they belong.

- reject tasks with missing dependencies.

Fix issue 3832 - Provide ergonomics style settings for common server properties

Fix for issue#3391:Custom DIT Structure Rules are not added in 99-user.ldif but in 03-uddiv3.ldif

- [Issue 3674] Task backend should support backup and export

- [Issue 274] Recurring Tasks

Fix for issues 3509, 3510, 3538, 3539 and 3542 (typos in messages catalog)

Fix 3534: Provide native Solaris packages (fix also 3533: upgrade fails starting server adding entry ds-cfg-key-id)

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

- [Issue 2232] Log a message when taking the backend offline: Log an informational message upon JEB finalization.

Fix for Issue #1961 (reviewed by Josu) * Remove instances of "Specifies the..." * Remove instances of "Indicates that..." * Reword instances of "Specifies to..." (which doesn't really make sense anyway) * Change instances of "This utility may be used..." to "This utility can be used..." as discussed in a previous issue * Change some erroneous instances of "may" to "might" or "can". This might sound like a pointless change but it has implications for localization - "may" is generally ambiguous.

issue 466 (partial) remove redundant server property BACKUP_PROPERTY_CIPHER_ALGORITHM The cipher algorithm used is encoded in the backup data prologue.

Update the backend API to include new isIndexed methods that can be used to determine whether a given attribute is indexed in a specified manner, or that can be used to determine whether a specified filter is indexed. At present, all backends except the JE backend and the replication backend are considered always indexed for all operations. The JE backend is only considered indexed based on its index configuration. The replication backend is never considered indexed. Update the following components to make use of this new isIndexed capability: - The DSEE-compatible access control handler will now log a warning message at startup if it detects that there is no presence index for the aci attribute, which can make startup take a long time on a big database. - The group manager will now log a warning message at startup if any of the group implementation filters are unindexed, which can make startup take a long time on a big database. - The referential integrity plugin now requires that all of the attributes for which referential integrity is to be maintained must be configured with equality indexes. - The unique attribute plugin now requires that all of the attributes for which uniqueness is to be enforced must be configured with equality indexes. This commit also updates the LDIF backend so that it is possible to indicate via configuration whether its base DNs should be registered as public or private base DNs. The LDIF backend used as the admin root has been updated so that it is considered a private backend. The replication backend has also been updated so that it is considered a private backend.

Implement Get Symmetric Key Extended Operation for crypto manager symmetric key distribution.

Add support for an LDIF backend. Entries in this backend will be held in memory, and all read operations will be served from memory, but the underlying data will be stored in an LDIF file on disk and any write operation will cause that LDIF file to be updated. This backend supports all major operations, including moving/renaming non-leaf entries with the modify DN operation, and also supports the subtree delete control and LDIF import and export operations. Backup and restore operations are not currently supported.

Handle the base DN of the trust store backend properly, taking it from the configuration entry instead of hard-wiring it.

Enable replication session authentication. - Adds a thread to synchronize the server instance certificates from the admin data branch to the local trust store backend. - Replaces the blind trust managers in the replication session with trust managers that use the local trust store. Note that replication must be configured using either setup-gui or the dsreplication command.

Implement support for delete and modify operations in the task backend as follows: - Pending tasks and completed tasks may be deleted. Running tasks may not be deleted. - Any attributes in pending tasks may be modified. - Only the task state in running tasks may be modified, and only to cancel the task. - No attributes of a completed task may be modified. OpenDS Issue Number: 2181

throw exceptions for backend operations when initialization fails

Changes for replication security issues 511, 512, 608. There is a new backend representing the certificate trust store, which allows the setup code to query and populate the trust store over protocol. However, we are using blind trust until that piece of the setup code is ready. The encryption settings are currently global to the server instance in a new crypto manager config entry. Authentication will always be performed so the main setting is whether to use encryption or not. In the future (post 1.0) we will need to allow encryption to be configured on or off depending on which replication server we are connecting to but we need some discussion on the best way to specify that in configuration.

New tests for messaging plumbing to replace old ones: - Format string cannot end with '.' (QUICKSETUP and ADMIN_TOOLS excluded) - Categories cannot span multiple files and files cannot define messages in multiple categories Addional methods for MessageDescriptorRegistry to access descriptors by defining class Corrected some offending format strings Corrected message property file boilerplates and help comments

Correct a number of spelling errors identified in the message files.

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.