[Beepcore-java-users] PiggyBacked data, MessageListener and RequestHandler

[Wladimir A. <wa...@ju...>]

	Hi,

	I had code that was using the 0.9.07 library and it used the =
MessageListener interface. Now that I upgraded to the 0.9.08 it =
complains about deprecation (the setMessageListener() method is =
deprecated on the Channel interface (which was a class before)). That =
is, of course, not a problem in itself. The question is: should I =
rewrite the code to not use the MesageListener interface anymore (which =
is fine), in which case the interface should be deprecated or should I =
attempt a fix to this (I cannot throw a BEEPError on a piggybacked msg =
and that destroys my code...)?=20

	I noticed a different handling regarding what is now called a =
PiggybackedMSG. It is actually sent to the newly created channel as a =
regular message (which, IMO, should not be the case, since the =
startChannel() already got it as part of the String data argument). The =
major problem is that my old code does not work anymore. It looks like I =
have to reply to this PiggybackedMsg to continue with the channel =
start-up process. I'm trying to understand why this is done this way =
and, more importantly, how I should proceed.

	My idea for a fix would be to get rid of this piggybacked stuff and use =
the regular (deprecated) setStartData() (I know it's not the best but =
it's better than the current handling). Another option would be to pass =
a holder object instead of the simple String data, which, if modified =
inside startChannel(), would be sent back as embedded data to the =
profile RPY. In both alternatives, sending a content back is not =
mandatory (even if it's empty, if you don't reply to the PiggybackedMSG =
your session is gone). The second one has the problem of changing the =
interface StartChannelListener, but it is a straightforward change.

	Opinions, thoughts...

		Cheers,

Wladimir de Lara Araujo Filho
Juniper Networks, Inc.