All Downloads are FREE. Search and download functionalities are using the official Maven repository.

org.jscsi.parser.datasegment.OperationalTextKey Maven / Gradle / Ivy

The newest version!
/**
 * Copyright (c) 2012, University of Konstanz, Distributed Systems Group All rights reserved.
 * 
 * Redistribution and use in source and binary forms, with or without modification, are permitted provided that the
 * following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of
 * conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice,
 * this list of conditions and the following disclaimer in the documentation and/or other materials provided with the
 * distribution. * Neither the name of the University of Konstanz nor the names of its contributors may be used to
 * endorse or promote products derived from this software without specific prior written permission.
 * 
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL  BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
 * OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
 * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
 * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
package org.jscsi.parser.datasegment;


import java.util.HashMap;
import java.util.Map;


/**
 * This enumeration defines all valid operational text keys, which are defined in the iSCSI STandard (RFC 3720).
 */
public enum OperationalTextKey {
    /**
     * Use: During Login - Security Negotiation Senders: Initiator and Target Scope: connection AuthMethod =
     * <list-of-values> The main item of security negotiation is the authentication method (AuthMethod). The
     * authentication methods that can be used (appear in the list-of-values) are either those listed in the following
     * table or are vendor-unique methods:
     * 

*

* * * * * * * * * * * * * * * * * * * * * * * * * * * * *
NameDescription
KRB5Kerberos V5 - defined in [RFC1510]
SPKM1Simple Public-Key GSS-API Mechanism defined in [RFC2025]
SPKM2Simple Public-Key GSS-API Mechanism defined in [RFC2025]
SRPSecure Remote Password defined in [RFC2945]
CHAPChallenge Handshake Authentication Protocol defined in [RFC1994]
NoneNo authentication
*
* The AuthMethod selection is followed by an "authentication exchange" specific to the authentication method * selected. The authentication method proposal may be made by either the initiator or the target. However the * initiator MUST make the first step specific to the selected authentication method as soon as it is selected. It * follows that if the target makes the authentication method proposal the initiator sends the first keys(s) of the * exchange together with its authentication method selection. The authentication exchange authenticates the * initiator to the target, and optionally, the target to the initiator. Authentication is OPTIONAL to use but MUST * be supported by the target and initiator. The initiator and target MUST implement CHAP. All other authentication * methods are OPTIONAL. Private or public extension algorithms MAY also be negotiated for authentication methods. * Whenever a private or public extension algorithm is part of the default offer (the offer made in absence of * explicit administrative action) the implementer MUST ensure that CHAP is listed as an alternative in the default * offer and "None" is not part of the default offer. Extension authentication methods MUST be named using one of * the following two formats: *
    *
  1. Z-reversed.vendor.dns_name.do_something=
  2. *
  3. Z<#><IANA-registered-string>=
  4. *
* Authentication methods named using the Z- format are used as private extensions. Authentication methods named * using the Z# format are used as public extensions that must be registered with IANA and MUST be described by an * informational RFC. For all of the public or private extension authentication methods, the method specific keys * MUST conform to the format specified in Section 5.1 Text Format for standard-label. To identify the vendor for * private extension authentication methods, we suggest you use the reversed DNS-name as a prefix to the proper * digest names. The part of digest-name following Z- and Z# MUST conform to the format for standard-label specified * in Section 5.1 Text Format. Support for public or private extension authentication methods is OPTIONAL. The * following subsections define the specific exchanges for each of the standardized authentication methods. As * mentioned earlier the first step is always done by the initiator. */ AUTH_METHOD("AuthMethod"), /** * Use: IO
* Senders: Initiator and Target
* Scope: CO *

* HeaderDigest = <list-of-values>
* DataDigest = <list-of-values> *

* Default is None for both HeaderDigest and DataDigest. *

* Digests enable the checking of end-to-end, non-cryptographic data integrity beyond the integrity checks provided * by the link layers and the covering of the whole communication path including all elements that may change the * network level PDUs such as routers, switches, and proxies.
* The following table lists cyclic integrity checksums that can be negotiated for the digests and that MUST be * implemented by every iSCSI initiator and target. These digest options only have error detection significance. *

*

* * * * * * * * * * * * * * *
NameDescriptionGenerator
CRC32CDigest32 bit CRC0x11edc6f41
Noneno digest
*
* The generator polynomial for this digest is given in hex-notation (e.g., 0x3b stands for 0011 1011 and the * polynomial is x**5+X**4+x**3+x+1). *

* When the Initiator and Target agree on a digest, this digest MUST be used for every PDU in Full Feature Phase.
* Padding bytes, when present in a segment covered by a CRC, SHOULD be set to 0 and are included in the CRC.
* The CRC MUST be calculated by a method that produces the same results as the following process:
*

    *
  • The PDU bits are considered as the coefficients of a polynomial M(x) of degree n-1; bit 7 of the lowest * numbered byte is considered the most significant bit (x^n-1), followed by bit 6 of the lowest numbered byte * through bit 0 of the highest numbered byte (x^0).
  • *
  • The most significant 32 bits are complemented.
  • *
  • The polynomial is multiplied by x^32 then divided by G(x). The generator polynomial produces a remainder R(x) * of degree <= 31.
  • *
  • The coefficients of R(x) are considered a 32 bit sequence.
  • *
  • The bit sequence is complemented and the result is the CRC.
  • *
  • The CRC bits are mapped into the digest word. The x^31 coefficient in bit 7 of the lowest numbered byte of * the digest continuing through to the byte up to the x^24 coefficient in bit 0 of the lowest numbered byte, * continuing with the x^23 coefficient in bit 7 of next byte through x^0 in bit 0 of the highest numbered byte.
  • *
  • Computing the CRC over any segment (data or header) extended to include the CRC built using the generator * 0x11edc6f41 will always get the value 0x1c2d19ed as its final remainder (R(x)). This value is given here in its * polynomial form (i.e., not mapped as the digest word).
  • *
* For a discussion about selection criteria for the CRC, see [RFC3385]. For a detailed analysis of the iSCSI * polynomial, see [Castagnoli93].
* Private or public extension algorithms MAY also be negotiated for digests. Whenever a private or public digest * extension algorithm is part of the default offer (the offer made in absence of explicit administrative action) * the implementer MUST ensure that CRC32CDigest is listed as an alternative in the default offer and "None" is not * part of the default offer.
* Extension digest algorithms MUST be named using one of the following two formats:
*
    *
  1. Y-reversed.vendor.dns_name.do_something=
  2. *
  3. Y<#><IANA-registered-string>=
  4. *
* Digests named using the Y- format are used for private purposes (unregistered). Digests named using the Y# format * (public extension) must be registered with IANA and MUST be described by an informational RFC.
* For private extension digests, to identify the vendor, we suggest you use the reversed DNS-name as a prefix to * the proper digest names.
* The part of digest-name following Y- and Y# MUST conform to the format for standard-label specified in Section * 5.1 Text Format. Support for public or private extension digests is OPTIONAL. */ HEADER_DIGEST("HeaderDigest"), /** * See for the details in the HEADER_DIGEST documentation above. */ DATA_DIGEST("DataDigest"), /** * Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery *

* MaxConnections=<numerical-value-from-1-to-65535> *

* Default is 1.
* Result function is Minimum. *

* Initiator and target negotiate the maximum number of connections requested/acceptable. */ MAX_CONNECTIONS("MaxConnections"), /** * Use: FFPO
* Senders: Initiator
* Scope: SW *

* For a complete description, see Appendix D. - SendTargets Operation -. */ SEND_TARGETS("SendTargets"), /** * Use: IO by initiator, FFPO by target - only as response to a SendTargets, Declarative, Any-Stage
* Senders: Initiator and Target
* Scope: SW *

* TargetName=<iSCSI-name-value> *

* Examples:
* TargetName=iqn.1993-11.com.disk-vendor:diskarrays.sn.45678
* TargetName=eui.020000023B040506 *

* The initiator of the TCP connection MUST provide this key to the remote endpoint in the first login request if * the initiator is not establishing a discovery session. The iSCSI Target Name specifies the worldwide unique name * of the target.
* The TargetName key may also be returned by the "SendTargets" text request (which is its only use when issued by a * target). TargetName MUST not be redeclared within the login phase. */ TARGET_NAME("TargetName"), /** * Use: IO, Declarative, Any-Stage
* Senders: Initiator
* Scope: SW *

* InitiatorName=<iSCSI-name-value> *

* Examples:
* InitiatorName=iqn.1992-04.com.os-vendor.plan9:cdrom.12345
* InitiatorName=iqn.2001-02.com.ssp.users:customer235.host90 *

* The initiator of the TCP connection MUST provide this key to the remote endpoint at the first Login of the Login * Phase for every connection. The InitiatorName key enables the initiator to identify itself to the remote * endpoint.
* InitiatorName MUST not be redeclared within the login phase. */ INITIATOR_NAME("InitiatorName"), /** * Use: ALL, Declarative, Any-Stage
* Senders: Target
* Scope: SW
* TargetAlias=<iSCSI-local-name-value> *

* Examples: TargetAlias=Bob-s Disk
* TargetAlias=Database Server 1 Log Disk
* TargetAlias=Web Server 3 Disk 20 *

* If a target has been configured with a human-readable name or description, this name SHOULD be communicated to * the initiator during a Login Response PDU if SessionType=Normal (see Section 12.21 SessionType). This string is * not used as an identifier, nor is it meant to be used for authentication or authorization decisions. It can be * displayed by the initiator’s user interface in a list of targets to which it is connected. */ TARGET_ALIAS("TargetAlias"), /** * Use: ALL, Declarative, Any-Stage
* Senders: Initiator
* Scope: SW *

* InitiatorAlias=<iSCSI-local-name-value> *

* Examples:
* InitiatorAlias=Web Server 4
* InitiatorAlias=spyalley.nsa.gov
* InitiatorAlias=Exchange Server *

* If an initiator has been configured with a human-readable name or description, it SHOULD be communicated to the * target during a Login Request PDU. If not, the host name can be used instead. This string is not used as an * identifier, nor is meant to be used for authentication or authorization decisions. It can be displayed by the * target's user interface in a list of initiators to which it is connected. */ INITIATOR_ALIAS("InitiatorAlias"), /** * Use: ALL, Declarative, Any-Stage
* Senders: Target
* Scope: SW
* TargetAddress=domainname[:port][,portal-group-tag] *

* The domainname can be specified as either a DNS host name, a dotted-decimal IPv4 address, or a bracketed IPv6 * address as specified in [RFC2732].
*
* If the TCP port is not specified, it is assumed to be the IANA-assigned default port for iSCSI (see Section 13 * IANA Considerations).
* If the TargetAddress is returned as the result of a redirect status in a login response, the comma and portal * group tag MUST be omitted. If the TargetAddress is returned within a SendTargets response, the portal group tag * MUST be included. *

* Examples:
* TargetAddress=10.0.0.1:5003,1
* TargetAddress=[1080:0:0:0:8:800:200C:417A],65
* TargetAddress=[1080::8:800:200C:417A]:5003,1
* TargetAddress=computingcenter.example.com,23 *

* Use of the portal-group-tag is described in Appendix D. - SendTargets Operation -. The formats for the port and * portal-group-tag are the same as the one specified in Section 12.9 TargetPortalGroupTag. */ TARGET_ADDRESS("TargetAddress"), /** * Use: IO by target, Declarative, Any-Stage
* Senders: Target
* Scope: SW *

* TargetPortalGroupTag=<16-bit-binary-value> *

* Examples:
* TargetPortalGroupTag=1 *

* The target portal group tag is a 16-bit binary-value that uniquely identifies a portal group within an iSCSI * target node. This key carries the value of the tag of the portal group that is servicing the Login request. The * iSCSI target returns this key to the initiator in the Login Response PDU to the first Login Request PDU that has * the C bit set to 0 when TargetName is given by the initiator.
* For the complete usage expectations of this key see Section 5.3 Login Phase. */ TARGET_PORTAL_GROUP_TAG("TargetPortalGroupTag"), /** * Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery *

* InitialR2T=<boolean-value> *

* Examples:
* I->InitialR2T=No
* T->InitialR2T=No *

* Default is Yes.
* Result function is OR. *

* The InitialR2T key is used to turn off the default use of R2T for unidirectional and the output part of * bidirectional commands, thus allowing an initiator to start sending data to a target as if it has received an * initial R2T with Buffer Offset=Immediate Data Length and Desired Data Transfer Length=(min(FirstBurstLength, * Expected Data Transfer Length) - Received Immediate Data Length).
* The default action is that R2T is required, unless both the initiator and the target send this key-pair attribute * specifying InitialR2T=No. Only the first outgoing data burst (immediate data and/or separate PDUs) can be sent * unsolicited (i.e., not requiring an explicit R2T). */ INITIAL_R2T("InitialR2T"), /** * Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery *

* ImmediateData=<boolean-value> *

* Default is Yes.
* Result function is AND. *

* The initiator and target negotiate support for immediate data. To turn immediate data off, the initiator or * target must state its desire to do so. ImmediateData can be turned on if both the initiator and target have * ImmediateData=Yes.
* If ImmediateData is set to Yes and InitialR2T is set to Yes (default), then only immediate data are accepted in * the first burst. If ImmediateData is set to No and InitialR2T is set to Yes, then the initiator MUST NOT send * unsolicited data and the target MUST reject unsolicited data with the corresponding response code.
* If ImmediateData is set to No and InitialR2T is set to No, then the initiator MUST NOT send unsolicited immediate * data, but MAY send one unsolicited burst of Data-Out PDUs.
* If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate * data and/or one unsolicited burst of Data-Out PDUs. *

* The following table is a summary of unsolicited data options:
*

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
InitialR2TImmediateDataUnsolicited Data Out PDUsImmediate Data
NoNoYesNo
NoYesYesYes
YesNoNoNo
YesYesNoYes
*/ IMMEDIATE_DATA("ImmediateData"), /** * Use: ALL, Declarative
* Senders: Initiator and Target *

* Scope: CO *

* MaxRecvDataSegmentLength=<numerical-value-512-to-(2**24-1)>
*

* Default is 8192 bytes. *

* The initiator or target declares the maximum data segment length in bytes it can receive in an iSCSI PDU.
* The transmitter (initiator or target) is required to send PDUs with a data segment that does not exceed * MaxRecvDataSegmentLength of the receiver.
* A target receiver is additionally limited by MaxBurstLength for solicited data and FirstBurstLength for * unsolicited data. An initiator MUST NOT send solicited PDUs exceeding MaxBurstLength nor unsolicited PDUs * exceeding FirstBurstLength (or FirstBurstLength-Immediate Data Length if immediate data were sent). */ MAX_RECV_DATA_SEGMENT_LENGTH("MaxRecvDataSegmentLength"), /** * Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery *

* MaxBurstLength=<numerical-value-512-to-(2**24-1)> *

* Default is 262144 (256 Kbytes).
* Result function is Minimum. *

* The initiator and target negotiate maximum SCSI data payload in bytes in a Data-In or a solicited Data-Out iSCSI * sequence. A sequence consists of one or more consecutive Data-In or Data-Out PDUs that end with a Data-In or * Data-Out PDU with the F bit set to one. */ MAX_BURST_LENGTH("MaxBurstLength"), /** * Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery
* Irrelevant when: ( InitialR2T=Yes and ImmediateData=No ) *

* FirstBurstLength=<numerical-value-512-to-(2**24-1)> *

* Default is 65536 (64 Kbytes).
* Result function is Minimum. *

* The initiator and target negotiate the maximum amount in bytes of unsolicited data an iSCSI initiator may send to * the target during the execution of a single SCSI command. This covers the immediate data (if any) and the * sequence of unsolicited Data-Out PDUs (if any) that follow the command.
* FirstBurstLength MUST NOT exceed MaxBurstLength. */ FIRST_BURST_LENGTH("FirstBurstLength"), /** * Use: LO
* Senders: Initiator and Target
* Scope: SW *

* DefaultTime2Wait=<numerical-value-0-to-3600> *

* Default is 2.
* Result function is Maximum. *

* The initiator and target negotiate the minimum time, in seconds, to wait before attempting an explicit/implicit * logout or an active task reassignment after an unexpected connection termination or a connection reset.
* A value of 0 indicates that logout or active task reassignment can be attempted immediately. */ DEFAULT_TIME_2_WAIT("DefaultTime2Wait"), /** * Use: LO
* Senders: Initiator and Target
* Scope: SW *

* DefaultTime2Retain=<numerical-value-0-to-3600> *

* Default is 20. Result function is Minimum. *

* The initiator and target negotiate the maximum time, in seconds after an initial wait (Time2Wait), before which * an active task reassignment is still possible after an unexpected connection termination or a connection reset.
* This value is also the session state timeout if the connection in question is the last LOGGED_IN connection in * the session. A value of 0 indicates that connection/task state is immediately discarded by the target. */ DEFAULT_TIME_2_RETAIN("DefaultTime2Retain"), /** * Use: LO
* Senders: Initiator and Target
* Scope: SW *

* MaxOutstandingR2T=<numerical-value-from-1-to-65535> *

* Irrelevant when: SessionType=Discovery
* Default is 1.
* Result function is Minimum. *

* Initiator and target negotiate the maximum number of outstanding R2Ts per task, excluding any implied initial R2T * that might be part of that task. An R2T is considered outstanding until the last data PDU (with the * F bit set to 1) is transferred, or a sequence reception timeout (Section 6.1.4.1 * Recovery Within-command) is encountered for that data sequence. */ MAX_OUTSTANDING_R2T("MaxOutstandingR2T"), /** * Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery *

* DataPDUInOrder=<boolean-value> *

* Default is Yes.
* Result function is OR. *

* No is used by iSCSI to indicate that the data PDUs within sequences can be in any order. Yes is used to indicate * that data PDUs within sequences have to be at continuously increasing addresses and overlays are forbidden. */ DATA_PDU_IN_ORDER("DataPDUInOrder"), /** * Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery *

* DataSequenceInOrder=<boolean-value> *

* Default is Yes.
* Result function is OR. *

* A Data Sequence is a sequence of Data-In or Data-Out PDUs that end with a Data-In or Data-Out PDU with the F bit * set to one. A Data-Out sequence is sent either unsolicited or in response to an R2T. Sequences cover an * offset-range.
* If DataSequenceInOrder is set to No, Data PDU sequences may be transferred in any order.
* If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing * sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data * sequence).
* If DataSequenceInOrder is set to Yes, a target may retry at most the last R2T, and an initiator may at most * request retransmission for the last read data sequence. For this reason, if ErrorRecoveryLevel is not * 0 and DataSequenceInOrder is set to Yes then MaxOustandingR2T MUST be set to 1. */ DATA_SEQUENCE_IN_ORDER("DataSequenceInOrder"), /** * Use: LO *

* Senders: Initiator and Target *

* Scope: SW *

*

* ErrorRecoveryLevel=<numerical-value-0-to-2> *

* Default is 0. *

* Result function is Minimum. *

* The initiator and target negotiate the recovery level supported. Recovery levels represent a combination of * recovery capabilities. Each recovery level includes all the capabilities of the lower recovery levels and adds * some new ones to them. *

* In the description of recovery mechanisms, certain recovery classes are specified. Section 6.1.5 Error Recovery * Hierarchy describes the mapping between the classes and the levels. */ ERROR_RECOVERY_LEVEL("ErrorRecoveryLevel"), /** * Use: LO, Declarative, Any-Stage *

* Senders: Initiator *

* Scope: SW *

> * SessionType= <Discovery|Normal> *

* Default is Normal. *

* The initiator indicates the type of session it wants to create. The target can either accept it or reject it. *

* A discovery session indicates to the Target that the only purpose of this Session is discovery. The only requests * a target accepts in this type of session are a text request with a SendTargets key and a logout request with * reason "close the session". *

* The discovery session implies MaxConnections = 1 and overrides both the default and an explicit * setting. */ SESSION_TYPE("SessionType"), /** * Use: LO, Declarative, Any-Stage *

* Senders: Initiator *

* Scope: SW *

> * SessionBalancer= <RoundRobinSessionBalancer|ParallelSessionBalancer> *

* Default is RoundRobinSessionBalancer. *

* The SessionBalancer to use; *

*/ SESSION_BALANCER("SessionBalancer"), /** * OFMarker = <boolean-value> *

* IFMarker = <boolean-value> *

* Default is No. Result function is AND. *

* IFMarker is used to turn on or off the target to initiator markers on the connection. *

* Examples: *

* I->OFMarker=Yes,IFMarker=Yes *

* T->OFMarker=Yes,IFMarker=Yes *

* Results in the Marker being used in both directions while: *

* I->OFMarker=Yes,IFMarker=Yes *

* T->OFMarker=Yes,IFMarker=No *

* Results in Marker being used from the initiator to the target, but not from the target to initiator. */ IF_MARKER("IFMarker"), /** * OFMarkInt is Irrelevant when: OFMarker = No *

* IFMarkInt is Irrelevant when: IFMarker = No *

* Offering: *

* OFMarkInt=<numeric-range-from-1-to-65535>
* IFMarkInt=<numeric-range-from-1-to-65535> *

* Responding: *

* OFMarkInt=<numeric-value-from-1-to-65535>|Reject
* IFMarkInt=<numeric-value-from-1-to-65535>|Reject *

* IFMarkInt is used to set the interval for the target to initiator markers on the connection. *

* For the offering, the initiator or target indicates the minimum to maximum interval (in 4-byte words) it wants * the markers for one or both directions. In case it only wants a specific value, only a single value has to be * specified. The responder selects a value within the minimum and maximum offered or the only value offered or * indicates through the xFMarker key=value its inability to set and/or receive markers. When the interval is * unacceptable the responder answers with "Reject". Reject is resetting the marker function in the specified * direction (Output or Input) to No. *

* The interval is measured from the end of a marker to the beginning of the next marker. For example, a value of * 1024 means 1024 words (4096 bytes of iSCSI payload between markers). *

* The default is 2048. * * @see #IF_MARKER */ IF_MARK_INT("IFMarkInt"), /** * OFMarker is used to turn on or off the initiator to target markers on the connection. *

* * @see #IF_MARKER */ OF_MARKER("OFMarker"), /** * OFMarkInt is used to set the interval for the initiator to target markers on the connection. * * @see #OF_MARKER * @see #IF_MARK_INT */ OF_MARK_INT("OFMarkInt"); private final String value; private static Map mapping; static { OperationalTextKey.mapping = new HashMap(); for (OperationalTextKey s : values()) { OperationalTextKey.mapping.put(s.value, s); } } private OperationalTextKey (final String newValue) { value = newValue; } /** * Returns the value of this enumeration. * * @return The value of this enumeration. */ public final String value () { return value; } /** * Returns the constant defined for the given value. * * @param value The value to search for. * @return The constant defined for the given value. Or null, if this value is not defined * by this enumeration. */ public static final OperationalTextKey valueOfEx (final String value) { return OperationalTextKey.mapping.get(value); } // -------------------------------------------------------------------------- // -------------------------------------------------------------------------- // -------------------------------------------------------------------------- // -------------------------------------------------------------------------- }





© 2015 - 2025 Weber Informatics LLC | Privacy Policy