problem with package refactoring

Hi,

I wrote a package, deployed it as executable and all worked fine.
Then, I decided to make some refactoring and I got to one little problem: I
can rename all the classes except the SessionManager.
If I rename my DailyLoggerSessionManager to JFRDailyLoggerSessionManager, I
can't save the package.
If I try, i get this message:

--- Message begin ---
10:41:54, lundi 27 décembre 2004: '''C:\Documents and Settings\Joseph
Frippiat\My Documents\Dolphin Smalltalk 5.1\dailyLogger.pak'' - The system
cannot find the file specified.'
File>>signalOsError:
File>>open
File>>open:flags:share:
File>>open:mode:check:share:
File class>>open:mode:check:share:
FileStream class>>open:mode:check:text:
FileStream class>>read:text:
[] in BinaryPackage class>>loadUsing:
BlockClosure>>ifCurtailed:
[] in BinaryPackage class>>loadUsing:
LookupTable>>at:ifAbsent:
BinaryPackage class>>loadUsing:
[] in ClassLocator>>findOrImportForeignClass
WeakLookupTable(SharedLookupTable)>>at:ifAbsent:
[] in ClassLocator>>findOrImportForeignClass
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
[] in ClassLocator>>findOrImportForeignClass
Mutex>>critical:
ClassLocator>>findOrImportForeignClass
ClassLocator>>locateClass
ClassStub>>resolveLocator
[] in ClassStub>>doesNotUnderstand:
[] in Mutex>>critical:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
Mutex>>critical:
ClassStub>>doesNotUnderstand:
[] in Package>>tracePrerequisitesOfImageStripper:
OrderedCollection>>do:
Package>>tracePrerequisitesOfImageStripper:
Package>>tracePrerequisites:
Package>>tracePrerequisites
Package>>calculatePrerequisites
Package>>buildPrerequisiteNames
Package>>prerequisiteNames
Package>>prerequisites
Package>>hasCyclicPrerequisites:
Package>>hasCyclicPrerequisites
Package>>okToSaveOrDeploy
[] in PackageSelector>>okToSavePackage:
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
--- Message End ---

Where does the name "dailyLogger.pak'' come from ?  The package is normaly
saved to "C:\Documents and Settings\Joseph Frippiat\My Documents\Dolphin
Smalltalk 5.1\0-mesFichiers\dailyLogger\DailyLogger.pac".

Thanks

Joseph

Joseph Frippiat wrote:

> If I rename my DailyLoggerSessionManager to JFRDailyLoggerSessionManager,
> I can't save the package.

The problem here is quite complicated, though it should be easy to fix.

I haven't tested this, but I think that if you evaluate:

    p := PackageManager current packageNamed: '...whatever...'.
    p imageStripperBytes: nil.

then that package should start to work properly again.  You will have lost the
deployment settings, though, so you'll have to rebuild those (from Lagoon)
again.

The reason that you have a problem when you rename a SessionManager class is
that:

*) A reference to the SessionManager class (the class object itself) is stored
in the deployment settings object (an Instance of ImageStripper, or some
subclass).

*) The settings object is held in the package in the form of an STBed byte
array (in much the same way as "view resources" are stored as byte arrays).  In
fact, the byte array is held in a variable called 'imageStripperBytes'.  In
that format, references to classes are stored as the string name of the class.

*) When you change the name of the class, Dolphin tries to find and fix all
references to the class, including methods that refer to it by name.  However
it /doesn't/ find the references embedded in STB byte arrays.  (Incidentally,
that means that changing the name of a View subclass can be tricky too).

So once you've changed the name of the SessionManager subclass, your package
(the instance of class Package in the image) is in an odd state, where it
contains a byte array that cannot be un-STBed.

Now, the reason you are seeing the odd error that you did, is that when the
Package Browser saves a package, it first checks the package's pre-requisites
to see if there's a loop (which would make the package unsaveable).  One part
of that check is to see what classes (etc) are referred to by the Package
object's deployment settings, so it attempts to un-STB the byte array.  When
the un-STB process finds a reference to a class that doesn't exist in the image
(the name of a non-existent class), it assumes that this is a use of Dolphin's
built-in ability to load classes dynamically (on demand) from binary data
stored in .PAK files.  So it creates a proxy object for the class which "knows"
how to find the corresponding .PAK file.  So, after all that, the attempt to
find the pre-requisites of the original package will result in the system
attempting to load a non-existent .PAK file for the old name of the
SessionManager subclass.

The reason the above fix works (assuming it does -- remember that I haven't
tested it !) is that it throws away the old STBed byte array, leaving the
package to generate a new, default, one on demand.

One way to avoid the problem, I /think/, would be to have the Lagoon wizard
open on the relevant package while you rename the class, and then to save the
settings back into the package after the rename.  (A similar trick with the
View Composer is useful if you rename or redefine View subclasses.)

BTW, there's no reason why you should have expected problems when renaming a
SessionManager subclass.  It's just One of Those Things that you have to
know...

(To OA: would it be worthwhile adding some sort of warning before renaming
SessionManager subclasses, or renaming/redefining View or ImageStripper
subclasses ?  Maybe there could be class side #warningBeforeRename and
#warnBeforeRedefine methods that normally answered nil, but View, etc, would
override to answer a warning String)

    -- chris

It's working for me.

Thank you very much.

Joseph

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...