For development purpose my web app run with:
| handler commitThreshold |
commitThreshold := 65.
handler := AlmostOutOfMemory addDefaultHandler: [ :ex | self halt ].
SessionTemps current at: #'AlmostOutOfMemoryStaticException' put: handler.
System signalAlmostOutOfMemoryThreshold: commitThreshold.
[WAGsZincAdaptor startOn: 8787]
on: AlmostOutOfMemory enable
do: [:ex | ex error: ex description].
For a production environment ....
The Adaptor class should be used directly or should i use a GemServer sublcass like ZnGemServer ?
(maybe my own sublcass of ZnGemServer ??)
I think the method for Production server will be with this:
ZnSeasideGemServer register: 'bpm' on: #(8787 8888 8989).
(ZnSeasideGemServer gemServerNamed: 'bpm') startGems.
"of course exceptions handlers are missing :) "
WAAdmin is still used to register components ?
WAAdmin register: WAOrbeonBackofficeLogin asApplicationAt:'orbeonBackoffice'.
Or there are method in GemServer subclasses ? (i did not found anything)
In the beginning there was WAGsZincAdaptor which was written to be very
similar in functionality to the FastCGI and Swazoo adaptors for
GemStone. WAGsZincAdaptor was to run against a pretty vanilla GemStone
port of Zinc which is to say that the basic structure of Zinc was
preserved. WAGsZincAdaptor as also intended to run using the
WAGemStoneRunSeasideGems class which is called from the
startSeaside30_adaptor script. This was all done around 2013.
In 2014 Sebastian Heidbrink began work on gsApplicationTools which was
intended to a create gem server framework for Zinc that supported all of
the Zinc services beyond Seaside, namely REST and WebSockets. In late
2014, I forked Sebastian's work. At this point in time it became
necessary to do some work to adapt the Zinc servers for running in
GemStone: non-Seaside transaction support, object log-based logging,
interactive server debugging, improved error reporting..
This work ended with two new ZnServer subclasses:
ZnGemServerManagingMultiThreadedServer was the original ZnServer class
designed to be used with GemServers and should work perfectly well with
When working with REST and web sockets, transaction support is not
built-in as it is in Seaside and the
ZnTransactionSafeManagingMultiThreadedServer class was created to be
transaction safe ... the main difference between
ZnTransactionSafeManagingMultiThreadedServer is that the socket
references in the ZnServer code are protected from being persisted
(GsSocket instances cannot be persisted).
A side-effect of making the ZnTransactionSafeManagingMultiThreadedServer
transactionally safe is that continuations can be safely snapped off for
error stacks in the ZnServer code itself --- a feature which can be
useful for Seaside applications as well.
So long story short, the ZnSeasideGemServer class works fine with
Seaside, but continuations cannot be used for the debugging ZnServer
errors. And continuations can be used to debug ZnServer errors with the
> I think the method for Production server will be with this:
> ZnSeasideGemServer register: 'bpm' on: #(8787 8888 8989).
> (ZnSeasideGemServer gemServerNamed: 'bpm') startGems.
> "of course exceptions handlers are missing :)"
> WAAdmin is still used to register components ?
> WAAdmin register: WAOrbeonBackofficeLogin
> Or there are method in GemServer subclasses ? (i did not found anything)
Nothing special needs to be done when registering components with
Seaside for GemServers ... The GemServer classes are used to manage the
http server for Seaside so other than the adaptors nothing must be done
differentls within Seaside itself.