Change Log
Version 0.90.1:
XdrEncodingStream.xdrEncodeByteFixedVector()
which
falsely encoded length information about the following array of characters.
I should take more care when doing "Italian code recycling" using copy &
pasta...
OncRpcTcpClient.call()
which caused XDR
buffer underflows when receiving the next reply after the previous reply
has been rejected by an ONC/RPC server.
org.acplt.oncrpc
to put it
in sync with (de-) serializing fixed-size vectors and dynamic and fixed vectors
of characters.
AUTH_UNIX
authentication. For this to achieve quite
some additions and changes were necessary -- luckily, old applications will
not be broken, as the changes are deep within the RemoteTea package:
OncRpcClientAuth
, OncRpcClientAuthNone
and
OncRpcClientAuthUnix
were added.
OncRpcReplyMessage
and OncRpcCallMessage
are now
both abstract. This was necessary because ONC/RPC protocol issues make it
necessary to handle authentication through so-called authentication protocol
handling objects different on the client side than on the server side.
Additional classes now handle sending calls and receiving replies on the
client side (OncRpcClientCallMessage
and
OncRpcClientReplyMessage
respectively), as well as on the
server side (OncRpcServerCallMessage
and
OncRpcServerReplyMessage
). According to their needs, these new
classes only declare those encoding and decoding methods which are really
needed. In consequence, the base class OncRpcCallMessage
has lost
its XdrAble
interface completely.
OncRpcUdpClient
and OncRpcTcpClient
, as well as
to the base class OncRpcClient
.
callMessage.auth
attribute of the OncRpcCallInformation
delivered with each incomming ONC/RPC call. See
tests.org.acplt.oncrpc.ServerTest.java
for an example.
AUTH_DES
is still not supported, as this needs
quite some things to be done and I don't have full information about the
AUTH_DES
protocol.
XdrBufferEncodingStream
and
XdrBufferDecodingStream
for encoding and decoding XDR data from
and to a fixed-size buffer. These classes comes in handy when dealing with
shorthand credentials.
XdrDynamicOpaque
to handle variable-sized
vectors of bytes.
org.acplt.oncrpc.apps.jrpcgen
,
because it's an application belonging very tight to ONC/RPC.
OncRpcConstants.REMOTETEA_VERSION_PREVERSION
,
which indicates preversions if not zero.
Version 0.86.1:
char<>
as a series of
characters, each one sitting happily in its very own XDR int (that is,
four bytes), the two methods XdrDecodingStream.xdrDecodeBytes()
and XdrEncodingStream.xdrEncodeBytes()
were renamed to
XdrDecodingStream.xdrDecodeByteVector()
and XdrEncodingStream.xdrEncodeByteVector()
as well as their
semantics changed accordingly.
XdrDecodingStream.xdrDecodeDynamicOpaque()
,
XdrEncodingStream.xdrEncodeDynamicOpaque()
,
XdrDecodingStream.xdrDecodeByteFixedVector()
and
XdrEncodingStream.xdrEncodeByteFixedVector()
.
XdrDecodingStream
and XdrEncodingStream
finally final
. Maybe this helps Java compilers improve code
speed. Maybe.
XdrDecodingStream
and XdrEncodingStream
.
Version 0.85.1:
readBuffer()
to class
XdrTcpDecodingStream
. This fixes problems when reading from
a TCP/IP stream and not all bytes wanted are immediately available, thus
stream.read()
returning not all bytes at once (shame on me
for not reading the java.io documentation attentive enough).
Version 0.84.1:
Version 0.83.1:
Version 0.82.1:
Version 0.81.1:
broadcastCall
of method in class OncRpcUdpClient
.
jrpcgen
. Sun's documentation on the rpcgen
syntax and grammar is rather thin and sometimes inaccurate. As always, I had to resort
to RTSL ("Read The Source, Luke!") to find out what syntax and grammar rpcgen
does in fact use. Please give it a try and report problems. Note that there
is no preprocessor step.
Version 0.80.2:
Version 0.80.1:
Version 0.35.1 and before: