beepcore-java-users — Discussion list for developers using beepcore-java library

[Beepcore-java-users] BeepCore-java and RoadRunner-c

[De K. SJ <136...@su...>]

Hi,

Has anyone used beepcore-java with RoadRunner-c? I have just started =
using RoadRunner and the plan is to combine it with work that I did a =
while ago using BeepCore and/or SimpleBEEP. Has anyone done any testing =
of the two?

Thanks,
Sean

Re: [Beepcore-java-users] race in org.beepcore.beep.lib.Reply

[Huston <hu...@us...>]

On Fri, 2003-06-13 at 12:34, Lawrence Greenfield wrote:
> The Reply class has a pretty serious race condition in it: hasNext()
> fails to check the pending replies after coming off of the wait().
> 
> Patch attached. My patch also inserts a while() loop around the
> wait(), which is generally good form.
> 
> Larry

Larry,

Thanks! I'll check this into cvs.

--Huston

[Beepcore-java-users] race in org.beepcore.beep.lib.Reply

[Lawrence G. <le...@an...>]

The Reply class has a pretty serious race condition in it: hasNext()
fails to check the pending replies after coming off of the wait().

Patch attached. My patch also inserts a while() loop around the
wait(), which is generally good form.

Larry

Re: [Beepcore-java-users] NullPointerExcpetion in Channel.java

[Huston <hu...@us...>]

On Wed, 2003-06-04 at 11:48, Paul Andrews wrote:
> The current code in the method receiveFrame(...) calls
> listener.receiveMSG(m) without first checking if listener is null. This
> can happen if the profile allowed a channel to start without setting a
> message listener (which is obviously a bug in my profile, but anyway I
> though you should know).
> 

Thanks! I'll fix that.

--Huston

[Beepcore-java-users] NullPointerExcpetion in Channel.java

[Paul A. <paa...@ci...>]

The current code in the method receiveFrame(...) calls
listener.receiveMSG(m) without first checking if listener is null. This
can happen if the profile allowed a channel to start without setting a
message listener (which is obviously a bug in my profile, but anyway I
though you should know).

- Paul

RE: [Beepcore-java-users] The semantics of close()

[Paul A. <paa...@ci...>]

Yes, that would be perfect. I was thinking that it might also be worth
adding a method to query the state, though that would obviously present
a race condition, I don't think it would matter if close() was modified
like you propose.

> -----Original Message-----
> From: Huston [mailto:hu...@us...] 
> Sent: Wednesday, June 04, 2003 1:14 PM
> To: Paul Andrews
> Cc: Bee...@li...
> Subject: Re: [Beepcore-java-users] The semantics of close()
> 
> 
> On Wed, 2003-06-04 at 10:03, Paul Andrews wrote:
> > I've been thinking about how session.close() works and I'm 
> not really
> > comfortable with it. If I call close() on a session that is already
> > closing I get an illegal state exception from it, yet I 
> have no way of
> > finding out if a session is in the process of closing or is already
> > closed.
> > 
> > This makes it difficult to write code that cleans up when 
> it is through
> > with a session.
> 
> This is a very good point. Would it be ok with you if close() did
> nothing if the state of the session was CLOSING or CLOSED?
> 
> --Huston
> 

RE: [Beepcore-java-users] AbortChannelException terminates session

[Paul A. <paa...@ci...>]

Those changes sounds fine to me.

> -----Original Message-----
> From: Huston [mailto:hu...@us...] 
> Sent: Wednesday, June 04, 2003 1:11 PM
> To: Paul Andrews
> Cc: Bee...@li...
> Subject: Re: [Beepcore-java-users] AbortChannelException 
> terminates session
> 
> 
> On Wed, 2003-06-04 at 09:52, Paul Andrews wrote:
> > Hi again :-)
> > 
> > I have a message reply listener that throws an 
> AbortChannelException in
> > certain circumstances but this actually causes the session 
> code to issue
> > a terminate session request to the remote peer - when all I 
> wanted to do
> > was to terminate the channel.
> > 
> > A slight wrinkle with this is that my test code originally called
> > session.close() immediately after the AbortChannelException 
> was thrown,
> > but in a different thread. This caused the session to deadlock.
> > 
> > - Paul
> 
> In the code I'm working on right now I have removed
> AbortChannelException from the signature of the
> MessageHandler.receiveMSG(). (MessageHandler is a new version of
> MessageListener, the reason for a new interface was to provide a
> migration path for profile writers.) While AbortChannelException made
> some things easier when writing profiles I think it can be 
> the source of
> more problems than good.
> 
> BTW, I'm also considering removing the throws BEEPError from the
> receiveMSG() method because there isn't a good method of notifying the
> profile if there is a problem sending the ERR message from 
> the BEEPError
> exception. Instead profiles would call MessageMSG.sendERR() directly.
> 
> Any feedback on these changes is welcome and right now is the 
> best time
> since I am in the middle of making them.
> 
> --Huston 
> 

Re: [Beepcore-java-users] The semantics of close()

[Huston <hu...@us...>]

On Wed, 2003-06-04 at 10:03, Paul Andrews wrote:
> I've been thinking about how session.close() works and I'm not really
> comfortable with it. If I call close() on a session that is already
> closing I get an illegal state exception from it, yet I have no way of
> finding out if a session is in the process of closing or is already
> closed.
> 
> This makes it difficult to write code that cleans up when it is through
> with a session.

This is a very good point. Would it be ok with you if close() did
nothing if the state of the session was CLOSING or CLOSED?

--Huston

Re: [Beepcore-java-users] AbortChannelException terminates session

[Huston <hu...@us...>]

On Wed, 2003-06-04 at 09:52, Paul Andrews wrote:
> Hi again :-)
> 
> I have a message reply listener that throws an AbortChannelException in
> certain circumstances but this actually causes the session code to issue
> a terminate session request to the remote peer - when all I wanted to do
> was to terminate the channel.
> 
> A slight wrinkle with this is that my test code originally called
> session.close() immediately after the AbortChannelException was thrown,
> but in a different thread. This caused the session to deadlock.
> 
> - Paul

In the code I'm working on right now I have removed
AbortChannelException from the signature of the
MessageHandler.receiveMSG(). (MessageHandler is a new version of
MessageListener, the reason for a new interface was to provide a
migration path for profile writers.) While AbortChannelException made
some things easier when writing profiles I think it can be the source of
more problems than good.

BTW, I'm also considering removing the throws BEEPError from the
receiveMSG() method because there isn't a good method of notifying the
profile if there is a problem sending the ERR message from the BEEPError
exception. Instead profiles would call MessageMSG.sendERR() directly.

Any feedback on these changes is welcome and right now is the best time
since I am in the middle of making them.

--Huston 

[Beepcore-java-users] AbortChannelException terminates session

[Paul A. <paa...@ci...>]

Hi again :-)

I have a message reply listener that throws an AbortChannelException in
certain circumstances but this actually causes the session code to issue
a terminate session request to the remote peer - when all I wanted to do
was to terminate the channel.

A slight wrinkle with this is that my test code originally called
session.close() immediately after the AbortChannelException was thrown,
but in a different thread. This caused the session to deadlock.

- Paul

[Beepcore-java-users] The semantics of close()

[Paul A. <paa...@ci...>]

I've been thinking about how session.close() works and I'm not really
comfortable with it. If I call close() on a session that is already
closing I get an illegal state exception from it, yet I have no way of
finding out if a session is in the process of closing or is already
closed.

This makes it difficult to write code that cleans up when it is through
with a session.

Re: [Beepcore-java-users] Shutting down a server?

[Huston <hu...@us...>]

On Tue, 2003-06-03 at 12:13, Paul Andrews wrote:
> I need a way to close the server sockets created by
> TCPSessionCreate.listen(...). There doesn't seem to be any way to do
> this at the moment.
> 
> - Paul

I hadn't looked at that code, it is in need of some refactoring. Would
you mind entering a bug against this on sf?

For now I wouldn't use TCPSessionCreator. Instead, create your own
ServerSocket and call TCPSession.createListener() for each new
connection you accept.

Thanks for finding this.

--Huston

[Beepcore-java-users] Shutting down a server?

[Paul A. <paa...@ci...>]

I need a way to close the server sockets created by
TCPSessionCreate.listen(...). There doesn't seem to be any way to do
this at the moment.

- Paul

Re: [Beepcore-java-users] start element processing

[Huston <hu...@us...>]

On Mon, 2003-06-02 at 12:59, Paul Andrews wrote:
> Hi,
> 
> I'm implementing a SOAP profile (RFC 3288) which uses the 'serverName'
> attribute of the 'start' element to specify the virtual server on which
> a SOAP service should be present. It seems that I can't get a hold of
> that information in the profile. A quick look at Session.java shows that
> the ChannelZeroListener class access the attribute but doesn't use it or
> store it anywhere.
> 
> What is the intention with this attribute and should the
> ChannelZeroListener class and profile API be modified to make the
> information available? Maybe it should be an attribute of the channel
> that is started?

The latest code in CVS saves this attribute on the Session and it can be
retrieved with getServerName().

--Huston

[Beepcore-java-users] start element processing

[Paul A. <paa...@ci...>]

Hi,

I'm implementing a SOAP profile (RFC 3288) which uses the 'serverName'
attribute of the 'start' element to specify the virtual server on which
a SOAP service should be present. It seems that I can't get a hold of
that information in the profile. A quick look at Session.java shows that
the ChannelZeroListener class access the attribute but doesn't use it or
store it anywhere.

What is the intention with this attribute and should the
ChannelZeroListener class and profile API be modified to make the
information available? Maybe it should be an attribute of the channel
that is started?

Thanks - Paul

[Beepcore-java-users] SessionCredentials and realm

[Paul A. <paa...@ci...>]

One more thing:
 
There is no place to store the 'realm' in the SessionCredential. All of
the other items are really scoped by the realm. Hmmm. in fact, shouldn't
there be room for multiple credentials on a single session, or should
you have one session per realm?

RE: [Beepcore-java-users] SASL Interoperability

[Paul A. <paa...@ci...>]

> -----Original Message-----
> From: bee...@li... 
> [mailto:bee...@li...] On 
> Behalf Of Huston
> Sent: Thursday, May 29, 2003 11:55 AM
> To: Paul Andrews
> Cc: Bee...@li...
> Subject: Re: [Beepcore-java-users] SASL Interoperability
> 
> 
> On Thu, 2003-05-29 at 09:10, Paul Andrews wrote:
> > And finally ( :-) ):
> >  
> > I've been using the Java beepcore implementation against the C
> > beepcore implementation (or more properly with the Cyrus SASL
> > libraries) and come across a couple of interoperability issues.
> >  
> > The first was with the base64 encoding of <blob>s. The Java SASL
> > libraries split the encoding across multiple lines - the Cyrus SASL
> > libraries expect it all to be on one line. At first, I though that
> > RFC3080 was vague on this issue, but it does say in its 
> examples that
> > although the text is split across multiple lines, in actuality, the
> > blob wouldn't be. However, it is read we would increase
> > interoperability if we *didn't* split across multiple lines.
> 
> I agree this should be fixed in beepcore-j. I'm currently refactoring
> the tuning reset code so I won't be able to get to this for a 
> few days.
> If you need it sooner and would like to submit a patch I'm happy to
> check it in.

No hurry - we modified the Cyrus side instead for the time being. Fixing
it in the Java classes would require using a different base64 encoder
than the Sun one - there are plenty around, but I didn't want to modify
the beepcore-j code so I don't have a patch to provide. Sorry.

> 
> > The second is really a problem with the Cyrus libraries, but I'll
> > include it here in case anyone reading can influence the 
> Cyrus group.
> > RFC2831 (SASL/DIGESTMD5) states that 'qop-options' is optional and
> > defaults to "auth" if not specified. Cyrus simply aborts 
> the exchange
> > if it isn't specified.
> 
> I don't know much about SASL but is there something that could be
> changed in beepcore-j to make this work?

No. beepcore-j doesn't do DIGESTMD5 at all - it is in my implementation,
so, once again, we fixed it in our version of the Cyrus libraries. It
really needs to be fixed by the Cyrus team so we'll probably be in touch
with them :-).

It would be good to submit our DIGESTMD5 code to beepcore. We'll have to
work on our management for that, plus it uses a preview release of Sun's
SASL API for the initiator side and I've got a few issues with that too
:-). I wrote the listener side myself.

> 
> --Huston
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Beepcore-java-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-java-users
> 

RE: [Beepcore-java-users] Possible bug in SASL profile listenercode

[Paul A. <paa...@ci...>]

No problem.

> -----Original Message-----
> From: Huston [mailto:hu...@us...] 
> Sent: Thursday, May 29, 2003 11:59 AM
> To: Paul Andrews
> Cc: Bee...@li...
> Subject: Re: [Beepcore-java-users] Possible bug in SASL 
> profile listenercode
> 
> 
> On Thu, 2003-05-29 at 09:01, Paul Andrews wrote:
> > At various places, the SASL tuning profile listener code 
> sends a blob
> > containing <abort>s to the initiator if anything goes wrong. I don't
> > think this is correct. RFC 3080 says:
> >  
> > exchange sequence: 
> >         "Challenges" and "responses" are carried in exchanges of the
> >         "blob" element. The "status" attribute of the "blob" element
> >         is used both by a server indicating a successful 
> completion of
> >         the exchange, and a client aborting the exchange, The server
> >         indicates failure of the exchange by sending an "error"
> >         element.
> 
> I agree with your assesment, this needs to be fixed in beepcore-j.
> 
> Would you mind entering this as a bug on SF so that is doesn't get
> forgotten about?
> 
> --Huston
> 

Re: [Beepcore-java-users] Possible bug in SASL profile listener code

[Huston <hu...@us...>]

On Thu, 2003-05-29 at 09:01, Paul Andrews wrote:
> At various places, the SASL tuning profile listener code sends a blob
> containing <abort>s to the initiator if anything goes wrong. I don't
> think this is correct. RFC 3080 says:
>  
> exchange sequence: 
>         "Challenges" and "responses" are carried in exchanges of the
>         "blob" element. The "status" attribute of the "blob" element
>         is used both by a server indicating a successful completion of
>         the exchange, and a client aborting the exchange, The server
>         indicates failure of the exchange by sending an "error"
>         element.

I agree with your assesment, this needs to be fixed in beepcore-j.

Would you mind entering this as a bug on SF so that is doesn't get
forgotten about?

--Huston

Re: [Beepcore-java-users] SASL Interoperability

[Huston <hu...@us...>]

On Thu, 2003-05-29 at 09:10, Paul Andrews wrote:
> And finally ( :-) ):
>  
> I've been using the Java beepcore implementation against the C
> beepcore implementation (or more properly with the Cyrus SASL
> libraries) and come across a couple of interoperability issues.
>  
> The first was with the base64 encoding of <blob>s. The Java SASL
> libraries split the encoding across multiple lines - the Cyrus SASL
> libraries expect it all to be on one line. At first, I though that
> RFC3080 was vague on this issue, but it does say in its examples that
> although the text is split across multiple lines, in actuality, the
> blob wouldn't be. However, it is read we would increase
> interoperability if we *didn't* split across multiple lines.

I agree this should be fixed in beepcore-j. I'm currently refactoring
the tuning reset code so I won't be able to get to this for a few days.
If you need it sooner and would like to submit a patch I'm happy to
check it in.

> The second is really a problem with the Cyrus libraries, but I'll
> include it here in case anyone reading can influence the Cyrus group.
> RFC2831 (SASL/DIGESTMD5) states that 'qop-options' is optional and
> defaults to "auth" if not specified. Cyrus simply aborts the exchange
> if it isn't specified.

I don't know much about SASL but is there something that could be
changed in beepcore-j to make this work?

--Huston

Re: [Beepcore-java-users] Initiator use of tuning profiles

[Huston <hu...@us...>]

On Thu, 2003-05-29 at 08:50, Paul Andrews wrote:
> There doesn't seem to be a common API that an initiator can use to,
> for example, start an authentication with a remote peer. This means
> that every initiator has to have explicit knowledge of the various
> TuningProfile subclasses in order to call the correct method to start
> the exchange.
>  
> Is there any intention to define an initiator API for tuning profiles
> - maybe something along the lines of an initator using a directory API
> to locate an implementation from some set of characteristics and then
> kick off the exchange using single interface that those
> implementations implement?
>  
> Am I missing something here?

I don't think you are missing anything. This is an area which hasn't had
much thought given to it. I like the idea of having a common API for the
initiator. Any help you would like to give in this area is welcome.

--Huston

Re: [Beepcore-java-users] TuningProfile

[Huston <hu...@us...>]

On Thu, 2003-05-29 at 08:45, Paul Andrews wrote: 
> I'm writing a SASL/DIGESTMD5 tuning profile and am trying to work out
> how TuningProfile is supposed to be used. It has a bunch of methods
> (begin, complete and abort) that none of the exisitng tuning profiles
> actually use - in fact SASLAnonymousProfile says it uses them, but it
> doesn't.
>  
> TuningProfile also has an implementation of startChannel - am I
> supposed to call that from my own implementation?

begin, complete, abort, and startChannel are for profiles which need to
do a tuning reset, typically profiles providing session level encryption
will use this (e.g. TLS).

TuningProfile also provides methods for setting credentials for profiles
perfoming authentication.

--Huston

[Beepcore-java-users] SASL Interoperability

[Paul A. <paa...@ci...>]

And finally ( :-) ):
 
I've been using the Java beepcore implementation against the C beepcore
implementation (or more properly with the Cyrus SASL libraries) and come
across a couple of interoperability issues.
 
The first was with the base64 encoding of <blob>s. The Java SASL
libraries split the encoding across multiple lines - the Cyrus SASL
libraries expect it all to be on one line. At first, I though that
RFC3080 was vague on this issue, but it does say in its examples that
although the text is split across multiple lines, in actuality, the blob
wouldn't be. However, it is read we would increase interoperability if
we *didn't* split across multiple lines.
 
The second is really a problem with the Cyrus libraries, but I'll
include it here in case anyone reading can influence the Cyrus group.
RFC2831 (SASL/DIGESTMD5) states that 'qop-options' is optional and
defaults to "auth" if not specified. Cyrus simply aborts the exchange if
it isn't specified.
 
Thanks - Paul.

[Beepcore-java-users] Possible bug in SASL profile listener code

[Paul A. <paa...@ci...>]

At various places, the SASL tuning profile listener code sends a blob
containing <abort>s to the initiator if anything goes wrong. I don't
think this is correct. RFC 3080 says:
 
exchange sequence: 

"Challenges" and "responses" are carried in exchanges of the "blob"
element. The "status" attribute of the "blob" element is used both by a
server indicating a successful completion of the exchange, and a client
aborting the exchange, The server indicates failure of the exchange by
sending an "error" element.

[Beepcore-java-users] Initiator use of tuning profiles

[Paul A. <paa...@ci...>]

There doesn't seem to be a common API that an initiator can use to, for
example, start an authentication with a remote peer. This means that
every initiator has to have explicit knowledge of the various
TuningProfile subclasses in order to call the correct method to start
the exchange.
 
Is there any intention to define an initiator API for tuning profiles -
maybe something along the lines of an initator using a directory API to
locate an implementation from some set of characteristics and then kick
off the exchange using single interface that those implementations
implement?
 
Am I missing something here?
 
- Paul Andrews