Deployment Help

Hi Forum

I am trying to deploy a Image that contains a basic implemntation of
GLORP.  This image works perfectly in the development environment.
Somewhere in the application the following
is executed:

Client isBehavior

where Client is a Client class.

When I perform Client isBehavior in a Workspace it works and returns
true.

In the deployed application the same line throws a MessageNotUnderstood
exception.

What is the difference and how do I fix it?

Any help welcomed

Regards,
Leon

Leon van Dyk escribió:
I think you have a problem with stipping options.

Try do deploy an exe without stripping anything and take a look of that.

Or you can user the "Executable Browser" tool to open the XML manifiest
to see what happen.

regards bruno

Hi Forum

I found the problem.  The method isBehavior is implemented for Object
and Behavior as loose methods in the package RBRefactorings.  I added
the RBRefactorings manually as a dependent package redeployed the
application and it worked.

My question for Andy or Blair, doesn't the ImageStripper pick up when
loose methods are used and automatically include (not strip out) the
package(s) that implements the loose methods?

Regards,
Leon

Leon,

you would most likely need to create your own ImageStripper subclass to
ensure that certain classes and/or methods are retained during the
stripping process.

My strategy has been to simply add loose methods to the "must not
strip" category. This ensures that specific methods/behaviors will be
retained in the runtime image. Following this process, I have not found
a need to create a specialized ImageStripper class. However, that does
not eliminate the idea of creating such an entity.

I copied the following from the Dolphin Education Centre...

Image stripping is not an exact science. It is possible that the
stripping process may remove too much from the image so that the
resultant application does not execute correctly. This is why we have
provided different stripping options that can be configured by the
Lagoon Deployment Wizard. Unfortunately, since all the development
tools are automatically stripped from a deployed image, tracking down
the source of a problem can prove difficult. For example, a
#doesNotUnderstand error at runtime simply brings up a message box with
no opportunity to invoke the Debugger.

If you experience problems with your application that were not present
in the development environment then you should experiment with one or
more of the following procedures.

1. Re-deploy your application with all of the ImageStripper check box
options turned off. If your application then works correctly try to
isolate which of the options makes the difference by repeated attempts
at re-deployment.

2. Turn on the Write log file option and re-deploy the application.
This generates an XML log file manifest of all the classes and methods
that are removed from the system together with a list of the classes
remaining at the end of the stripping process. The log is sent to a
file with the same name as that of the executable being generated but
with a .XML suffix. You can use the Executable Browser to examine the
contents on this file and this may allow you to isolate the problem.

3. It is possible to further control how the ImageStripper selects
classes and methods to be removed:

· All methods that belong to the category must not strip are forcibly
preserved in the image. If you find that your application is failing
because a particular method has been removed then try adding this to
the must not strip category. This set of categories to maintain is
determined by the ImageStripper>>requiredMethodCategories method.

· Methods that belong to the categories must strip and examples are
forcibly removed from the image. If you find, perhaps by browsing the
executable manifest, that your application is too large and contains
methods that could readily be removed then you can add them to the must
strip category. The method ImageStripper>>notRequiredMethodCategories
determines the set of method categories that are forcibly stripped.

· A number of classes are always retained. These are determined in the
ImageStripper>>requiredClasses method. Adding classes to this set may
be able to alleviate the consequences of occasions when the stripper is
"over aggressive" in its stripping policy.

· You may specify that a number of classes are always removed. This
set is determined by the ImageStripper>>notRequiredClasses method.
Adding classes to this set may allow you to further reduce the size of
deployed image.

If you wish to alter these default strategies then you may choose to
create a new subclass of ImageStripper and override the appropriate
methods. In this case, the Deployment Wizard gives you the opportunity
to install the class of image stripper you wish to use.