Recent changes to patches

GSS Profile

2005-01-21T00:17:57Z

This profile is useful for those still using JDK1.4 and
wanting to do Kerberos authentication.

(For JDK 1.5 a better solution is to have a profile
that uses the new SASL libraries)

Thread safety patch for InputDataStream

2005-01-20T23:43:48Z

This patch fixes a race condition that can potentially
cause problems reading data from a peer. Without this
patch, it is possible for InputDataStreamAdapter.read()
to return -1 prematurely, or
InputDataStreamAdapter.read(byte,int,int) to go into an
endless loop.

Index: InputDataStream.java

RCS file:
/cvsroot/beepcore-java/beepcore-java/src/org/beepcore/beep/core/InputDataStream.java,v
retrieving revision 1.6
diff -u -r1.6 InputDataStream.java
--- InputDataStream.java 23 Apr 2003 15:23:04 -0000 1.6
+++ InputDataStream.java 20 Jan 2005 23:33:24 -0000
@@ -90,9 +90,9 @@

synchronized (this.buffers) {
this.buffers.addLast(segment);
+ this.availableBytes += segment.getLength();
this.buffers.notify();
}
- this.availableBytes += segment.getLength();
}

public int available()

SASLProfile digestmd5 & SOAPProfile

2004-10-12T22:12:48Z

This patch (donated from Cisco Systems Limited) is for
a SASLProfile for digestmd5 and a basic SOAPProfile that
supports RFC3288 bootmsg handling.

The SASL profile (currently called SASLBeepProfile but
probably should be merged with the existing SASLProfile
class) is actually a generic SASL profile that should
be able to use arbitrary SASL Client/Servlet providers
to hand various authentication protocols.

Currently this has only been tested with digestmd5. To
achieve this, the SASL 1.1 RI has been added to the lib
and a sasl provider has been included in org.beepcore.sasl
that supports digestmd5 - partly by wrapping the sun ldap
provider included in jre 1.4. (Note the patch includes an
updated build files and eclipse .classpath file).

The use of this provider is not well documented - but there
are test harnesses that show how it works.

If this approach is accepted, then I believe the other
SASLProfiles should be converted to use the same
approach. IE, instead of writing new SASLProfiles, we
simply write/obtain new SASL providers. Eventually a
full set of these will be provided with the JRE.

The reason for this is that the intent of SASL is more than
just a wire prototocl. It is intended to allow simple
configuration of alternate authentication and
encyrption mechanisms at runtime. Thus hardcoded
profile names do not really support the spirit of SASL
- IMNSHO.

Initial implementation for SASL Plain Profile

2004-09-14T15:34:11Z

An initial implementation of the SASL Plain Profile.

This implementation is tested and works with itself.

It has not yet been tested and probably won't work with
other SASL Plain implementations (i.e. not guaranteed
to interoperate with C, TCL, etc...).

RFC 822 Header Parsing broken

2004-01-04T14:20:47Z

Hi,
(I've sent this patch to the mailing list in November
24th, but it hasn't been incorparated yet).

In an attempt to implement Beep as a protocol for JAXM
and SAAJ using the
SOAP Profile specification, I noticed, that the
implementation of the
RFC822 Header parser has not been complete.

The problems arises when sending attachments with SUNs
default
implementation of JAXM. When sending an Attachment with
Soap, the payload
actually contains a full mime multipart document, so
one mime header
of a beep message contains the boundary which happens
to be on a new line
with the SUN implementation; something like:

Content-Type:multipart/related; type="text/xml";
boundary="----=_Part_0_19610963.1069622873839"

This is correct according to RFC822 (Paragraph 3.2,
field-body
production), but is not implemented in the Beep header
parser which does
not understand multiline headers. So in this case the
boundary is lost and
SOAP-Attachments won't work :-(

I fixed this for the current CVS by implementing a
RFC822 parser (an
improved version found on w3c)

The patch can be found in the attachment.
It will create a new java file and a patch file:

rfc822-header-parse.patch
src/org/beepcore/beep/util/Rfc822HeaderParser.java

The files can then be patched with
patch -p0 < rfc822-header-parse.patch

With this patch, sending JAXM Attachments works without
problems.

ciao,
-hen

PureTLS negotiation failure

2003-04-15T14:34:55Z

PureTLS negotiation fails if the
TLSProfilePureTLSPemInit class is used to initialise
the profile and the PROPERTY_CLIENT_AUTH_REQUIRED
property has not been set in the ProfileConfiguration
passed to TLSProfilePureTLSPemInit.init().
Basically, when this has not been set, the profile
doesn't assume that client authentication IS required.
Consequently, if the client does not set
PROPERTY_CLIENT_AUTH_REQUIRED, the client doesn't send
their certificate to the server during negotiation,
however the server will by default, expect one, if they
haven't had PROPERTY_CLIENT_AUTH_REQUIRED set at their end.
It seems natural to me, that if the server is expecting
client auth when this property hasn't been set, that
the client should provide client auth, when this
property hasn't been set for them.
Its a simple fix, adding an else branch to an if which
checks for the existence of this property. If it isn't
set, then indicate that we expect client authentication.

I have also modififed the class to have a no-arg
constructor which calls the default constructor on its
TLSProfilePureTLS private member, which is initially
set to null, as it seems a more natural way to do
things, rather than have the TLSProfilePureTLS
constructor called statically.

Use thread pool for TCPSession threads

2003-01-15T15:41:27Z

I noticed that TCPSession was creating a new thread to
process the next frame. On linux this requires a new
process to be created, which isn't very efficient I
wouldn't have thought. I've knocked up a simple
singleton containing a Thread Pool (using
concurrent.jar) that TCPSession now uses. Seems to make
an improvement on my boxes for cpu usage, process
creation, and i/o transfer rate.

It's not very thorough, but could it be useful? Does it
make sense, and are there any flaws?

Wrong property accessor called

2002-08-27T10:40:34Z

public String getProperty(String key, String
defaultValue) {
* return props.getProperty(key, defaultValue);
}
Called getProperty with the defaultValue

Fix for bug 581621

2002-08-22T17:08:55Z

SASLOTPProfile now implements Profile

Fix for bug 558390

2002-08-22T17:05:25Z

Added fireChannel events in Session on Listener chnnel
start.