Packaging Seaside in 8.5

171 views
Skip to first unread message

Randy Nelson

unread,
Sep 20, 2011, 8:58:04 PM9/20/11
to va-sma...@googlegroups.com
Hello,
Are there any documents or general advice to help with packaging a headless Seaside app specifically for 8.5? My service starts and actually opens port 8080, (my default), but the Seaside server does not seem to respond and web page requests result in a 503 "Service Unavailable". I've looked on Instantiations site and did find a discussion at http://forums.instantiations.com/topic-12-5573.html  but that had to do with 8.02. I did try modifying my packaging instructions per the packaging instructions listed in the thread anyway...but that was unsuccessful. 
Of course I've gone through the list of packaging errors and even set rules for any Seaside, Grease, etc... app I can find to not reduce...no luck. Clearly I'm missing something...any ideas?

Thanks
Randy

Marten Feldtmann

unread,
Sep 21, 2011, 3:25:42 AM9/21/11
to va-sma...@googlegroups.com
As I mentioned in my blog - but I did not get any reaction - I think, that with 8.5 the packaging situation with Seaside is not getting easier:

In general you will need the application SeasideCoreApp. This application depends - as a prerequisite - on GreaseVASTCoreApp. GreaseVASTCoreApp has a new prerequisite in 8.5: EmClassDevelopment. With this prerequisite you also depends on the applications EsCodeGeneration and EmLibraryInterface applications. This brings up stuff of the development tools into the packager work, which is  pretty bad stuff and it seems to make it even more harder for the headless packaging stuff.

I've done some demos (actually with 8.03. I tried to switch to 8.5 before that, but gave up in the first run) last weekend for a customer and as a result from this work I got several conclusions (in the field of experimental development):

* before even working on a project: think about (cross-) packaging: That means for me: when starting with a new Seaside programming project under VA, bring up a useless GUI and package this stuff as early as you can. When this works, you may continue with your work. This is of course a pretty bad (wrong) way - but in general you will not have time to solve these packaging problems in the end phase of your demo time and it shows, that VA has big, big problems here.

* with every new Seaside application this pain repeats again and again ...

I urgently request Instantiations

* to introduce an easy packaging system. This means: do NOT reduce all applications found in the prerequisite chain of your application. I assume, that the programmer IS maintaining its prerequisite chain correctly.

* use application name to differentiate between runtime "RunApp" and development time "EditApp" application to help developers to choose the right applications. IBM did this in the early days of this product.


Due to these packaging problems I consider more and more to use Pharo for experimental programming in the Seaside area

Randy Nelson

unread,
Sep 21, 2011, 6:11:03 AM9/21/11
to va-sma...@googlegroups.com
Marten,

Thanks for your excellent response. I really appreciate the time you took to consider my request. This is what I've found.
I thought I had included the prereqs you mentioned. I had, but as I was going through and verifying, I noticed this interesting app, SeasideAdaptersSstApp, that I had not made a prereq. So I added it and repackaged - no luck. So in browsing the image contents for the 100th time, I thought I might as well tell the packager to not reduce SeassideAdaptersSstApp...that didn't work either *but* I did get a new response from my http request: "MessageNotUnderstood: WARenderer>>form....Ha! Now I have something to work with. Sure enough, I browsed image contents and found 2 implementors of form that I thought would be applicable, WAHtmlCanvas and WARenderCanvas. WAHtmlCanvas had been greatly reduced but it looked like it reduced truly what I didn't use and kept what I did. So I really didn't want to force it to include a bunch of stuff I wasn't using, so I told it to not reduce WARenderCanvas...SUCCESS! 

I completely agree with your comments that this shouldn't be as hard as it is...hopefully Instantiations will consider your request to make this process easier.

Well, after a long struggle, I'm back in business. I wish I could have spent that time adding functionality to my app but I grateful that I'm back on track.

Thanks again for your consideration - it was key to finally solving this puzzle. I hope this helps others down the road.

Randy


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/-2Gu31klJEIJ.
To post to this group, send email to va-sma...@googlegroups.com.
To unsubscribe from this group, send email to va-smalltalk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Thomas Koschate

unread,
Sep 21, 2011, 8:57:34 AM9/21/11
to va-sma...@googlegroups.com
And as it turns out, there doesn't even appear to be a reason to prereq EmClassDevelopment in GreaseVASTCoreApp.  At least it shows up as a mismatched prereq.  Possibly it's there to pull in EsCompiler, but there are better applications to use for that.

Tom

Louis LaBrunda

unread,
Sep 21, 2011, 9:35:13 AM9/21/11
to va-sma...@googlegroups.com
I add my vote to Marten's call for some help from Instantiations with packaging Seaside images.  Maybe we can have a simple means of telling the packager to NOT reduce ANY of the Seaside apps.  This should help us get working packaged Seaside apps sooner.  The images may be larger than they would be if reduced well but I for one will trade the smaller image and time it takes to load the larger image for an easier packaging experience.  Those of us who really need the smaller image size can always package the hard way.

Lou

Gabriel Cotelli

unread,
Sep 21, 2011, 10:40:51 AM9/21/11
to va-sma...@googlegroups.com
Hi,
In case it's useful whe are using the following rules in VA 8.0.2 (not tried in VA 8.5 yet) for packaging a Unix Headless image with Seaside.

(Just the seaside related stuff)

Do a "doNotReduceSubApplicationNamed:"
for evey in:
  • GreaseCoreApp
  • GreaseVASTCoreApp
  • SstHttpServletSupport
  • SstWebServicesHttpSupport
  • SstWebServicesHttpsSupport
  • SstWebServicesSoap12App
  • JavascriptCoreApp
  • JavascriptVASTCoreApp
  • JQueryCoreApp
  • JQueryUIApp
  • PrototypeCoreApp
  • ScriptaculousComponentsApp
  • ScriptaculousCoreApp
  • SeasideAdaptorsSstApp
  • SeasideCanvasApp
  • SeasideComponentApp
  • SeasideCoreApp
  • SeasideEnvironmentApp
  • SeasideFlowApp
  • SeasideHTML5App
  • SeasideInternetExplorerApp
  • SeasideRenderLoopApp
  • SeasideSessionApp
  • SeasideToolsCoreApp
  • SeasideVASTContinuationApp
  • SeasideVASTCoreApp
  • SeasideVASTEnvironmentApp
  • SeasideVASTFlowApp
  • SeasideWidgetsApp
Do a  doNotReduceClassNamed: #SstHttpSessionManager
doNotReduceClassNamed: #SstHttpSession

As Thomas already mentioned if EmClassDevelopment is an unneeded pre-requisite of GreaseVASTCoreApp, create a new edition and remove it before doing the packaging.

Sadly the packaging stuff is usually trial and error. 

Regards,
Gabriel

Marten Feldtmann

unread,
Sep 21, 2011, 12:10:56 PM9/21/11
to va-sma...@googlegroups.com
If this list is correct - and some candidates are questionable - it means, that for each Seaside (standalone-) application you want to create, you have to repeat to add these rules to your packaging system.

Do you see, what I mean ? This is boring repeatable work - quite the opposite Smalltalkers want to do in an experimental environment. And each (VA-) developer has to find out lists like the one above and this takes hours ... and now think about cross deployment and headless deployment.

Gabriel Cotelli

unread,
Sep 21, 2011, 1:26:00 PM9/21/11
to va-sma...@googlegroups.com
Marten,
I'm with you on this. If instantiations provide a short guide for packaging the frameworks included in the product, it will save us a lot of time lost in trial and error for packaging 3rd party code. Seaside and Glorp, at least, needs such a kind of thing.

jtu...@objektfabrik.de

unread,
Sep 21, 2011, 2:40:34 PM9/21/11
to va-sma...@googlegroups.com
Marten,

not that I think it's a perfect solution, but you could concentrate all the rules in a Packaging Instruction class and use it as a template / superclass for individual applications. But if it's that simple, Instantiations could probably ship one quite easily, along with the ones that IBM shipped for a long time already.

Joachim

jtu...@objektfabrik.de

unread,
Sep 21, 2011, 2:42:15 PM9/21/11
to va-sma...@googlegroups.com
Gabriel,

thanks a lot for sharing. This list is impressive, and I guess it's going to be real hard work to fine tune these rules. 

I hope we can keep the stuff somewhere (I'll link to it on my blog, both for myself, and for anybody who might be interested in a few months time ... ;-)

Joachim

Marten Feldtmann

unread,
Sep 23, 2011, 4:50:22 AM9/23/11
to va-sma...@googlegroups.com
SstHttpSessionManager and SstHttpSession are defined in SstHttpServletSupport application and therefore should not be reduced due to the first rule.

In earlier experiences I noticed, that sometimes a rule gets into the production system to remove unused constants in PoolDictionaries - and one of these dictionaries were the HTTP status code values.

I just played around again in this topic and I get more or less the same list. But I get warnings during the packaging process, which are not that clear (#CwAppContext references in passive packaging).

Marten Feldtmann

unread,
Sep 23, 2011, 4:53:05 AM9/23/11
to va-sma...@googlegroups.com
And more or less the whole IC packaging process is even more complicated - though I think, that this kind of packaging could be getting more interesting in this server area and distributed computing, multithreading stuff.


Douglas Swartz

unread,
Sep 23, 2011, 7:50:58 AM9/23/11
to Marten Feldtmann
Hello Marten,

I have always felt the complications of IC packaging are more hassle
than they're worth. The biggest problem I have with IC packaging is
all the version checks it does to attempt to guarantee I have a
"consistent" set of ICs. Even if I package a backward compatible base
IC, dependent ICs have to be repackaged to work with it. I would love
for an Instantiations person (I almost said IBM) to tell me that's not
true. Thus I have always packaged single monolothic headless images
for my servers.

All that said, however, IC packaging might simplify packaging a
Seaside app. This is because the reduction rule for ICs is "No
reduction". Because by its nature an IC can't know which methods and
classes will be used, it doesn't any throw away. Memory is much more
generous on modern machines, so the lack of reduction shouldn't really
be an issue, especially as IC packaged apps can share program code
between processes.

--
Doug swartz

Marten Feldtmann

unread,
Sep 23, 2011, 2:11:28 PM9/23/11
to va-sma...@googlegroups.com
I just managed to build my first Seaside ICded application under Windows and actually this was much easier than all that reducing stuff. I will write down some instructions how to do it under Windows, BUT:

Sadly distributing your application via IC's in headless server env. is said not to be a first class distribution way. When building your desktop apps you get those IC's from Instantiations. When building headless server apps you are totally on your own - you have to build ALL IC's (from the Kernel to your application stuff).

Marten Feldtmann

unread,
Sep 26, 2011, 3:03:14 PM9/26/11
to va-sma...@googlegroups.com
Hello Doug,

well I created now several ICs for my headless server and tried to load/unload components on the fly via Seaside code. Loading of the component worked without any problems - but unloading has never worked so far. I get messages, indicating that lots of methods of the SubApplication, Application hierarchy are not there (though I thought I had EmImageSupport included). Any idea ?

By working in this area I wished to have a non GUI to create the ICs without user interaction.

Any idea here ?

Marten Feldtmann

unread,
Sep 26, 2011, 4:23:38 PM9/26/11
to va-sma...@googlegroups.com
Unloading is working too - amazing - now it's time to come to the more interesting things :-))))))

Marten Feldtmann

unread,
Sep 26, 2011, 4:30:21 PM9/26/11
to va-sma...@googlegroups.com
Hello Doug,

I just made this for a very simple component (add a new method and call this method). Created the IC and two dependent ICs were loaded without problems (and I did not recreate them).

Douglas Swartz

unread,
Sep 27, 2011, 9:50:41 PM9/27/11
to Marten Feldtmann
Hello Marten,

Monday, September 26, 2011, 2:03:14 PM, you wrote:

> By working in this area I wished to have a non GUI to create the ICs
> without user interaction. Any idea here ?

I've occasionally thought it would be really useful to be able
to package a headless image from a single mouse click, or from a
command line. It would be great to enable continuous integration. In
the approach I was thinking of you would have to build the passive
image, load the code into it, then do the packaging.

It would certainly be doable, but it's just always seemed like more
work than I wanted to bite off.

--
Doug Swartz

Marten Feldtmann

unread,
Sep 28, 2011, 4:11:15 AM9/28/11
to va-sma...@googlegroups.com
I think the work of Tom Koschate is the way to go ...

Thomas Koschate

unread,
Sep 28, 2011, 10:51:44 AM9/28/11
to va-sma...@googlegroups.com
Unfortunately, as Marten has discovered, the scripted build tools are broken in 8.5, apparently due to some change in the image startup process that I haven't yet figured out.  I've been occupied trying to get my code base to load in 8.5, an effort remarkably hindered by the change to EmSystemConfiguration>>#vaVersion.

Tom

Marten Feldtmann

unread,
Sep 28, 2011, 11:44:22 AM9/28/11
to va-sma...@googlegroups.com
Thomas,

not everything is broken - actually a workaround is posted at your blog.

One can still work with your ideas and I'm now reading all these posting from you and at the end I hope to have some build script to make a headless Seaside application just from Scripts by building IC's.

I had problems with some configuration expressions containing vaVersion. I think (I am not sure) - as I mentioned earlier executing #vaImage throws an exception here in my image - that loading configuration maps, where #vaVersion is used, can make problems.

I tried to load your config map with option required map, but actually nothing happend. Then I changed all configuration expressions to use #imageVersion and then I had no more trouble.


Thomas Koschate

unread,
Sep 28, 2011, 12:04:25 PM9/28/11
to va-sma...@googlegroups.com
Well this is going to be fun.  There have been changes to EmSystemConfiguration>>#startUp as well as EmLibraryInterface class>>#startUp.

Tom

Thomas Koschate

unread,
Sep 28, 2011, 12:08:39 PM9/28/11
to va-sma...@googlegroups.com
The workaround of using a pre-connected image strikes me as a temporary measure - I really want to be able to build from the stock, as-distributed image.

Unfortunately, changing expressions from #vaVersion to #imageVersion doesn't work if one wants to run VA versions in parallel.  Instantiations has provided me with a code fix, but it needs to be in the image before anything is done with config maps.

Tom
Reply all
Reply to author
Forward
0 new messages