Problem with #sessionReady and #queryEndSession: events

Anyone else have problems with the #sessionReady and #queryEndSession:
events in a deployed application?

I finally got patch level 4, and my deployed application gets
#onSessionReady / #onQueryEndSession: not understood when starting up /
shutting down.

MyRuntimeSessionManager doesn't implement them, but in reading the
source code they shouldn't be sent. The only sender is from the event
handlers set up in
DevelopmentSessionManager>>initializeFromSessionManager:. Now it _looks_
like DevelopmentSessionManager>>retire will remove those event
subscriptions when called from SessionManager class>>installNew called
from ImageStripper>>installRuntimeSessionManager.

But, after a bout of debugging the stripping process I think I see
what's going on. (Boy is that painful -- best I could seem to do was to
sprinkle " Notification signal: 'Got here' " type statements around, and
peruse the stripper log after it finished).

It seems that that Development System gets stripped (as it should),
which means that by the time #installRuntimeSessionManager gets executed
the DevelopmentSessionManager>>retire method is no longer around, and so
the events end up being transferred to MyRuntimeSessionManager.

Ah ha! I just found out why perhaps no one else has had this problem.
I'm actually using a subclass of DevelopmentSessionManager. (It just
extends command line processing to possibly fileIn: some files -- allows
for running scripts from DOS batch files (but that's beside the point)).

The ImageStripper>>stripRedundantPackagesNotifying: method adds
"SessionManager current" to its package manager with the comment "We
don't want to uninstall the DevelopmentSessionManager until it has been
replaced by the run-time session manager". So that seems to handle
things in the normal situation. But for me, it's protecting
MyDevelopmentSessionManager but not DevelopmentSessionManager.

Should this last be changed to support DevelopmentSessionManager
subclasses? A DevelopmentSessionManager subclass should be okay in
general, shouldn't it? At least I've not noticed any problem with using
the subclass until now.

There's a couple possibilities for an immediate work-around. 1) switch
to a standard DevelopmentSessionManager before stripping the image. or
2) implement #onSessionReady and #onQueryEndSession: in
MyRuntimeSessionManager to do nothing.

I leave it to OA to say what changes would allow a subclass of
DevelopmentSessionManager to be used cleanly.

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Bill,

> Ah ha! I just found out why perhaps no one else has had this problem.
> I'm actually using a subclass of DevelopmentSessionManager. (It just
> extends command line processing to possibly fileIn: some files --
> allows for running scripts from DOS batch files (but that's beside
> the point)).

I think you are probably right about why nobody else has had problems. I,
for one, have never even though about subclassing a SessionManager destined
for an executable under anything other than RuntimeSessionManager.

Can you just expand on why you need to do it and might not the easiest way
around it be to copy/paste a few methods from DevelepmentSM  to RuntimeSM
(or refactor them up to SM).

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian Bartholomew wrote:
> I think you are probably right about why nobody else has had problems. I,
> for one, have never even though about subclassing a SessionManager destined
> for an executable under anything other than RuntimeSessionManager.
>
> Can you just expand on why you need to do it and might not the easiest way
> around it be to copy/paste a few methods from DevelepmentSM  to RuntimeSM
> (or refactor them up to SM).

Okay. If it was some sort of general script running utility, I'd
probably put what was needed into a subclass of RuntimeSessionManager
and create an executable out of it. But, what I'm really trying to do is
automate things within the development environment itself.

First use is to take take my starting image (which is just a clean OA
image with MyDevelopmentSessionManager and its override of #main loaded)
which will run the script to generate and save my working image. It
files in patches, installs packages, loads package editions from STS,
sets my preferred development environment settings, and saves the image.

Second use is to start from a fresh working image and run unit and
acceptance tests to decide if it's ready to deploy an application.

Third use is to start from a fresh working image and to strip and create
a deployed executable of an application.

Finally, since I have the capability, I end up using it for a few other
miscellaneous scripts. But since they'd work just as well using a
runtime version, I won't bother mentioning them.

I could always achieve the same functionality by patching
DevelopmentSessionManager instead of subclassing. Perhaps that would be
a safer choice.

Ideally, I'd like to see OA change DevelopmentSessionManager #main,
#handleOpenArguments or #open: to handle "script" files specified on the
command line to do a #fileIn: on them. Then I could use the stock image
to do my thing.

-Bill

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Bill,

> Ideally, I'd like to see OA change DevelopmentSessionManager #main,
> #handleOpenArguments or #open: to handle "script" files specified on the
> command line to do a #fileIn: on them. Then I could use the stock image
> to do my thing.

I'm pretty certain that I do not understand what you are trying to do, but
based on a few things you've mentioned, I have a couple of suggestions that
might help.  First, are you aware of prestart.st?  Rather than stripping,
you could have one session write a prestart file, and the next use it - or
does prestart.st get filed in too early?

The other thing you might do is use a trick similar to my batch deployment
wizard.  IIRC, I have _not_ released it as a goodie, only because it needs
to be separated from some things that I can't release.  Eventually, I plan
to refactor and move the "bad" stuff into a subclasss, allowing me to
release the base.  Until then, I would be happy to file out parts that are
ok to release.  Making a long story short, it includes a shell that when
open at image start, along with a few other conditions (non-trivial
selection, etc.) advances its selection (like SuiteBuilder) and then deploys
an executable.  Hence it can then be launched from a batch file, unlike the
original SuiteBuilder.  Interested?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:
> I'm pretty certain that I do not understand what you are trying to do, but
> based on a few things you've mentioned, I have a couple of suggestions that
> might help.  First, are you aware of prestart.st?  Rather than stripping,
> you could have one session write a prestart file, and the next use it - or
> does prestart.st get filed in too early?

I had looked at it before (probably when I created
MyDevelopmentSessionManager). As you point out, it does get processed
quite early in the start up process. Also the need to copy the real
script file into prestart.st (and then to remove it) would complicate
its usage. But the real kicker is that it prompts with a message box to
confirm the filing in of prestart.st. Which is probably a good thing in
general for a early startup file. My guess is that its usage is intended
as a hook to get in and do things, for example, to an image that has
otherwise been hosed. But the prompt rather gets in the way for use in
automated batch scripts.

I don't quite get what this does. But as it seems geared toward
deploying an executable, it might handle one of my development system
automation issues, but not the other two. Thanks anyway.

The slight change to DevelopmentSessionManager that I've used works just
fine. It's just that with the 5.1.4 doing it via a subclass brought up
these new issues.

-Bill

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA