Menu ▾ ▴

CoFFEE re-engineering

Pina Palmieri

CoFFEE re-engineering

CoFFEE project tackles nat traversal problem, introducing XMPP container

Changes in CoFFFEE project

Changes in the Controller

Login of the teacher with XMPP account

Aim
The controller on the start up should ask to the user the xmpp login and password and the inforamtion about the collaborative session which he is starting. Then, the controller performs the login on the openfire server and creates the chatroom associated with the session.

Status on 25.11.2010
Currently, the controller login on openfire with fixed information embedded in the code (ilaman@trantor).
Changes on the project it.unisa.coffeeServerCore:

  • created the package it.unisa.coreplugins.coffeeServerCore.ecf.xmpp which contains the classes providing xmpp implentation for coffee;
    In particular, the TestSharedObject? is used to test the xmpp protocol and has no implication for coffee;
    The class XmppClient? implements the xmpp funcionalities for coffee:
    • creates the global xmpp container and connect to the openfire server
    • creates the chatroom and its conainer
    • add shared objects to the containers (both the global and the chatroom containers)
  • changes in the class LEADServer:
    • added a field istance of XmppClient?
    • in the method init(), without modifying the existent behavior, at the end,
    • creation of the XmppClient?; it creates the containers and performs the connection;
    • creation of the chatroom "test"; so far it is a static and predefined room, but it will modified to take the information from the start up dialog of the controller;
    • added the TestSharedObjects? to the xmmpClient; this operation does not make sense for coffee, it has just testing aims.

TODO

  • change the initial dialog to get the information about the conenction to the openfire server

Create a XMPP room (chatroom)

Aim
At the start up the CoFFEE server has to create a room; The roomm should show information about the identity of the coffee server;

Status on 25.11.2010

  • changes in the class LEADServer:
    • creation of the chatroom "test"; so far it is a static and predefined room, but it will modified to take the information from the start up dialog of the controller;

TODO

  • associate the creation of the roon with the information about the controller
  • check what happens if the room already exists
  • verify how the clients can identify the desired room (i.e. coffee controller)

Add to the chatroom all Shared Object of the CoFFEE

Aim
All the sharedObject used by CoFFEE should be registered on the xmpp container; a the end, the tcp container should be eliminated. The communication should be modified to use the xmpp container; Note that the broadcast should use the chatroom, while the point-to-point communications should use the xmppp global container.

Status on 1.12.2010

  • changes in the class XmppClient?
    • added a method addSharedObject(ID id, BasicSharedObject? so); it does the same operation of the method addSharedObject(ID id, BaseSharedObject? so) but morevoer, it sets information in the shared object about the xmmpp romm; these information are required to execute the bradcast of the messages;
  • changes in the class BasicSharedObject?
    • added information about the xmpp room (and related getter and setter methods);
    • modified the method sendSharedObjectMessage(ID fromID, ID toID, Serializable msg) to send th emessage in broadcast by using the id of the xmpp room instead of the <null> target previuolsy usedwith the TCP generic container;

Status on 25.11.2010

  • changes in the class LEADServer:

    • in the method addSharedObject(), at the end, without modify the current behavior, added a line to add the sharedOject to the xmppClient:

    xmppClient.addSharedObject(id,so);

the method addSharedObject of the XmppClient? adds the sharedObject to both the gloabal and the chatroom container. Currently, CoFFEE Controller adds the shared object of core and of the tools which are activated, but it throws an exception on communication because the broadcast must be managed diffrenetly (the point is that xmpp does not accept "null" as target, while in the existing mechanism the target "null" means "broadcast").

Communications

Aim
Sending mechanism: Controller to all discussers, Controller to one discusser, Discusser to Controller and then in broadcast, Dicsusser to Controller and stop (quick chat); This mechanism involves not only the Controller part but also tools and parts common to Discussers.

Controller to ALL discussers
messages sent from the server will be addressed to the id of the room, so that will be sent in broadcast (including then to himself). This mechanism implies two main aspects:

  1. the messages must set the destination id to the xmpp room id
  2. the server should discard the messages received in broadcoast (otherwise it will send th emessages again generating an infinite loop)

TODO

  • Controller to one discusser
  • Discusser to Controller and then in broadcast
  • Dicsusser to Controller and stop (quick chat)

Status on 10.12.2010

  • Changes concerning parts common to Controller and Discusser
    • project it.unisa.coffeeUtilsCore
    • created a new package it.unisa.coreplugins.ecf.core.xmpp with the class:
      • XmppConnectionInformation?; thiss class collect all information useful for the xmpp conenction
      • the user account
      • password
      • username (achieved from the useraccount)
      • the connectContext (achieved from the username and password)
      • the serveaddress (achieved from the useraccount)
      • a reference to the xmpp container
      • a boolean indacating if the user is playing as Controller
    • changes in the package it.unisa.toolplugins.ecf
      • class LEADMessageProcessorECFAdapter
      • in the method processEvent()
        • added code to allow the Controller to discard messages which he sent in broadcast; changes to this aim
        • added a reference to XmppConnectionInformation? to check if the user is playing as the Controller
        • added code to check if the received message has a destinationID equal to the cmpp room ID (it means that the the message was sent in broadcast)
  • Changes concerning Controller
    • project it.unisa.coffeeServerCore
    • class LEADServer
      • added fields to determine the protocol used (xmpp or tcp)
      • added the method to get the XMPP client
      • added in EACH method the distinction between TCP_Protocol and XMPP_Protocol; (NOTE: currently the TCP protocol doesn't work!!!)
      • added a new method to init the XMPP protocol
    • class XmppClient?
      • moved the information about userID, userAccount and so on in the class XmppConnectionInformation?
      • splittted the method createandconnnectContainer() in CreateContainer?() and connectContainer()
      • added a method to get the xmppContainer;
  • Changes concerning Discusser
    • project it.unisa.coffeeClientCore
    • class XmppClient?
      • added a field XmppConnectionInformation?;
      • in the init() method added the instatiation of this field;
      • in the creatChatRoom() method added the setting of the chat room information;
  • Changes concerning Chat Server
    • project it.unisa.chatTool.server
    • package it.unisa.chattool.server
      • class ChatComposite?:
      • in the methods sendInfo(final boolean check) and sendFullAnonymousInfo(final boolean check) (which send information about anonymisation), changed the construction of the LEADMessage so that it sets as target the LEADserveridentifier (instead of the sharedobject id)

Presence Awareness on the Control Panel

Aim
The Control Panel on the CoFFEE Controller should be updated about the log in and log out of users;

The Control Panel, in the original version of CoFFEE, receives updates from the LEADServerPresenceManager which is a listener of the Container events; this means that the LEADServerPresenceManager receives the connected and disconnected events of clients; This does not happen with XMPP because the clients are connected onto the XMPP server and not on the CoFFEE Controller. The Controller must be changed to receive updates from the XMPP server.

Status on 15.12.2010
Changes on the project it.unisa.coffeeServerCore:

  • in the package it.unisa.coreplugins.coffeeServerCore.ecf
    • class LEADServer
    • in the method initXMPP() added as PresenceListener? the LEADServerPresenceManager to the XMPPClient (which adds the LEADServerPresenceManager to the XmppPresenceManager?);
    • class LEADServerPresenceManager
    • implements a new interface: IXMPPPrsenceListener
    • implements the new method handleXmppPresence(ID id, IPresence presence) to receive update events from the XmppPresenceManager?;
  • in the package it.unisa.coreplugins.coffeeServerCore.ecf.xmpp
    • created the new interface IXMPPPresenceListener, to identify the methods that a class must implement to receive updates about xmpp presence;
    • created the new class XMPPChatRoomPresenceManager, which receives the updates about xmpp presence in a specific room from the xmpp server and updates its listeners (which should implement the interface IXMPPPresenceListener)
    • in the class XMPPClient
    • added a field XMPPChatRoomPresenceManager;
    • in the costructor, instanced the field XmppChatRoomPresenceManager?;
    • in the method createChatRoom(), added the XmppChatRoomPresenceManager? to the ChatRoomContainer? as ParticipantsListener?;
    • added a method addPresenceListener(LEADServerPresenceManager presenceManager) to add listeners to the XMPPChatRoomPresenceManager;

Changes on the project it.unisa.coffeeUtilsCore:

  • in the package it.unisa.coreplugins.ecf.core
    • in the class LEADID, changed the type of the first argument in both the costructors from LEADNamespace to Namespace:
    • LEADID(Namespace en, String username, String pwd)
    • LEADID(Namespace en, String username, String pwd, boolean isTeacher)

Latecomer Management

Aim Synchronizing the tools and their content between the Controller and latecomer clients;

Note: this feature involves also the Discusser.

Status on 21.12.2010

Changes on the project it.unisa.coffeeUtilsCore:

  • in the package it.unisa.coreplugins.ecf

    • in the class BasiSharedObject?
    • in the method sendSharedObjectMessage(ID fromID, ID toID, Serializable msg), changed the mechanism to send messages, in particular are been modified the checks about broadcast, controller-side, client-side.
      • removed the information about the room info that now are get from the XMPPInformationConnection;

  • in the package it.unisa.coreplugins.ecf

    • in the class LEADID
    • added a boolean isXMPPID that indicates if this LEADID is associated with a XMPPID
    • addedd a constructor to create a LEADID from a XMPPID; this constructor set the boolean isXMPPID to TRUE;
    • added a field XMPPID so that the LEADID can contain an XMPPID; added relative getter method;
    • added a field XMPPID xmppID_userAtHost built on information of the xmppID field but in the form <username@serverHost> (i.e. ilaman@trantor); added relative getter method;
    • added a field XMPPID xmppID_userAtRommService built on information of the xmppID field but in the form <username@…> (i.e. ilaman@…); added relative getter method;

  • in the package it.unisa.coreplugins.ecf.core.xmpp

    • in the class XmppConncetionInformation?
    • added a field String controllerUserName and relative getter method; the initialization of this field happens in the setRoomInfo method, when the controller creates the chatroom or the discusser login on the chatroom;
    • added a field ID IDcontrollerID and relative getter method; the initialization of this field happens in the setRoomInfo method, when the controller creates the chatroom or the discusser login on the chatroom;

  • in the package it.unisa.toolplugins.ecf

    • in the class ClientStateManagerEventProcessor?
    • in the method sendStateRequest(),
      • modified the ID to which send the state request;
      • modified the ID from which th emessage is isent (it was the shared object ID, now it is the user id)
      • modified the creation of the message with the new IDs

  • in the class ServcerStateManagerEventProcessor?,

    • modified the method handleRequestStateMessage so that send the message to the sender;

  • in the class ECFLEADContext

    • in the constructor, modified the check to add the ServerStateManagerEventoProcessor? to the sharedobjects;
    • TODO: questa modifica probebilmente compromette la funzionalità in TCP; si dovrà riprisitnare anchel'if che ora è commentato nel costruttore (al rigo 100) per assicurare che fuznioni anche TCP;

Changes on the project it.unisa.coffeeServerCore:

  • in the package it.unisa.coreplugins.coffeeServerCore.ecf

    • in the class LEADServer
    • in the method initXMPP() added the LEADServerConnectionManager to the Xmpp Client
    • in the class LEADServerPresenceManager
    • in the method handleXmppPresence() changed the creation of the leadID with the new constructor that accept as argumet the XMPPID

  • in the package it.unisa.coreplugins.coffeeServerCore.ecf.internal

    • in the class LEADServerConnectionManager
    • the class implements the interface IXMPPPResenceListener
    • modified the methos processEvent() so that now it uses the new signature of the method handleConnection()
    • modified the signature of the method handle connectionevent so that it receives as argument the id of the connected client;
    • added the method handleXmppPresence() that manage the connection on the xmpp protocol;

  • in the package it.unisa.coreplugins.coffeeServerCore.ecf.xmpp

    • in the class XmppChatRoomPresenceManager?
    • in the method notifyListenes, added a check on the type of the ID; since this method updates xmpp presence, it checks that the id is istance of XMPPID;

  • in tha class XmppClient?,

    • changed the type of the argument addPresenceListener(), from LEADServerPresenceMAnager to IXMPPPresenceListener;

  • in the package it.unisa.coreplugins.coffeeServerCore.session

    • in the class AgileStepsManager?
    • in the method playExtraStepsTo(), changed the typpe of the argument from ID to LEADID;

Changes on the project it.unisa.coffeeClientCore:

  • in the package it.unisa.coreplugins.coffeeClientCore.ecf.xmpp
    • in the class XMPPClient
    • int he method addSharedObject(), removed the serRoomInfo on the sharedobject because the shared object can get these information frmo the XMppConnection_Informatiopn class, and added the setIsProtocol(true) to the sharedobject, so that the shared object can manage the difference between the TCP and XMPP protocol;

TODO

  • funzionalità testate solo con gli step al volo; da testare il funzionamento con la sessione;
    • verificare il funzionamento con il protocollo TCP;

Reloading saved sessions

Aim
The controller on the start should be able to reload a saved session from a trace file.

Status on 10.01.2011
When the controller reload a saved session, the tools are reloaded fine they are empty: the content is not reloaded.

Status on 14.01.2011
Added the event processors to trace the messages, now all the messages are traced twice (and then reloaded twice). It could depend on the fact that the event processors handle also the messages of the discusses forwarded by the Controller.

Status on 17.01.2011
fixed.

Changes on the project it.unisa.coffeeServerCore:

  • in the project it.unisa.coffeeServerCore, in the package it.unisa.coreplugins.coffeeServerCore.ecf

    • changes in the class LEADServer:
    • in the method addSharedObject()
      • for the protocol XMPP, added the event processors LEADServerTracer and LEADServerActivityMonitor;

  • in the project it.unisa.coffeeUtilsCore

    • in the package it.unisa.coreplugins.ecf
    • in the class BasicSharedObject?, changed the protector of the field isProtocolXMMP to default.
    • in the package it.unisa.toolsplugins
    • in the class LEADMessage
      • in the method setForwardesMsg(), added a check so that if the protocol used is XMPP, the messages forwarded from the Controller to the Discussers are not traced.

Communication Protocol on command line

Aim 1: allowing to choose the protocol (between TCP and XMPP) from command line;

Aim 2: on the basis of the chosen protocol, open an initial dialog with the right fields to fill

Status on 20 Jan 2011

Changes

  • on the project it,unisa.coffeeUtilsCore
    • in the package it.unisa.coreplugins.ecf.core
    • created a new class CommProtocol? which supports the application in the management of TCP and XMPP. It canbe initialized in the ApplicationWorkbenchWindowAdvir? and then its methods isTCP() and isXMMP() can be used everywhere in the application to check the protocol in use.

  • on the project it,unisa.coffeeServerCore

    • in the package it.unisa.coreplugins.coffeeServerCore.application.start.ui
    • in the class InformationServerDialog?
      • added an inner class XmppConnection? to manage the data for the XMPP connection
      • added a field of type XMPPConnection
        • added a method createXmppConnection() which creates an istance of the XmppConnection?; subcliasses of the information dialog that do not require the xmpp connection data can override thi method to return null.
      • in the method createDialogAreaContents(), added a portion of code to create the area to manage the data for the xmpp conection;
      • in the method my_close(), added a portion of code to save xmpp data in the configuration file;
    • in the package it.unisa.coreplugins.coffeeServerCore.ecf
    • in the class LEADServer
      • removed the field to manage TCP and XMPP protocol, that now are manged in the class CommProtocol?; this change involeves checks on the protocolin the following methods:
      • in the constructor LEADServer()
      • in readAtuhtenticationMode()
      • initXMPP()
      • getECFContainer()
      • getIdentifier()
      • start()
      • stop()
      • getSharedObject()
      • addSharedObject()
      • changes in initXMPP(): now it receives no arguments and reads the userAccount and password from the configuration file;
    • in the package it.unisa.coreplugins.coffeeServerCore.ecf.xmpp
    • in the class XmppClient?
      • in the method connectContainer() added a message Dialog to manage errors during the connection to the xmpp server;
      • in the method creatChatRoom()
      • changed the arguments to receive the strings coming from the initial information dialog;

  • on the project it.unisa.coffeeController

    • in the package it.unisa.coffeecontroller
    • in the class ApplicationWorkbenchWindowAdvisor?
      • in the constructor ApplicationWorkbenchWindowAdvisor?() added a portion of code to get the communication protocol from the command line and to set this value in the COmmProtocol class; moreover, this value determines the type of ServerStartUp? that the application will use: on the basis of the type of protocol the applicatio will use a dialog with fields for TCP or for XMPP.
      • added a method setProtocolFrom Arguments() whic set the protocol in the class CommProtocol?;
      • moved the code that where in the method openIntro() in the cosntructor;
      • in the method preWindowShellClose() added a check to verify that the LEADServer has not been already stopped;
    • in the package it.unisa.coffeecontroller.startup
    • created the class TCPServerStarUp, which extends ServerStartUp? and overrides the createInformationServerDialog() to create a TCPInformationServerDialog;
    • created the class XMPPServerStarUp, which extends ServerStartUp? and overrides the createInformationServerDialog() to create a XMPPInformationServerDialog;
    • created a new package it.unisa.coffeecontroller.stratup.dialogs
    • created a new class TCPInformationServerDialog which extends InformationServerDialog? and overrides the method createXmppConnection() to return null, because this dialog is used when the protocol is TCP and then the xmpp information are not required;
    • created a new class XMPPInformationServerDialog which extends InformationServerDialog? and overrides the method reateAuthenticationArea() to return null, because this dialog is used when the protocol is XMPP and then the authentication information are not required;

Exceptions on closing Controller

Problem: closing the Controller (also without tools started), it throws several NullPointerException?

Status on 20 Jan 2011

Changes:

  • on the project it,unisa.coffeeServerCore

    • in the package it.unisa.coreplugins.coffeeServerCore.application.start
    • in the class Activator, in the method stop(), added an IF to check if the LEADServer is alredy stopped, to avoid NullPointer? Exceptions
    • in the package it.unisa.coreplugins.coffeeServerCore.ecf
    • in the class LEADServer
      • added a filed boolean "stopped" to indicate if the server has already been stopped;
      • in the method getInstance() added a check on the stopped condition before to create the instance of the server; this is necessary to avoid to create a new istance of the server if this method is called during ths shutdown phase;
      • added a method isStopped which return a boolean indicating if the LEADServer has been already stopped;
      • in the method stop(), at the begin of the method, added a check to verify if the LEADServer has alredy been stopped
      • commented the method dispose() (which is embedded in the stop method)
    • in the package it.unisa.coreplugins.coffeeServerCore.serverStartUp
    • in the class LEADServerStartUp
      • in the method stop(), added a check to verify that the LEADServer has not been already stopped;
    • in the package it.unisa.coreplugins.coffeeServerCore.ui.actions
    • in the class ExitAction?
      • in the method run(), at the end, added a check to verify that the LEADServer has not been already stopped;
    • in the class StopServerAction?
      • in the method run(), at the end, added a check to verify that the LEADServer has not been already stopped;

  • on the project it.unisa.coffeeController

    • in the package it.unisa.coffeecontroller
    • in the class Activator, in the method stop(), commented the dispose of the LEADServer, which is stoppede elsewhere.
    • in the class ApplicationWorkbenchWindowAdvisor?
      • in the method preWindowShellClose() added a check to verify that the LEADServer has not been already stopped;

Fixing TCP protocol

Aim
Allowing to use CoFFEE with TCP OR XMPP protocol;

VERY IMPORTANT NOTE: the tests have been made with CoFFEE Discusser v5.0 THEN WITHOUT ANY CHANGE INVOLVING THE PROTOCOLS.

Problem #1 opening the chat, the Controller throws the following exception:

at it.unisa.coreplugins.ecf.BasicSharedObject?.sendSharedObjectMessage(BasicSharedObject?.java:194) ...

Fix

  • In the project it.unisa.coffeeUtilsCore, in the Class BasicSharedObjectMethod?
    • added a boolean field which indicates if the protocol used is XMPP;

    • in the method sendSharedObjectMessage(ID fromID, ID toID, Serializable msg) changed the sending mechanism to select the right destination ID on the basid of the procotol in use: 

        if (isProtocolXMPP){
     ID roomID = roomInfo.getRoomID();
     getContext().sendMessage(broadcast ? roomID : toID, cm);
  }else{
     getContext().sendMessage(broadcast ? null : toID, cm);
  }

Result

  • the Controller is able to open the chat and to send messages (editing, chat, anonymous)
  • New Problem: the Discusser is not able to send messages;

Problem #2

  • When the Discusser sends any kind of chat message, the Controller throws an Exception: ## it.unisa.chatTool.server #it.unisa.chattool.server

java.lang.NullPointerException? at it.unisa.toolplugins.ecf.LEADMessageProcessorECFAdapter.processEvent(LEADMessageProcessorECFAdapter.java:128)

...

Fix

  • In the project it.unisa.coffeeUtilsCore, in the Class LEADMessageProcessorECFAdapter

    • in the method processEvent(Event event), the Controller found XmppConnectionInformation? null when it uses TCP and tries to determine if the message is an XMPP message to discard. Fixed with a check on the field: 

      if ((connInfo!=null) && (connInfo.isController())) {
   String roomID_str=connInfo.getRoomInfo().getRoomID().toExternalForm();
   StringID toContainerID = (StringID) cm.getToContainerID();
   String toContainerID_str = toContainerID.getName(); 
   if(roomID_str.compareTo(toContainerID_str)==0)
      return true;
}

Result

  • The Controller receives presence updates the Control Panel;
  • the Controller is able to open the chat and to send any kind of chat message;
  • the Controller is able to receives chat messages from discussers.

Fixing Quick Chat

Problem: the Discusser was not able to activate the Quick chat

Status on 20 Jan 2011 Changes

  • on the project it.unisa.coffeeClientCore

    • in the package it.unisa.coreplugins.coffeeClientCore.application.start.ui
    • in the class ApplicationActionBarAdvisor?
      • in the method fill, added a try-catch block;
    • in the class RequestQuickChat?
      • in the method requestQuickChat()
      • added throws IOException
        • modified the code to get the id of the server to send the messeages;
    • in the package it.unisa.coreplugins.coffeeClientCore.ecf
    • in the class LEADClient
      • created a new method getTargetID which returns the ID of the server
      • added comments to clarify the use of the methods getTargetID() and getTargetID2()
    • in the package it.unisa.coreplugins.coffeeClientCore.ecf.internal
    • in the class LEADClientSharedObject
      • in the method handleEvent()
      • modified the code to get the id of the server (in the handling of QuickCommMessage?)

  • on the project it.unisa.coffeeDiscusser

    • in the package it.unisa.coffeediscusser
    • in the class ApplicationActionBarAdvisor?
        • in the method fill, added a try-catch block;

  • in the project it.unisa.coffeeServerCore

    • in the package it.unisa.coreplugins.coffeeServerCore.ecf
    • in the method handle requestQuickCommServ()
      • modified the return value to boolean, so that it informs the caller if the handling of the message has been succesful
      • modified the check on the presenceView so that if the filed presenceView is null it do another tentative to get a reference to the presence View; this cahgne is necessary because the initialization of the PresenceView? sometimes get a anull reference due to interleave of thread in the start up of the application;
    • in the method handleQuickCommServ()
      • modified the return value to boolean so that it informs the caller if the handle of mnessage has been successful
    • in the method processEvent()
    • modified so that it returns the value of the handling methods;
    • in the packege it.unisa.coreplugins.coffeeServerCore.ecf.internal
      • in the class ServerSharedObject?
      • wiht the xmpp protocol the method initialize() was called twice (by ecf code, so we can not change this behavior); to avoid to add twice our EventProcessors?, I have added a check to verify if the current shared object has alredy been initialized, in this case it returns before to add event processor again to the shared object.

  • in the project it.unisa.coffeeUtilsCore

    • in the package it.unisa.toolplugins.ecf
    • in the class ECFLEADContext
      • renamed a var
    • in the class LEADMessageProcessorECFAdapter
      • in the method processEvent()
      • added cheks to manage connectione and disconnection events for TCP and XMPP protocols

Fixing reloading of the trace

Changes in the Discusser

Ui of Discusser with XMPP account

Aim
At the start up the CoFFEE client selects a room created from the CoFFEE Server

  • Request to the xmpp server of all the rooms (chat rooms) existing
  • Request on the room XMPP ID of the CoFFEE controller to be set as default recipient for all messages
  • Addition of all the shared object of coffee to chatroom

Status on 29.11.2010
Update of the code 25.01.2011 Currently, the Discusser opens a dialog to select a room, already created on OpenFire Server, and s/he connects to the selected room, adding to the XMPP container the same SharedObject of the CoFFEE Discusser of the generic protocol. At last, the CoFFEE Discusser opens the "the Client Status view", setting as constant string the info of the CoFFEE Controller (eg in LEADClient class, changes of constant strings in the ServerTopic, isConnected(), getServerCoursename(), getServerCoordinator(), getServerClassroom() methods)

  • Discusser application side
    • A new interface has been introduced. In the leadClientStartup class, a new method (xmppClientStart) has been introduced
    • update 25.01.11: Changes: "it.unisa.coffeeDiscusser.ApplicationWorkbenchWindowAdvisor", called a new UI of the Discusser

{{{...

if (CommProtocol?.isTCP()){

if (! leadClientStartup.tcpClientStart()) {

....

}

} if (CommProtocol?.isXMPP()){

if (! leadClientStartup.xmppClientStart()) {

....

}}}

  • Update 25.01.11: _ it.unisa.coffeeDiscusser side_
    • Added new method: In clientStartUp class added a new method to management the UI of the XMPP client and TCP client
    • xmppClientStart() method
      • createXMPPConnectionWizard();
      • openXMPPConnectionWizard();
    • tcpClientStart() method
      • createTCPConnectionWizard
      • openTCPConnectionWizard()
  • Update 25.01.11: Added a new package: it.unisa.coffeeDiscusser.ui.connection:
    • XMPPPConnectionPage:
    • XMPPConnectionWizard
    • in the PerformFinish() method, to create and connect to the selected chat room container from manager

Status on 15.12.2010
Changed the creation of the selected room in "xmppConnect" method of the "LEADClientStartup" class {{{... leadClientStartUp.xmppConnect(selectedRoom);

... leadClientStartUp.xmppAddSharedObject();}}}

  • XMMPRoomPage: list of the rooms created on OpenFire server
  • XMMPSumaryPage

  • Update 25.01.11: in the it.unisa.coreplugins.coffeClientCore.ui.connection

    • Add a newclass XmppRoomPage?

    • Moved the the following code in the new TCPConnectionWizard class of the new package it.unisa.coffeediscusser.ui.connection 

                    instance = this;

        setWindowTitle(Platform.getProduct().getName());
        beaconListener = new LEADServerBeaconListener();

        ImageDescriptor desc = getImgDesc();

        setDefaultPageImageDescriptor(desc);

  • Added a new package: "it.unisa.coreplugins.coffeeClientCore.ecf.xmpp" which contains the classe providing xmpp implementation for coffee

    • XMPPClient class: implements the xmpp functionalities (the same server-side)
    • the same class of Controller.
    • the TestSharedObject class to used only to test the xmpp protocol (now the discusser does not use)
  • Changes: in the LEADClientStartUpInternal() class, a new method (xmppAddSharedObject()) has been added to create and add LEADSharedObject.

    • xmppAddSharedObject(): 

                     ...//Creates the !LeadSharedObject
        xmppClient.addSharedObject(IDFactory.getDefault()
                .createStringID(LEADClientSharedObject.AsynchCoreSharedObjectID),
                leadClientSO);...

The addSharedObject method of the XmppClient class adds the sharedObject to both the gloabal and the chatroom container.

Note UI of Discusser

  • New Interface of Discusser via WizardDialog
    • First wizardDialog to insert login (<nick>@Hostname )) and password
    • Second Dialog shows the list of the rooms created on OpenFire
    • to do: management the info of the each room
    • Third Dialog is the summary page.

Communications

Status on 15.12.2010
The chat tool, client side, works without loop.

it.unisa.coffeeClientCore

  • LEADClient class, introduce the used protocol used from CoFFEE
    • Setting the protocol used with protocolUsed = XMPP
    • Starting CoFFEE (discusser side) with different protocol
    • Modify getTargetID() method used in each tool to create XMPPID for send methods in the BasicSharedObject
    • In the addSharedObject() method introduce different protocol
    • Different way to get UserName in the getUserName() method
  • LEADClientSharedObject
    • no news, delete code not used

  • LEADClientStartUpInternal

    • in the connect() class add protocolUsed = TCP
    • Add a new method xmppConnect()

  • XMMPClient

    • Add a new method makeInstance()
    • Set room information in the ConnectionInformation class

it.unisa.coffeeUtils

  • it.unisatoolplugins.ecf

    • ECFLEADContext(), when client sends a message the toID must be created 

                                 ... if(!connInfo.isController()){
                Namespace connectNamespace  = getSharedObjectContext().getConnectNamespace();
                toID = IDFactory.getDefault().createID(connectNamespace, msg.getTo());}

  • LEADMessageprocessor class

    • when the client sends message, toID is instaceof XMPPID 

                      String roomID_str=connInfo.getRoomInfo().getRoomID().toExternalForm();
            String toContainerID_str;
            if(cm.getToContainerID() instanceof XMPPID)
                toContainerID_str = cm.getToContainerID().getName();
            else{
                StringID toContainerID = (StringID) cm.getToContainerID();
                toContainerID_str = toContainerID.getName(); 
            }

    • to avoid the loop of the messages sending from client 

                                 if(obj instanceof LEADMessage){
                    msg = (LEADMessage) obj;
                    if (msg.isBroadcast())
                        return true;
                }

CoFFEE tools

Chat tool

  • it.unisa.chatTool.client
    • add comment code line in the sendEditingMessage(..) method when set the broadcast flag of the LeadMessage

Presence tool

Status on 14.01.2011

  • Starting an extra step: the connection and disconnection of the each discusser work
  • A demo session with groups steps and all functionalities of the presence Tool.
  • Bug (XMPP protocol): extra step about connection and disconnection
    • #1 When a Discusser disconnects, the presence list is not updated correctly
    • #2 When a second Dicusser connects , the presence list of the tool is not updated correctly
  • Fixed #1

When a Discusser disconnects, (close with red cross), s/he sends a message "exit" to update the presence list of Controller and each other discusser.

  • In the it.unisa.coreplugins.coffeeClientCore.ecf.xmpp package, add the dispose() method, when a Discusser closes the application
  • In GroupPresenceService? class, nothing news, added comment lines

  • Status on 14.01.2011
    When a discusser closes (red cross at the left corner), in the dispose() method of the groupPresenceComposite class, to send Exit Message 

    public void dispose() {         
   service.sendExitMessage();

  • Fixed #2

When the second discusser connects, the presence list is updated changing

In the LEADClient class, the getIdentifier() method changes 

public String getIdentifier(){
if (protocolUsed==XMPP_PROTOCOL){
    str = xmppClient.getClientID().toExternalForm();    
}
  • Testing: functionalities of the presence Tool
    • The management of groups steps of a session doesn't work correcty discusser side
    • Groups and colors for group : Test ok
    • More steps with groups
    • Testing the functionality of the Controller:
    • The client is moved to the new group: Test ok
    • Show the previuos artifact in the groups step.

Bug on Later

In the groups step of a demo session, the control panel of the Controller shows the later in the group #1, indeed, in the view are not in the same group

Image check

http://www.jollydimaro.it/jolly/jolly_home_italiano_files/bullet_nb_box-blue_check.png

Fixing TCP protocol

Status on 11.01.2011
The Discusser works with different protocol

Core side

  • In the it.unisa.coffeeUtilsCore package

    • In the ClientStateManagerEventProcessor class, the sendStateRequest() method checks which protocol is used 

      ...if (!sharedObject.isProtocolXMPP()) {
            //THE FOLLOWING ARE THE LINES OF THE ORIGINAL VERSION OF COFFEE WITH THE PROTOCOL TCP           
        ID connectedID = sharedObject.getSharedObjectContext().getConnectedID();
        RequestStateMessage rsm = new RequestStateMessage(
                        sharedObject.getSharedObjectContext().getLocalContainerID(),
                        sharedObject.getID(),
                        connectedID,
                        currentSequenceNumber);
        sharedObject.sendSharedObjectMessage(connectedID, rsm, false);

    }
   else{
    //the TCP protocol works
    ID controllerID = XmppConnectionInformation.getInstance().getControllerID();
    ID myID = XmppConnectionInformation.getInstance().getUserID();
        RequestStateMessage rsm = new RequestStateMessage(
                        myID,
                        sharedObject.getID(),
                        controllerID,
                        currentSequenceNumber);
    sharedObject.sendSharedObjectMessage(controllerID, rsm, false);
        globalLogger.finer(getLoggerHeader()+"sent state request: "+rsm); //$NON-NLS-1$
,           }

    • In the ECFContext class,

      • In the sendMessage method the check of the protocol used 

                  if (isProtocolXMPP){
                  XmppConnectionInformation connInfo = XmppConnectionInformation.getInstance();
                  if(!connInfo.isController()){
                         Namespace connectNamespace  = getSharedObjectContext().getConnectNamespace();
                    toID = IDFactory.getDefault().createID(connectNamespace, msg.getTo());
                }
                  else
                  toID = IDFactory.getDefault().createStringID(msg.getTo());
        }else
                //Work the TCP protocol
                toID = IDFactory.getDefault().createStringID(msg.getTo());

    • Kind of testing with different protocol 

                      if (isProtocolXMPP)
            tmpBln = XmppConnectionInformation.getInstance().isController();
        else
            tmpBln = getSharedObjectContext().getConnectedID().equals(getSharedObjectContext().getLocalContainerID());

  • In the BasicSharedObject class, the isProtocolXMPP boolean variable is protected

Discusser side

  • On the it.unisa.coffeeDiscusser package, the "ApplicationWorkbenchWindowAdvisor?" class, in the openConnectionWizard() method adding the different protocol to use 

    if (protocolUsed == TCP_PROTOCOL){
    if (! leadClientStartup.clientStart()) {
        System.exit(0);     
        return; 
    }
}
if (protocolUsed == XMPP_PROTOCOL){
    if (! leadClientStartup.xmppClientStart()) {
            System.exit(0);
        return; 
    }
}
...

Testing about groupPresence tool

  • Extra step in the XMPP protocol
    • Discusser side disconnects, the list of presence Controller and each discusser is updated correctly
    • Status on 11.01.2011
      Bug #1 Controller disconnects and each client doesn't close: NOT work correctly, because each discusser, in the XMPP protocol, doesn't receive the disconnection event, when the Controller closes the application.
  • Extra step in the TCP protocol
    • Discusser side disconnects, the list of presence Controller and each discusser is updated correctly
    • Controller disconnects and each client disconnects correctly

The Controller closes each Discusser

  • Fixed #1 (18.01.2011): Close each discusser when the Controller closes with exit in the File menu or by closing the workbench window with the red cross on the top right corner

  • Controller side

    • (Package it.unisa.coffeeController) In the ApplicationWorkbenchWindowAdvisor class, the preWindowShellClose method adds the close of the Controller when clicking on the red cross on the top right of the workbench window, otherwise a because raise exception in the clientDisconnected method of the SessionPlayerStatusLine class 

      LEADServer.getInstance().stop();

  • (it.unisa.coreplugins.coffeeServerCore.ecf.LEADServerPresenceManager package), in the class XmppClient?, added the dispose() method to dispose the xmppContainerClient

  • (it.unisa.coreplugins.coffeeServerCore.ecf package)In LEADServer class, added in the Stop() method the dispose of the XMPP container 

    public void stop() {
        ...
        if(protocolUsed == XMPP_PROTOCOL){
            xmppClient.dispose();
        }

  • (it.unisa.coreplugins.coffeeServerCore.ecf.xmpp; package)In the XmppClient add the dispose() method 

    public void dispose(){
        xmppContainerClient.dispose();
    }

  • (it.unisa.coreplugins.coffeeServerCore.application package), in the SessionPlayerStatusLine class, in the clientDisconnected method, added the following test, because the workbench window is already closed 

    if(leadServer != null){
   String info =authInfo+Messages.getString("SessionPlayerStatusLine._Connected_users2")+ users; //$NON-NLS-1$
...                 
}

  • (it.unisa.coreplugins.coffeeServerCore.ui.actions package), the ExitAction class adding the close of the Controller 

    public void run()
    {...
       LEADServer.getInstance().stop();
}

  • Discusser side

    • (it.unisa.coreplugins.coffeeClientCore.ecf.internal package), the LEADClientSharedObject class, code about the close of the client is moved when the client receives the ServerDisconnectMsg message from Controller 

      else if( (data2= som.getData()) instanceof ServerDisconnectMsg)
 ServerDisconnectMsg closeInfo = (ServerDisconnectMsg) data2;
 serverDisconnection  = closeInfo.isServerDisconnection();
 //In XMPP protocol the disconnection event doesn't occur
    if(serverDisconnection){
        if (LEADClient.getInstance()!=null)
             LEADClient.getInstance().dispose();
        // closing the application
        if (AppOptions.getCloseApplicationOnExit())
             System.exit(0); 
        else
            CoFFEEViewClose();
                    return;
                    }

and added comment block in the following test: 

if(event instanceof IContainerDisconnectedEvent){

            //The Disconnection Message is verified when:
            /**
             * Client application is closed when
             * <ul>
             * <li>Server clicks the window's close button.
             * <li>Server closes application choosing exit from file menu 
             * </ul>
             */
            /*if(serverDisconnection){
                if (LEADClient.getInstance()!=null)
                    LEADClient.getInstance().dispose();
                // closing the application
                if (AppOptions.getCloseApplicationOnExit())
                    System.exit(0); 
                else
                    CoFFEEViewClose();

                return;
            }*/

Discusser side: Communication protocol on command line, Connection Dialog shows options of the selected Room and the info of the "Status View" depend on the selected protocol

Aim 1: allowing to choose the protocol (between TCP and XMPP) from command line;

Aim 2: the dialog of the Discusser shows the following options of the Room: Room Name,Controller Name, Participants

Aim 3: The Client Status shows the following info : Teacher, Room Name and Your name

Status on 24 Jan 2011

Changes about Aim 1:

  • (it.unisa.coffeeDiscusser package), the ApplicationWorkbenchWindowAdvisor class adds the new method to read param form command line: 

    private void setProtocolFromArguments() {
        String args[]=Platform.getCommandLineArgs();
        String prot=null;
        for(int i=0; i<args.length; i++){
            if (args[i].startsWith("-prot=")){
                prot= (args[i].split("="))[1];
                CommProtocol.setProtocolUsed(prot);
            }
        }

Changes about Aim 2:

  • (it.unisa.coffeeClient package), the XMPPConnectionMainPage, XMPPConnectionWizard, XMPPRoomPage, XMPPSummaryPage classes modified to show the options of the selected Room (Room Name,Controller Name, Participants)
  • (it.unisa.coreplugins.coffeeClientCore.ecf package)No News: rename of the XMPPClient in xmppClient
    • Changes in the it.unisa.coreplugins.coffeeClientCore.clientStartUp package, the LEADClientStartUp class

Changes about Aim 3:

  • (it.unisa.coffeeDiscusser.ui.views package)
    • In the DiscusserView class, the getClassRoomLabelText() method is modified to write the label "Room name"
    • (it.unisa.coreplugins.coffeeClientCore.ecf.xmpp package) The LEADClient Class modifies the following methods:
    • getServerCoordinator()
    • getServerClassroom()
    • getServerCoursename()

Bug On User Interface of the Discusser

Status on 14.01.2011

  • When the Discusser connects at first and the Controller is on air later, the UI the Discusser doesn't update.

Discusser side: to do

List of to do to update to the XMPP protocol

  • In the LEADClient class
    • The Status View of the discusser doesn't show the LEADServer info
    • LeadClientConfiguration to management
    • disconnect of the XMPP protocol, and methods (getServerClassRooms etc) to get SERVERInfo data
    • toString

Bugs

  • User Interface of the client
    • The Controller is running, the client connects, when s/he tries to reconnect, the UI of the client (windowsDialog) is not updated

Task Tags

In the Eclipse workspace, management of the task Tags(Window->Preferences, Compiler->Task Tags), create the following Task Tags:

  • TaskIla
  • TaskPina
  • TaskDonato

Testing CoFFEE features

  • Check on geographic network
  • Check on the CoFFEE sessions
  • Check of the step on the fly (extra step)
  • Latecomer
  • Write traces
  • Reload of a trace
  • Check of the Ec-CoFFEE plugin

Documentation

Documentation about SharedOject over XMPP ECF XMPP room and shared object.pdf documentation