geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sagenschneider, Daniel A" <>
Subject RE: [XML Parsing]
Date Mon, 08 Sep 2003 01:57:27 GMT
Not to question RMI, but on matching methods with the same ordinal number, why not do this
at deployment/startup time?  As the client interface is fixed, we can have a mapping performed
by alphabetically ordering the method signatures and then simply taking their indexes.

As the number of methods is fixed, we can utilise a static structure (i.e. an array) to hold
the method metadata and methodproxies and utilise this index for a lookup (removes the need
for continuous trie lookups or various other string manipulation).

NOTE: if we take control of the stub generation, we can generate these indexes up front and
thus require NO string manipulations.

On Friday, September 5, 2003, at 08:16 AM, Hiram Chirino wrote:
> I actually had to change the way that worked.  Seems like the Method[]
> the Class.getMethods() is in a different order if you run in different
> JVMs.  Well at least that's what I noticed.  So for now I'm sending  
> down
> a String the represents the method sig until I find a way to get an Int
> to represent the method.
> So how can we get 2 jvms to agree on the same ordinal number mapping??

Use the RMI hashing algorithm: 

the string containing the remote method's name and descriptor would be  
the following:


The hash value is assembled from the first two 32-bit values of the  
SHA-1 message digest. If the result of the message digest, the five  
32-bit words H0 H1 H2 H3 H4, is in an array of five int values named  
sha, the hash value would be computed as follows:

long hash = ((sha[0] >>> 24) & 0xFF) |
             ((sha[0] >>> 16) & 0xFF) << 8 |
             ((sha[0] >>>  8) & 0xFF) << 16 |
             ((sha[0] >>>  0) & 0xFF) << 24 |
             ((sha[1] >>> 24) & 0xFF) << 32 |
             ((sha[1] >>> 16) & 0xFF) << 40 |
             ((sha[1] >>>  8) & 0xFF) << 48 |
             ((sha[1] >>>  0) & 0xFF) << 56;


View raw message