Deployment and Maintenance
- 1. How to exclude applications from the Seaside main dispatcher?
- 2. How to deploy Seaside Cincom Smalltalk behing Apache?
Before deploying for production, it is not a bad idea to remove from the Seaside dispatcher all those applications that are not strictly needed. Otherwise, users may accidentally enter the "counter" or the "store" demo applications.
First of all, you will have to explicitely designate those Seaside applications that are deployed. This is achieved by re-implementing the
#isDeployed class method in the root component of the deployed applications. By default, this class method answers
false, only the dispatcher editor ("config") and the dispatcher navigator ("browse") answer
Then, to remove applications from the Seaside dispatcher, evaluate the following:
WADispatcher default trimForDeployment.
This will remove all those applications that answer
false to message
You can run Seaside under Cincom Smalltalk behind Apache using either the the CGI gateway or the CGI Perl Interface.
There is however some potential difficulties to take into consideration. By default, Seaside is designed to use only one
WADispatcher object and the
WADispatcher object has a hard-coded base URI. Therefore, if you start your image, access Seaside through TinyHttpServer, then access Seaside through Apache, the access through Apache should fail because the
WADispatcher object has been initialized with the TinyHttpServer URI and does not recognize the Apache URI.
For instance if the first Seaside visitor comes in through TinyHttpServer with a request for ’seaside/go/counter’, the
WADispatcher base path will be ’seaside/go’. When another visitor comes in through Apache with a request for ’cgi-bin/Cincom Smalltalk.pl/seaside/go/counter’, Seaside uses the REQUEST_URI environment variable and the
WADispatcher does not find any match.
The problem would be solved if the Apache request would come with REQUEST_URI equals to ’seaside/go/counter’. This might be possible by modifying the perl script so that it modifies the REQUEST_URI variable before transfering the HTTP request to Cincom Smalltalk.
This issue was solved differently by implementing the concept of alternate servlet. See the Seaside mailing list post.
With this concept there are two SeasideServlet instances rather than just one. Each instance has its own separate
WADispatcher object. As a result you may serve Seaside applications through two different base URIs.
The alternate servlet support has been included in VW 7.3.
The parcel for alternate servlet support is inside the BonusPack folder and is named SeasideShortPath. You will need to use a different URI when coming through Apache, something like for ’/cgi-bin/Cincom Smalltalk.pl/counter’ rather than for ’cgi-bin/Cincom Smalltalk.pl/seaside/go/counter’. With the later, Seaside would attempt to use the default servlet and would fail. With the former, it will drop into the alternate servlet and initialize a new
WADispatcher with the right base path. Having explained all this, I believe that the best solution will be to have multiple
WADispatcher objects available for the SeasideServlet providing support for multiple channels into Seaside.