Hi,

On 7/2/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
On 6/26/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> Oh, ok.
>
> I was also thinking about switching from Class to Enum for those types.

I like the way the current Class enumerators allow for a descriptive
toString(), which is useful during logging.  I didn't think you could
replicate that with enums.

Enum are just wrappers for classes, but with special syntaxes. Here is
an example of conversion, where you can see that we also have the
toString() method :

package org.apache.directory.server.kerberos.shared.messages.value.types;

import java.util.Arrays;

public enum TransitedEncodingType
{
   /**
    * Constant for the "null" transited encoding type.
    */
   NULL( 0 ),

   /**
    * Constant for the "Domain X500 compress" transited encoding type.
    */
   DOMAIN_X500_COMPRESS( 1 );

   /**
    * Array for building a List of VALUES.
    */
   private static final TransitedEncodingType[] values =
       { NULL, DOMAIN_X500_COMPRESS };

   /**
    * A List of all the transited encoding type constants.
    */
   public static final List VALUES = Collections.unmodifiableList(
Arrays.asList( values ) );

   /**
    * The value/code for the transited encoding type.
    */
   private final int ordinal;

   /**
    * Private constructor prevents construction outside of this class.
    */
   private TransitedEncodingType( int ordinal )
   {
       this.ordinal = ordinal;
   }

   /**
    * Returns the transited encoding type when specified by its ordinal.
    *
    * @param type
    * @return The transited encoding type.
    */
   public static TransitedEncodingType getTypeByOrdinal( int type )
   {
        switch ( type )
        {
                case 1  : return DOMAIN_X500_COMPRESS;
                default : return NULL;
        }
   }

   /**
    * Returns the number associated with this transited encoding type.
    *
    * @return The transited encoding type ordinal.
    */
   public int getOrdinal()
   {
       return ordinal;
   }

   /**
    * @see Object#toString()
    */
   public String toString()
   {
        switch ( this )
        {
                case DOMAIN_X500_COMPRESS :     return "Domain X500 compress 
(1)";
                default :                                       return "null 
(0)";
        }
   }
}



> FYI, I have started to write some encoders for simple Kerberos
> constructs (like PrincipalName, EncryptionKey,etc) and it works pretty
> well. The idea is to extend the existing classes by adding a couple of
> methods, so that you ask them to 'encode' themselves :

OK, so it sounds like the message class and its codecs are combined,
similar to how JAAS KerberosTicket works.

Sounds good, especially the speed boost.

I will soon commit some code. It's really faster.

FYI, the most important
class, which directs the heavy lifting, is CipherTextHandler.

Yes, I noticed it's the place where we have huge CPU consumption while
running some tests. There may be some ways to improve this class, but
I want to finish the codec stuff before, because it's the easiest way
for me to get a grip on the whole thing, learning all the vocabulary
and interns of Kerberos from the low level layer.

CipherTextHandler contains the static hashed adapters that actually
make use of the Encoder/Decoder interfaces, so this is where
compatibility with the new codecs is key.  This is for the "one-shot"
codec use.

I see. It should not be a pb at all.


>                 PrincipalName principal = new PrincipalName(
> PrincipalNameType.KRB_NT_PRINCIPAL, "Test" );
>
>                 ByteBuffer encoded = ByteBuffer.allocate( 
principal.computeLength() );
>
>                 principal.encode( encoded );

Is this for the "one-shot" use or also how the codecs are used in the
codec filters?  I ask because all of the JCE crypto works with byte[]
so anytime one of the current Encoder-using Kerberos objects is
"one-shot" encoded it is immediately encrypted using the byte[] form.
If this is a no cost operation than it is OK but I thought you should
be aware.  It may be slightly nicer for the API to use a byte[].

I have used ByteBuffer just to be in synch with MINA, as MINA is using
ByteBuffers.  The overhead is almost unnoticeable. Switching from
ByteBuffer to byte[] is barely the same operation then switching from
String to char[] : an access to the intern array.


Enrique



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Reply via email to