SULibrary and File Serving
Locked
 
|
Okay, so I have this terrific Seaside application and I want to deploy it on
a Linux server (Ubuntu "Feisty Fawn"). (Currently, it's being developed on a Vista machine.) When the app is run locally on my Vista box, it runs perfectly. In particular, the "lightbox" effect for #inform: and #confirm: works just fine. HOWEVER, over the Internet, I lose the "lightbox" effect on the Linux server running the exact same app. I believe there is some issue with Apache file serving, Seaside file serving, and SULibrary. I've spent two days trying to figure this out and I'm getting absolutely nowhere. I desperately need help. Here's my httpd.conf file: LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so NameVirtualHost 192.168.1.101:80 <VirtualHost 192.168.1.101:80> RewriteEngine on ProxyRequests off DocumentRoot /var/www ProxyPass /goodsexnetwork http://localhost:9090/seaside/goodsexnetwork ProxyPassReverse /goodsexnetwork http://localhost:9090/seaside/goodsexnetwork ProxyPass /goodsexspace http://localhost:9090/seaside/goodsexspace ProxyPassReverse /goodsexspace http://localhost:9090/seaside/goodsexspace RewriteRule ^/$ http://localhost:9090/seaside/goodsexnetwork/$1 [P,L] </VirtualHost> The httpd.conf file is used with a plain vanilla Apache2 installation with no other modifications. All the CSS files and static images that adorn my application reside in /var/www. Like I said, so far so good, everything runs fine except for the lightbox effect. The Seaside image has been configured for file serving thusly: | ma seaside | HttpService allInstancesDo: [:each | each stop. each unregister]. WAKom stop. seaside := WAKom default. ma := ModuleAssembly core. ma serverRoot: FileDirectory default fullName. ma alias: '/seaside' to: [ma addPlug: [:request | seaside process: request]]. ma documentRoot: FileDirectory default fullName. ma directoryIndex: 'index.html index.htm'. ma serveFiles. (HttpService startOn: 9090 named: 'httpd') plug: ma rootModule (FYI, FileDirectory default fullName --> /home/richard/seaside/ where the Seaside image is.) So the question is, in this environment, how do I get SULibrary to be served up to the Seaside app in order to restore the lightbox effect (if indeed this is the exact nature of the problem)? Remember, it's only an issue when the app is running with Apache over the Internet. (BTW, I don't quite understand where SULibrary resides, but I think it's somehow "embedded" inside Seaside.) Thanks, Richard _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: SULibrary and File Serving
|
|
2007/10/6, Richard K Eng <[hidden email]>:
> Okay, so I have this terrific Seaside application and I want to deploy it on > a Linux server (Ubuntu "Feisty Fawn"). (Currently, it's being developed on a > Vista machine.) When the app is run locally on my Vista box, it runs > perfectly. In particular, the "lightbox" effect for #inform: and #confirm: > works just fine. > > HOWEVER, over the Internet, I lose the "lightbox" effect on the Linux server > running the exact same app. I believe there is some issue with Apache file > serving, Seaside file serving, and SULibrary. I've spent two days trying to > figure this out and I'm getting absolutely nowhere. I desperately need help. > > Here's my httpd.conf file: > > LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so > LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so > LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so > > NameVirtualHost 192.168.1.101:80 > > <VirtualHost 192.168.1.101:80> > RewriteEngine on > ProxyRequests off > DocumentRoot /var/www > ProxyPass /goodsexnetwork > http://localhost:9090/seaside/goodsexnetwork > ProxyPassReverse /goodsexnetwork > http://localhost:9090/seaside/goodsexnetwork > ProxyPass /goodsexspace > http://localhost:9090/seaside/goodsexspace > ProxyPassReverse /goodsexspace > http://localhost:9090/seaside/goodsexspace > RewriteRule ^/$ > http://localhost:9090/seaside/goodsexnetwork/$1 [P,L] > </VirtualHost> > > > The httpd.conf file is used with a plain vanilla Apache2 installation with > no other modifications. All the CSS files and static images that adorn my > application reside in /var/www. Like I said, so far so good, everything runs > fine except for the lightbox effect. > > The Seaside image has been configured for file serving thusly: > > | ma seaside | > HttpService allInstancesDo: [:each | each stop. each unregister]. > WAKom stop. > seaside := WAKom default. > ma := ModuleAssembly core. > ma serverRoot: FileDirectory default fullName. > ma alias: '/seaside' to: [ma addPlug: [:request | seaside process: > request]]. > ma documentRoot: FileDirectory default fullName. > ma directoryIndex: 'index.html index.htm'. > ma serveFiles. > (HttpService startOn: 9090 named: 'httpd') plug: ma rootModule > > > (FYI, FileDirectory default fullName --> /home/richard/seaside/ where the > Seaside image is.) > > So the question is, in this environment, how do I get SULibrary to be served > up to the Seaside app in order to restore the lightbox effect (if indeed > this is the exact nature of the problem)? Remember, it's only an issue when > the app is running with Apache over the Internet. > > (BTW, I don't quite understand where SULibrary resides, but I think it's > somehow "embedded" inside Seaside.) It's at /seaside/files/SULibrary/whatever.js I think that should answer your questions. Note that the URLs are static so they could very well also be served by Apache. Given you have a recent version of Seaside 2.8 you can esily file out all the files by: - go to /seaside/config - configure the files application - configure the SULibrary application - push 'write to disk' You should then have a folder named SULibrary in the folder of your Smalltalk image. There all the JS files of SULibrary should reside. Cheers Philippe > Thanks, > Richard > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Richard Eng
Hi, Philippe. Several comments:
First, I¹m no longer using Seaside 2.8. Damien¹s beta dev image seems to be broken because I can¹t get it to work on Linux (it works just fine locally on my Vista machine, however). So I¹m using the last Squeak 3.9/Seaside 2.7 stable dev image from Damien (dated August). Second, I¹ve done as you suggested, writing to disk all the files from both SULibrary and WAStandardFiles (these are the only two libraries specified in my app config). However, it doesn't help--the problem is still there. Since the app is configured to serve files from /home/richard/seaside, I put the SULibrary files in /home/richard/seaside/files/SULibrary/. When this didn't work, I tried putting them in /var/www/seaside/files/SULibrary/. Again, no luck. I've tried several other permutations but my Seaside app stubbornly refuses to recognize them. Complicating matters, either Apache or Seaside is doing some kind of weird caching that makes it very difficult to determine whether I've got the right solution. I found this to be especially true when trying to get Apache file serving to work with Seaside. After going around in circles with various attempts, Apache file serving suddenly started working for no apparent reason. Frickin' weird! Third, on an unrelated note, I've also noticed that #setFocus on text input fields doesn't work over the Internet (via Apache), either. So I'm experiencing a LOT of Linux server deployment problems. Regards, Richard ------- It's at /seaside/files/SULibrary/whatever.js I think that should answer your questions. Note that the URLs are static so they could very well also be served by Apache. Given you have a recent version of Seaside 2.8 you can esily file out all the files by: - go to /seaside/config - configure the files application - configure the SULibrary application - push 'write to disk' You should then have a folder named SULibrary in the folder of your Smalltalk image. There all the JS files of SULibrary should reside. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Richard Eng
There are no other suggestions?
Here's a nice simplification of the problem that I've been able to replicate: 1) Create a simple Seaside app (or even use Seaside config). Make sure the deployment flag is false. 2) Run the app over the Internet via Apache2 using the following httpd.conf: LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so NameVirtualHost 192.168.1.101:80 <VirtualHost 192.168.1.101:80> RewriteEngine on ProxyRequests off DocumentRoot /var/www ProxyPass /MyApp http://localhost:9090/seaside/MyApp ProxyPassReverse /MyApp http://localhost:9090/seaside/MyApp </VirtualHost> 3) Note that the footer line "New Session Configure Toggle Halos..." is not formatted properly. And if you click on "Toggle Halos", you don't see the little images at the top of the webpage for System Browser, Inspector, and Style Editor. This is because Seaside is unable to find WAStandardFiles, which contains the necessary stylesheets and image gifs. Running MyApp locally on the same Linux server, and bypassing Apache, everything works fine. So, using Apache as I've configured it, Seaside is unable to access its own libraries. Surely someone knows what's going on. This is a pretty serious problem for Seaside. Richard --------- Hi, Philippe. Several comments: First, I¹m no longer using Seaside 2.8. Damien¹s beta dev image seems to be broken because I can¹t get it to work on Linux (it works just fine locally on my Vista machine, however). So I¹m using the last Squeak 3.9/Seaside 2.7 stable dev image from Damien (dated August). Second, I¹ve done as you suggested, writing to disk all the files from both SULibrary and WAStandardFiles (these are the only two libraries specified in my app config). However, it doesn't help--the problem is still there. Since the app is configured to serve files from /home/richard/seaside, I put the SULibrary files in /home/richard/seaside/files/SULibrary/. When this didn't work, I tried putting them in /var/www/seaside/files/SULibrary/. Again, no luck. I've tried several other permutations but my Seaside app stubbornly refuses to recognize them. Complicating matters, either Apache or Seaside is doing some kind of weird caching that makes it very difficult to determine whether I've got the right solution. I found this to be especially true when trying to get Apache file serving to work with Seaside. After going around in circles with various attempts, Apache file serving suddenly started working for no apparent reason. Frickin' weird! Third, on an unrelated note, I've also noticed that #setFocus on text input fields doesn't work over the Internet (via Apache), either. So I'm experiencing a LOT of Linux server deployment problems. Regards, Richard ------- It's at /seaside/files/SULibrary/whatever.js I think that should answer your questions. Note that the URLs are static so they could very well also be served by Apache. Given you have a recent version of Seaside 2.8 you can esily file out all the files by: - go to /seaside/config - configure the files application - configure the SULibrary application - push 'write to disk' You should then have a folder named SULibrary in the folder of your Smalltalk image. There all the JS files of SULibrary should reside. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Richard Eng
Richard Eng a écrit :
> Hi, Philippe. Several comments: > > First, I¹m no longer using Seaside 2.8. Damien¹s beta dev image seems to be > broken because I can¹t get it to work on Linux (it works just fine locally > on my Vista machine, however). It works for me on ubuntu without any problem... Cédrick _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> > First, I¹m no longer using Seaside 2.8. Damien¹s beta dev image seems to be
> > broken because I can¹t get it to work on Linux (it works just fine locally > > on my Vista machine, however). The web images contain incompatible versions of Seaside/Scriptaculous/Magritte/Pier. There should be problems no matter what platform you use. > It works for me on ubuntu without any problem... I never had such problems on Debian, Ubuntu and Gentoo. As I already noted several times in the list I would avoid the use of ProxyPass and ProxyPassReverse directives. It might work, but at least for me it is totally unclear what is going on in what order. I just use plain rewrite rules. Next, did you enable the directive ProxyPreserveHost xor did you specify the correct absolute URLs in the Seaside config? What do the Apache logs say? access_log, error_log, rewrite_log? How do the generated pages look like? Are the URLs ok? Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Richard Eng
If you're talking about Seaside 2.8 beta dev image, I didn't check the
Apache logs. But the generated pages looked fine. The URLs, on the other hand, were totally screwy... Normally, the URLs would have the same IP prefix, eg, http://99.226.61.54/seaside/go?_k=sRoFbbHT&_s=msfIsDkzIWCfriQz But with the beta dev image, when I navigate after the initial home page to other pages in my app, I would get a URL like: http://localhost:9090/seaside/go?_k=sRoFbbHT&_s=msfIsDkzIWCfriQz ...which is what would be used if I were running the web app *locally*. This caused problems because locally the app is unable to access the stylesheets and static image files served up by Apache. When I fell back to the last stable dev image (Seaside 2.7, dated August), the problem went away...the IP prefix was again the same as for the initial home page (ie, 99.226.61.54). Regards, Richard ------- > > First, I¹m no longer using Seaside 2.8. Damien¹s beta dev image seems to be > > broken because I can¹t get it to work on Linux (it works just fine locally > > on my Vista machine, however). The web images contain incompatible versions of Seaside/Scriptaculous/Magritte/Pier. There should be problems no matter what platform you use. > It works for me on ubuntu without any problem... I never had such problems on Debian, Ubuntu and Gentoo. As I already noted several times in the list I would avoid the use of ProxyPass and ProxyPassReverse directives. It might work, but at least for me it is totally unclear what is going on in what order. I just use plain rewrite rules. Next, did you enable the directive ProxyPreserveHost xor did you specify the correct absolute URLs in the Seaside config? What do the Apache logs say? access_log, error_log, rewrite_log? How do the generated pages look like? Are the URLs ok? Lukas _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Richard Eng
I've solved my problems!!! After *much* trial and error (and after *much*
hair-pulling), I've learned a number of important lessons. And just so none of you go through the same hell that I did, I'm going to impart my hard-earned knowledge to you... (Here's the final httpd.conf I'm using: LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so NameVirtualHost 192.168.1.101:80 <VirtualHost 192.168.1.101:80> RewriteEngine on ProxyRequests off DocumentRoot /var/www ProxyPass /seaside/go http://localhost:9090/seaside/go ProxyPassReverse /seaside/go http://localhost:9090/seaside/go RewriteRule ^/$ http://localhost:9090/seaside/go/$1 [P,L] </VirtualHost> It doesn't matter how the Seaside image itself, ie, WAKom, is configured for file serving.) First, despite what Lukas said, you *do* need the ProxyPass and ProxyPassReverse directives in Apache. When I used the rewrite rule by itself, I ran into the same problem I experienced before with the Seaside 2.8 beta dev image, ie, the initial home page rendered correctly and with the correct IP address prefix, but navigating to subsequent pages got me the "localhost:9090" prefix. Second, the #setFocus on text input field problem I alluded to earlier is a direct consequence of the file serving problem, which is the primary focus of this message thread. Third, the whole issue boils down to where, *exactly*, is Seaside looking for the library files. Various blog posts were not entirely accurate, and therefore misleading. My final clue to the mystery came from Seaside config's "file" configuration. This led me to surmise that perhaps the proper Seaside URL for locating its internal library files was /seaside/files/SULibrary/scriptaculous.js, for example. Now the next question was, to what filesystem folder should this URL be based? Since Apache is configured to serve files only from /var/www, it made sense that the Seaside URL should be here. So I moved all the files I extracted from Seaside (WAStandardFiles and SULibrary) to: /var/www/seaside/files/WAStandardFiles /var/www/seaside/files/SULibrary Fourth, in order for the file serving to work properly, the ProxyPass directives must be coded correctly. This means that, for example, ProxyPass /seaside/go http://localhost:9090/seaside/go ...is correct, but ProxyPass /go http://localhost:9090/seaside/go ...is incorrect. "/seaside/go" must match with "localhost:9090/seaside/go". This is where I went wrong in my original httpd.conf file. One final comment: My approach to problem-solving is to distill everything to the simplest basis. While there are several instances of Apache configuration in various Seaside blogs, they tend to be fairly complicated and therefore it is difficult to understand how or why they work. This post simplifies to, and focuses on, the absolute minimum basics. From here, you can get as fancy as you like. It is not good to start off with a complicated httpd.conf configuration. Regards, Richard _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> NameVirtualHost 192.168.1.101:80 > > <VirtualHost 192.168.1.101:80> > RewriteEngine on > ProxyRequests off > DocumentRoot /var/www > ProxyPass /seaside/go http://localhost:9090/seaside/go > ProxyPassReverse /seaside/go http://localhost:9090/seaside/go > RewriteRule ^/$ http://localhost:9090/seaside/go/$1 [P,L] > </VirtualHost> > > It doesn't matter how the Seaside image itself, ie, WAKom, is configured for > file serving.) > > First, despite what Lukas said, you *do* need the ProxyPass and > ProxyPassReverse directives in Apache. see joined file ;) I think it's based on Ramon's conf file... Cédrick > When I used the rewrite rule by > itself, I ran into the same problem I experienced before with the Seaside > 2.8 beta dev image, ie, the initial home page rendered correctly and with > the correct IP address prefix, but navigating to subsequent pages got me the > "localhost:9090" prefix. > maybe ProxyPreserveHost On > Second, the #setFocus on text input field problem I alluded to earlier is a > direct consequence of the file serving problem, which is the primary focus > of this message thread. > > Third, the whole issue boils down to where, *exactly*, is Seaside looking > for the library files. Various blog posts were not entirely accurate, and > therefore misleading. My final clue to the mystery came from Seaside > config's "file" configuration. This led me to surmise that perhaps the > proper Seaside URL for locating its internal library files was > /seaside/files/SULibrary/scriptaculous.js, for example. > > Now the next question was, to what filesystem folder should this URL be > based? Since Apache is configured to serve files only from /var/www, it made > sense that the Seaside URL should be here. So I moved all the files I > extracted from Seaside (WAStandardFiles and SULibrary) to: > > /var/www/seaside/files/WAStandardFiles > /var/www/seaside/files/SULibrary > > Fourth, in order for the file serving to work properly, the ProxyPass > directives must be coded correctly. This means that, for example, > > ProxyPass /seaside/go http://localhost:9090/seaside/go > > ...is correct, but > > ProxyPass /go http://localhost:9090/seaside/go > > ...is incorrect. "/seaside/go" must match with "localhost:9090/seaside/go". > This is where I went wrong in my original httpd.conf file. > > > One final comment: My approach to problem-solving is to distill everything > to the simplest basis. While there are several instances of Apache > configuration in various Seaside blogs, they tend to be fairly complicated > and therefore it is difficult to understand how or why they work. > > This post simplifies to, and focuses on, the absolute minimum basics. From > here, you can get as fancy as you like. It is not good to start off with a > complicated httpd.conf configuration. > > > NameVirtualHost *:80 <VirtualHost *:80> ServerName localhost DocumentRoot /var/www/seaside/ RewriteEngine On ProxyRequests Off ProxyPreserveHost On UseCanonicalName Off # http compression DeflateCompressionLevel 5 SetOutputFilter DEFLATE AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4.0[678] no-gzip BrowserMatch bMSIE !no-gzip !gzip-only-text/html #proxy to seaside if file not found RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f RewriteRule ^/(.*)$ http://localhost:8080/$1 [P,L] # Logfiles ErrorLog /var/log/apache2/seaside.error.log CustomLog /var/log/apache2/seaside.access.log combined </VirtualHost> <Proxy *> Order allow,deny Allow from all </Proxy> <Directory proxy:*> Order allow,deny Allow from all </Directory> ProxyVia Block #<Directory "/var/www/seaside/"> # Options Indexes MultiViews # AllowOverride None # Order allow,deny # Allow from all # </Directory> _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Richard Eng
Nope, didn't help. Still need the ProxyPass directives.
Regards, Richard Cédrick wrote: > When I used the rewrite rule by > itself, I ran into the same problem I experienced before with the Seaside > 2.8 beta dev image, ie, the initial home page rendered correctly and with > the correct IP address prefix, but navigating to subsequent pages got me the > "localhost:9090" prefix. > maybe ProxyPreserveHost On _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: SULibrary and File Serving
|
|
In reply to this post by Richard Eng
I agree with you in starting simple. The problem arrives when you need more.
I find a good idea to take one crisis at the time :) and start simple until you really have to make next step. An ant can cover large distances. In this stage I use rewrite rules, they are a total pain in you know where but when they work they do it very well. I don't need to proxypass at all. Just for reference: ... # proxy by rewritting to seaside if file not found RewriteEngine On RewriteLog /var/log/apache2/dev.ceaec.seaswork.com.rewrite.log RewriteLogLevel 9 <--- only when debuging rewrite rules (0 for production) # 1. Try to find the request as a regular file in the document root # and if exists serve it RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} -f RewriteRule ^(.+) %{DOCUMENT_ROOT}/$1 [L] # 2. This is optional. If not there, see if the url says it's a file resource (by detecting # /applicationFiles* in the path that I artifially introduced in image) # if so, then rewrite it to the libraries in the image RewriteCond %{REQUEST_URI} ^/applicationFiles* RewriteRule ^/(.*)$ <a href="http://localhost:9090/%">http://localhost:9090/%{REQUEST_URI} [P,L] # 3. Send to the application if matches a typical seaside url RewriteCond %{REQUEST_URI} appName*_* [OR] RewriteCond %{REQUEST_URI} index* RewriteRule ^/(.*)$ http://localhost:9090/appName/$1 [P,L] ... Notes: this needs the hack that cuts the /seaside/ in the dispatcher but maybe gives ideas even using /seaside/ in the path. I've only tested this with normal seaside url (not pretty ones) I think this will scale reasonably easily (I mean apache conf only) to hit a proxy of balanced images when needed instead of localhost:9090 attended by one image like I have now. Sebastian Sastre PS: several technologies seems to be solved similarily when using apache as front end so conserve your hair !! > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Richard Eng > Enviado el: Lunes, 08 de Octubre de 2007 13:59 > Para: Seaside - general discussion > Asunto: Re: [Seaside] SULibrary and File Serving > > I've solved my problems!!! After *much* trial and error (and > after *much* hair-pulling), I've learned a number of > important lessons. And just so none of you go through the > same hell that I did, I'm going to impart my hard-earned > knowledge to you... > > (Here's the final httpd.conf I'm using: > > LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so > LoadModule proxy_http_module > /usr/lib/apache2/modules/mod_proxy_http.so > LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so > > NameVirtualHost 192.168.1.101:80 > > <VirtualHost 192.168.1.101:80> > RewriteEngine on > ProxyRequests off > DocumentRoot /var/www > ProxyPass /seaside/go http://localhost:9090/seaside/go > ProxyPassReverse /seaside/go http://localhost:9090/seaside/go > RewriteRule ^/$ http://localhost:9090/seaside/go/$1 [P,L] > </VirtualHost> > > It doesn't matter how the Seaside image itself, ie, WAKom, is > configured for file serving.) > > First, despite what Lukas said, you *do* need the ProxyPass > and ProxyPassReverse directives in Apache. When I used the > rewrite rule by itself, I ran into the same problem I > experienced before with the Seaside > 2.8 beta dev image, ie, the initial home page rendered > correctly and with the correct IP address prefix, but > navigating to subsequent pages got me the "localhost:9090" prefix. > > Second, the #setFocus on text input field problem I alluded > to earlier is a direct consequence of the file serving > problem, which is the primary focus of this message thread. > > Third, the whole issue boils down to where, *exactly*, is > Seaside looking for the library files. Various blog posts > were not entirely accurate, and therefore misleading. My > final clue to the mystery came from Seaside config's "file" > configuration. This led me to surmise that perhaps the proper > Seaside URL for locating its internal library files was > /seaside/files/SULibrary/scriptaculous.js, for example. > > Now the next question was, to what filesystem folder should > this URL be based? Since Apache is configured to serve files > only from /var/www, it made sense that the Seaside URL should > be here. So I moved all the files I extracted from Seaside > (WAStandardFiles and SULibrary) to: > > /var/www/seaside/files/WAStandardFiles > /var/www/seaside/files/SULibrary > > Fourth, in order for the file serving to work properly, the > ProxyPass directives must be coded correctly. This means > that, for example, > > ProxyPass /seaside/go http://localhost:9090/seaside/go > > ...is correct, but > > ProxyPass /go http://localhost:9090/seaside/go > > ...is incorrect. "/seaside/go" must match with > "localhost:9090/seaside/go". > This is where I went wrong in my original httpd.conf file. > > > One final comment: My approach to problem-solving is to > distill everything to the simplest basis. While there are > several instances of Apache configuration in various Seaside > blogs, they tend to be fairly complicated and therefore it is > difficult to understand how or why they work. > > This post simplifies to, and focuses on, the absolute minimum > basics. From here, you can get as fancy as you like. It is > not good to start off with a complicated httpd.conf configuration. > > Regards, > Richard > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
I guess you forgot one important line:
ProxyPreserveHost On > Notes: this needs the hack that cuts the /seaside/ in the dispatcher > but maybe gives ideas even using /seaside/ in the path. No, you can specify an empty base-path in the application configuration. > I've only tested this with normal seaside url (not pretty ones) > I think this will scale reasonably easily (I mean apache conf only) > to hit a proxy of balanced images when needed instead of localhost:9090 > attended by one image like I have now. You should start a blog ;-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: SULibrary and File Serving
|
|
> -----Mensaje original-----
You're right, this is the first part that complements that:
> De: [hidden email] > [mailto:[hidden email]] En nombre > de Lukas Renggli > Enviado el: Lunes, 08 de Octubre de 2007 15:51 > Para: Seaside - general discussion > Asunto: Re: [Seaside] SULibrary and File Serving > > I guess you forgot one important line: > > ProxyPreserveHost On > DirectoryIndex index.html ProxyRequests Off ProxyPreserveHost On ProxyVia On UseCanonicalName Off # http compression to make the site better qualified by Yslow (and experience of course) DeflateCompressionLevel 5 SetOutputFilter DEFLATE AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4.0[678] no-gzip BrowserMatch bMSIE !no-gzip !gzip-only-text/html # some automatic headers expiry for cacheable content ExpiresActive Off ExpiresByType text/css "access plus 2 days" ExpiresByType text/javascript "access plus 2 days" > > Notes: this needs the hack that cuts the /seaside/ in the > > dispatcher but maybe gives ideas even using /seaside/ in the path. > > No, you can specify an empty base-path in the application > configuration. > Mmm I didn't tried without reseting the dispatcher not to use '' instead of 'seaside' but I remember last time I tried without it was not enough (now I don't remember well why). In the next chance maybe I try. > > I've only tested this with normal seaside url (not > pretty ones) > > I think this will scale reasonably easily (I mean > apache conf > > only) to hit a proxy of balanced images when needed instead of > > localhost:9090 attended by one image like I have now. > > You should start a blog ;-) > LOL yeah maybe I should. In any case I'm warming up to do it sooner or later. For now I'll wait a little :) Sebastian > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: SULibrary and File Serving
|
|
> # some automatic headers expiry for cacheable content > ExpiresActive Off > ExpiresByType text/css "access plus 2 days" > ExpiresByType text/javascript "access plus 2 days" > > I think I should turn the expires On :P No seriusly, in the development images that are set in the server I have it off, in the production virtualhost I have them in On (and LogLevel in zero, etc) cheers Sebastian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Lukas Renggli
> > Notes: this needs the hack that cuts the /seaside/ in the
> > dispatcher but maybe gives ideas even using /seaside/ in the path. > > No, you can specify an empty base-path in the application > configuration. > Lukas Renggli > http://www.lukas-renggli.ch Where? This used to be the case but I'm porting over my app to 2.8 right now and no longer see it, and my code blew up while porting when my initialize tried to set the app basePath: '/', which worked fine in 2.7, a hack I relied on. What's the trick in 2.8 to get Seaside generating urls correctly? Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> Where? This used to be the case but I'm porting over my app to 2.8 right
> now and no longer see it, and my code blew up while porting when my > initialize tried to set the app basePath: '/', which worked fine in 2.7, a > hack I relied on. What's the trick in 2.8 to get Seaside generating urls > correctly? It is a application property called #serverPath now, similary to #serverProtocol, #serverHostname and #serverPort. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> > Where? This used to be the case but I'm porting over my app to 2.8
> > right now and no longer see it, and my code blew up while > porting when > > my initialize tried to set the app basePath: '/', which > worked fine in > > 2.7, a hack I relied on. What's the trick in 2.8 to get Seaside > > generating urls correctly? > > It is a application property called #serverPath now, similary > to #serverProtocol, #serverHostname and #serverPort. > > Lukas Ah, excellent, just what I needed, thanks, upgrade is going quite smooth so far. Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |