Deployment Weirdness

Hi All,

I deployed an application by following the suggested strategy of
creating a new RuntimeSessionManager subclass that instantiates the
application as part of its start-up processing. This is done by
overriding the #main method.

However, the mainShellClass method that return the name of my presenter
shell does not open. As a test, I re-deloyed the app with the
application open in the dev environment. No changes were made to the
depolyment configuration.

At runtime, the application opens up two shell windows. One being the
shell that was open during deployment, the other being opened as a
result of image startup via the main method.

Has anyone experienced this under D6? Under D5, I have not seen this
problem. Other things considered, I will be checking the depolyed app
via the Executable Browser to see what could be causing this behavior.

Under Dolphin Smalltalk, deployment is straight forward and I have
deployed apps under D5 without issue. At this point in time, I am at
loss for what could be causing the main shell class not to open.

Thanks,


Pax

After reviewing the deployed app using the Executable Browser, I found
no missing classes or methods. I still don't have a clue as to what
could be causing the main shell class not to open.

However, the work-around for this issue is simple. I removed the #main
method from my session manager class along with #mainShellClass class
method. To open the main shell or presenter for the application, I
implemented #tertiaryStartup instead.

MyAppSessionManager>>tertiaryStartup

super tertiaryStartup.

MyPresenterShell show


#tertiaryStartup is called by the SessionManager singleton instance via
the ProcessScheduler when the image fires up.
Now the application starts up as expected and works as expected. It
would be interesting to find out was was causing the previous problem
of the main shell class not opening. But for now, its on with the dev
process.

Anyway, thanks for the help ;)

Pax

Pax,

> Anyway, thanks for the help ;)

<g>


> MyAppSessionManager>>tertiaryStartup
>
> super tertiaryStartup.
>
> MyPresenterShell show

I /suspect/ that what might be happening is that your main shell is taking too
long to start up, and that Dolphin's automatic default behavior (to exit if
there is no top-level window showing when Windows signals idle-time has
started) is causing it to exit prematurely.  If you search the archives for
messages about SessionManagers and #hasActiveServers then you should find more
details.

BTW, looking over the SessionManager implementation before writing this, I
discovered that OA have added a #sessionReady notification (triggered after the
splash screen, if any, has gone away).  I (and others) asked for that some time
ago, but I hadn't realised that my wish had been granted until I looked at
GUISessionManager>>tertiaryStartup.  So my thaks to you /and/ OA.

    -- chris

Pax,

> However, the work-around for this issue is simple. I removed the #main
> method from my session manager class along with #mainShellClass class
> method. To open the main shell or presenter for the application, I
> implemented #tertiaryStartup instead.

FWIW, I've recently been deploying a lot of different apps using D6 and have
never had a problem with the shell not openeing.  I have to admit that I
don't use either a class or instance side #mainShellClass method though - my
#main usually just reads "MyShell show"

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Pax,

> After reviewing the deployed app using the Executable Browser, I found
> no missing classes or methods. I still don't have a clue as to what
> could be causing the main shell class not to open.

Just an idea: are you deploying from a fresh image? That is, one that
hasn't been used for development over a period of time. Often with
strange deployment problems the first line of attack is to create a
fresh image, load your packages up and then deploy again.

Best regards

Andy Bower
Dolphin Support
www.object-arts.com

Ian,

your implementation of the #main method is similar to my implementation
of #tertiaryStartup. Both methods perform the same function; to open
the presenter shell instance.

As far as the image is concerned, I deployed from a working image not a
fresh image. Andy, I will follow your suggestion and load up all my
packages into a fresh (virgin) image and initiate deployment again. I
deployed from the working image in order to test and check screen
realestate the shell, and plugin behavior for my application on a
tablet pc. Fortunately, all is well with the deployed exe on this
platform.

Personally, I don't believe there is a problem with the startup process
for D6. It may be the fact that I deployed from a "working image" or as
Chris suggest, the main shell is taking too long to open.

However, the main shell is a simple construct with a pluggable
container which renders specific views based on the users selection.
This is the part that seems puzzling as the main shell when opened,
doesn't have to show any specific application view.

Thanks for the comments and tips. I will check and re-check my image,
packages and manifest for possible problems. For debug output, I have
overridden #unhandledException: in an effort to get output for any
runtime app errors.


Regards,


Pax