CmdrZin
23may09
rev: 24may09

Launching server and client.

Before getting started, was wondering where the log file was. Turned out to be in the user home directory. (which is what logging.properties said)
Changes to logging.properties to put it with the jar file in tutorial/
    handlers=java.util.logging.FileHandler, java.util.logging.ConsoleHandler
    java.util.logging.FileHandler.pattern=tutorial/java%u.log
AND had to add a blank line at the end of the file or it would not execute the
    java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
line to use text instead of XML (default for files)
Still don't know whats causing the 10 MB log file in the db Must be a Berkley DB thing.  

Plan 4

On to Exercice 3
opps..minor bug..if I login with one name, logout, then login with a different name, it gives
an NullPointerException error at
    .getSession(MudUser.java:283)
when I type in a command..hmm...should probably track this down before proceeding.
Code cleanup..moved session declare (397) down near bcast (443) since it's only used there.
Added to flag new user login
                log.info("No User " + name);
to lookupUser() after error catch..might as well use the logger instead of println
hmm..error on startup now in MudMain init..but also spotted a warning in MudObject.java
Changed MudObject.java
    getInventory()
// ManagedReference<MudObject> ref = (ManagedReference<MudObject>)iter.next();
ManagedReference ref = (ManagedReference)iter.next();
MudObject obj = (MudObject)ref.get();
to remove "unchecked" warning.
error on startup..remove cleanup change and added log code.
DOH..was copying jar file from initial ZIP distribution, NOT the current dist folder..(whack head)
all back to normal..put back in cleanup changes and retest logins.
ok..new login info msg goes to log and consol...error in .getSession() if second user tries a command...
Change logging level to =ALL to see what it can tell me...rerun login, logout. login 2nd..try help cmd.
ok..not a good idea to use ALL..tons of timeouts..try FINE (per Java 6 API)..bah..still give task tics each second.
try CONFIG..bunches on congif notes, but stops and sits for input...rerun login, logout. login 2nd..try help cmd.
same error (283) but no enter, exit info..hmm...look at souce for entering()..rats..logs at FINER level..boo...oh well.
Back to the error
    get a .receivedMessage(MudUser:176) -> .parse(MudOject:351) -> .parse(MudOject:399) -> .notifyInterestList(MudObject:427)
    -> .commitCommand(MudUser:218) -> .getSession(MudUser:283) and hits .NullPointerException
has to be caused by MudUser.sessionRef being null...but how??..MudUser comes from the interest list..how does it get on there??
hmm..through regsterInterest()..processHelpCommand()..nothing poping up..try calling getSession() at the begining of receivedMessage()
        ClientSession session = getSession();   // TEST ONLY
this should fail with a NullPointerException..also changed logging back to INFO
hmm..no error there..bad MudObject coming off interest list??..beyond me..so
Change MudUser:commitCommand()
    try moving session declare into if loop just before ByteBuffer declare..HAH..that fixed it..sort of makes sense..but not by much.
It does show the other looged off user sleeping in the room..kinda neat.
now..what did Exercise 3 want to do?..also enhanced my No User log to
    log.info(ex + ":No User " + name);
to consume error catch.
Reading Exercise 3 now..

The part on Data Management gives insight into the ManagedObject / ManagedReference thing. Apperantly, ClientSession has become a ManagedObject which can not be stored in another ManagedObject. So, the rererance has to be stored and the the get() method used to access the object.

"To retrieve a ManagedObject from a ManagedReference, we call ManagedReference.get() and pass in a class of the type we expect the ManagedObject to be."
This is no longer the case. The return is now cast to the class expected instead of the class being sent as a parameter. This was what most of the changes were about.

Woosh..long read. The GOOD thing is at the end they describe how the properties file is used to "build" the world with both generic and custom objects..this looks like a winner..now to copy the code from the exercise into the project.
From the end of Step 1 item r..updating the Rope class and adding comments.
Will only be recording code changes here..see final source for added coments.
Changes to com.sun.sgs.darkmud.trapdoor.Rope.java
    inserted code for parseCommandType()
    inserted code for setUntieTarget()..this will need fixing..MObj/MRef thing...add
    TrapDoor td = (TrapDoor)trapDoorRef.get();
        and use td.getDescription() in string.
    inserted code for setTieTarget()
    inserted code for notifyCommand()
    inserted code for executeTieCommand()
    inserted code for executeUntieCommand()..one line to fixup..Mobj/MRef thing..use
    TrapDoor trapDoor = (TrapDoor)trapDoorRef.get();
From the end of Step 2 item e..updating the Rug class and adding comments.
Changes to com.sun.sgs.darkmud.trapdoor.Rug.java
    inserted code for parseOuterCommand()
    inserted code for executeTakeCommand()..fixup
    TrapDoor trapDoor = (TrapDoor)trapDoorRef.get();
From the end of Step 3 item b..updating the TrapDoor class and adding comments.
Changes to com.sun.sgs.darkmud.trapdoor.TrapDoor.java
    inserted code for notifyCommand()
also had to add
    import com.sun.sgs.darkmud.core.Direction;
Build for error check..everything seems to still work..now to edit the MudMain.properties per Step 4.
but first..I don't think the MudMain.properties file is being used..getting a "you're in a room that shouldn't exist." when I look.
This indicates an error in the properties file..(see note in Step 5)..try copying MudMain.properties into tutorial/conf with the other files.
Nope..still get Dummy room load msg on server launch..try putting it with jar file.
Nope..still get Dummy room load msg on server launch..try putting it command directory.
hmm..still can't find it..hmm...found
    com.sun.sgs.app.root=tutorial/data/7400_Darkstar
in 7400_Darkstar.properties file...maybe should put it in
    tutorial/data/7400_Darkstar
directory..nope..still Dummy room msg.
try adding
        log.info(properties.toString());
to MudMain.java:loadRoom() to find out file path maybe..nope..lots of config stuff though
Says it's using ROOT to find file..no ROOT tag in 7400_Darkstar.properties file...try adding
    ROOT=tutorial/MudMain.properties
to it and putting MudMain.properties in with jar file...nope..try copying
    room.origin.description=an inviting room with stone floor and walls
into 7400_Darkstar.properties file..arrrrrggghhhh...
Still think
    com.sun.sgs.app.root=tutorial/data/7400_Darkstar
is the one..add to .boot and move file to jar area
    ROOT=${SGS_HOME}/tutorial
bah...looked around the Forums..got an idea..replace the 7400_Darkstar.properties file with the MudMain.properties file and
in any items from 7400 prop file as needed...hmm...it seems to have found the properties, but lots of errors...a small progress step..
Commented out all lines after
    room.origin.description=an inviting room with stone floor and walls
still error, but when I log in and "look", I get the room description..hmm..try adding
    room.origin=room.origin
to file above description tag..no effect..oh well..try adding doors, items, and rooms from Step 4 to file...leave all other key=value commented out...ah ha..noticed that the 'name' is not trimmed in loadRoom..so the
       if (!properties.containsKey(name + ".description")) {
doesn't work as intended..try String name = nameNT.trim(); and change input parameter to nameNT..nope..try putting
        log.info(name + ".description");    // TEST ONLY
before if test..just to see if the string is mangled..nope..oh well..the logic works, but can't figure out why test fails..
Sooooo....just changed test to one that's just as valid..
//        if (!properties.containsKey(name + ".description")) {
        if (properties.getProperty(name + ".description") == null) {
so there..leaving in trim change..on to getting the logic flow working...can walk west and east so far..need to enable the other stuff in MudMain.properties file.

Ok, the basic format is desribed in Appendix A

Doors must be named in the format door.<room_name>.<direction_abv>. For example, a door in the starting room that goes south would be named door.origin.s. Objects are name item.<name>, like item.lamp.
Uncommenting everything..Mobj / MRef errors in map.Mapper..hmm..ChannelWrapper error.
Looked at Mapper.java code..nothing obvious..read Lesson 6 in Server API Programming Guide (ServerAppTutorial.pdf) on Channels..looks like this will have to be recoded to use ManagedReference...the Mapper class seems to be triggered by the item.map..try commenting it out .class for now and trace code later..no startup errors now..lets see how it plays..
Doing Exercise 2 Step 2 item 10 directions..error ClassCastException when try to turn on lamp..MudObject.parse(:394)..ah..inventory interator..can use the same code to fix getInventory().
Change MudObject.java
    parse()
//  MudObject obj = (MudObject)iter.next();
    ManagedReference ref = (ManagedReference)iter.next();
    MudObject obj = (MudObject)ref.get();
might as well fix isInInventory() while here...same change.."turn on lamp"works now..
use Appendix C as map..everything works..but no rope in southCavern..recheck Rope code.
nothing obvious..try adding rope to origin room inventory..hmm..shows up there..used on trapdoor.
error when trying to "untie rope"..NullPointerException (Rope.java:254)
hmm..why is trapDoorRef = null ??..I think it should be set to null at the end of the method..try that..
yup..that fixed it..wonder why the rope didn't show up in southCavern??..ah..found it. There were
two inventory entries for the room..the second one didn't have a rope. It overrode the first which did.
I declare Plan 4 a success..