Re: [Beepcore-java-users] Piggyback data API deprecated.
Status: Beta
Brought to you by:
huston
From: Huston <hu...@us...> - 2004-07-27 13:08:28
|
You are correct about the state of the piggybacked requests. I haven't added anything to the API for the initiator side because I haven't found a design that felt comfortable yet. The idea I have been toying with is passing a ReplyListener into the startChannel call and then mapping the reply into a InputDataStream in a similar way to what is happening on the listener side (input is welcome). I deprecated the set/getStartData APIs a bit prematurely to let people writing listener profiles know that they shouldn't be using them. Unfortunately it creates a problem for people writing initiator profiles. --Huston Wladimir Araujo wrote: > These methods have been deprecated, yes. For you to piggyback >data you can do the following: > > send it with (Session): > > public Channel startChannel(String profile, boolean >base64Encoding, > String data) > throws BEEPException, BEEPError; > > you'll get it on the other side with (Channel): > > public void startChannel(Channel channel, String >encoding, String data) > throws StartChannelException; > > There was (is), however, a problem with the SessionImpl start-up >(processStartChannel). I had submitted a fix a while ago, but I don't >know the status of where it went. I am attaching my previous message >with the fix. The detail is that you must send back some data (using >setStartChannel). That solved my problem. Maybe you can improve the fix >in the case no reply is sent. > > I hope it helps. Detail: I still use the deprecated methods. > > Cheers, > >Wladimir de Lara Araujo Filho >Juniper Networks, Inc. > > >-----Original Message----- >From: bee...@li... >[mailto:bee...@li...]On Behalf Of >Greg Wilkins >Sent: Sunday, July 25, 2004 10:49 PM >To: bee...@li... >Subject: [Beepcore-java-users] Piggyback data API deprecated. > > > >The setStartData and getStartData methods have been deprecated, but I >can't see how to avoid their use to receive a piggyback reply? > >You can send piggyback data with an arg to startChannel. >You can receive piggyback data with a RequestHandler and send a reply >normally. > >But I can't see how to receive this reply without using getStartData >after the startChannel? > >I'm also seeing a problem that after using piggyback data, the channel >does not appear to work. But I think this is a bug in 0.9.08 that has >been discussed in the "PiggyBacked data, MessageListener and >RequestHandler" thread. > >regards > > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >_______________________________________________ >Beepcore-java-users mailing list >Bee...@li... >https://lists.sourceforge.net/lists/listinfo/beepcore-java-users > > > > ------------------------------------------------------------------------ > > Subject: > PiggyBacked data, MessageListener and RequestHandler (simple fix) > From: > "Wladimir Araujo" <wa...@ju...> > Date: > Wed, 11 Feb 2004 11:32:45 -0400 > To: > "Beepcore \(E-mail\)" <bee...@li...> > > To: > "Beepcore \(E-mail\)" <bee...@li...> > > > Hi, > > Since I did not hear from anybody in this respect, I'm adding this simple fix. The piggybacked stuff remains there and the TCPSession is recreated afterwards. This only works if StartChannelListener.startChannel() calls channel.setStartData() to send back a piggybacked reply, otherwise the session will die if the new channel does not reply to the piggybacked message. The patch is below. > > Cheers, > >--- SessionImpl.java.new Wed Feb 11 10:21:28 2004 >+++ SessionImpl.java.old Wed Feb 11 10:24:09 2004 >@@ -1321,7 +1321,7 @@ > > fireChannelStarted(ch); > >- if (ch.getState() != ChannelImpl.STATE_TUNING) { >+ if (p.data == null && ch.getState() != ChannelImpl.STATE_TUNING) { > this.enableIO(); > } > } > >Wladimir de Lara Araujo Filho >Juniper Networks, Inc. > > > |