Hi all, The Rails book talks about running Rails under Apache, but is there a (relatively) easy way to deploy it to either Tomcat or JBoss? Is the CGI servlet the only option? Thanks, Ken -- Kenneth A. Kousen, Ph.D. President Kousen IT, Inc. <http://www.kousenit.com> http://www.kousenit.com <mailto:ken.kousen@kousenit.com> ken.kousen@kousenit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060104/958369e3/attachment-0001.html
Only Java applications can be deployed to Tomcat and JBoss. On 1/4/06, Ken Kousen <ken.kousen@kousenit.com> wrote:> > Hi all, > > > > The Rails book talks about running Rails under Apache, but is there a > (relatively) easy way to deploy it to either Tomcat or JBoss? Is the CGI > servlet the only option? > > > > Thanks, > > > > Ken > > > > -- > > *Kenneth A. Kousen, Ph.D.* > > President > > *Kousen IT, Inc.* > > http://www.kousenit.com > > ken.kousen@kousenit.com > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-- Blog >>> http://spaces.msn.com/members/skyincookoo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060105/e1062b9a/attachment-0001.html
Sky Yin wrote:> Only Java applications can be deployed to Tomcat and JBoss.Thats not entirely through, there are also bridges one can use to get PHP working, for example, wich then runs in fastcgi mode and is contacted by a servlet. It should be possible to construct such a bridge also for ruby - or is there anything like this already on the web? -- Posted via http://www.ruby-forum.com/.
Gregor Melhorn wrote:> Thats not entirely through,entirely true, ouch... -- Posted via http://www.ruby-forum.com/.
> > Thats not entirely through, > > entirely true, ouch...Well... for all practical purposes, it is true. But, technically, you could use Tomcat''s webserver and CGI capabilities -- at least this was true the last time I checked (v4). We''d be hard-pressed to find anyone using this in a production environment though...
That''s interesting. One of the big reasons to use J2EE is that servlets scale much better than CGI scripts because only a single instance of each servlet is used to service all requests. Does that mean that using Rails with Apache is going back to the CGI approach? The Rails book lists FastCGI as an alternative to CGI. Does that change the situation? Most of the clients I''ve worked with are already set-up to use one of the major J2EE application servers, like WebSphere, WebLogic, or JBoss. Assuming they already use a separate web server (i.e., Apache), how do you deploy production Rails applications in those environments? Do people use the FastCGI approach? I seriously doubt any of my clients are going to be interested in replacing their existing web servers. I freely admit that it''s likely I''m missing something, since my background is obviously Java and I''ve only just begun my journey toward Rails. Any insight would be appreciated. Thanks, Ken -- Kenneth A. Kousen, Ph.D. President Kousen IT, Inc. http://www.kousenit.com ken.kousen@kousenit.com -----Original Message----- From: rails-bounces@lists.rubyonrails.org [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Dean Matsueda Sent: Wednesday, January 04, 2006 8:16 PM To: rails@lists.rubyonrails.org Subject: RE: [Rails] Re: Rails on Tomcat or JBoss?> > Thats not entirely through, > > entirely true, ouch...Well... for all practical purposes, it is true. But, technically, you could use Tomcat''s webserver and CGI capabilities -- at least this was true the last time I checked (v4). We''d be hard-pressed to find anyone using this in a production environment though... _______________________________________________ Rails mailing list Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails
Ken Kousen wrote:> The Rails book talks about running Rails under Apache, but is there a > (relatively) easy way to deploy it to either Tomcat or JBoss? Is the > CGI servlet the only option?Sounds like a relatively easy way to set yourself up a very bruised forehead. First, running Rails in CGI mode is anticlimatic at best. The setup of the Rails environment on each request would be painful. So, you''d really want some Servlet that ran FCGI. And, even if one exists (which, quite frankly I don''t know if one does), just thinking about it makes my head hurt. Setting up Rails in a production environment can be challenging enough. Even if you get it working, it''s not the right tool for the job. If you''re just trying to dink around with Rails, use WEBrick. If you want to put something up for real, use Lighty[1] or Apache. If you want to set up a server with some requests going to Rails and other requests going to some Servlets, set up Apache with connectors to send some requests to Tomcat and others to Rails via FCGI.> That''s interesting. One of the big reasons to use J2EE is that servlets > scale much better than CGI scripts because only a single instance of each > servlet is used to service all requests. Does that mean that using Rails > with Apache is going back to the CGI approach? The Rails book lists FastCGI > as an alternative to CGI. Does that change the situation?FastCGI != CGI. The ability to have a long running program serve multiple requests is _exactly_ what FastCGI[2] is all about. Bottom line: This is a very different world than the Servlet one, especially when it comes to setting things up. Lots of learning and grappling with some very different concepts has to be done to make the transition well. But don''t worry, it can be done. [1] http://duncandavidson.com/essay/2005/12/railsonlighty [2] http://cryp.to/publications/fastcgi/ -- Posted via http://www.ruby-forum.com/.
I agree with everything said here, but for reference, an FCGI does exist: http://www.caucho.com/resin-3.0/thirdparty/php.xtp#Configuring-FastCGIServlet Might actually work well, anyone try it? On 1/4/06, James Duncan Davidson <james@duncandavidson.com> wrote:> > Ken Kousen wrote: > > > The Rails book talks about running Rails under Apache, but is there a > > (relatively) easy way to deploy it to either Tomcat or JBoss? Is the > > CGI servlet the only option? > > Sounds like a relatively easy way to set yourself up a very bruised > forehead. First, running Rails in CGI mode is anticlimatic at best. The > setup of the Rails environment on each request would be painful. So, > you''d really want some Servlet that ran FCGI. And, even if one exists > (which, quite frankly I don''t know if one does), just thinking about it > makes my head hurt. Setting up Rails in a production environment can be > challenging enough. > > Even if you get it working, it''s not the right tool for the job. If > you''re just trying to dink around with Rails, use WEBrick. If you want > to put something up for real, use Lighty[1] or Apache. If you want to > set up a server with some requests going to Rails and other requests > going to some Servlets, set up Apache with connectors to send some > requests to Tomcat and others to Rails via FCGI. > > > That''s interesting. One of the big reasons to use J2EE is that servlets > > scale much better than CGI scripts because only a single instance of > each > > servlet is used to service all requests. Does that mean that using > Rails > > with Apache is going back to the CGI approach? The Rails book lists > FastCGI > > as an alternative to CGI. Does that change the situation? > > FastCGI != CGI. The ability to have a long running program serve > multiple requests is _exactly_ what FastCGI[2] is all about. > > Bottom line: This is a very different world than the Servlet one, > especially when it comes to setting things up. Lots of learning and > grappling with some very different concepts has to be done to make the > transition well. But don''t worry, it can be done. > > [1] http://duncandavidson.com/essay/2005/12/railsonlighty > [2] http://cryp.to/publications/fastcgi/ > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060105/a798199e/attachment-0001.html
Okay, that makes sense. It really comes down to using a web server with plugins for the dynamic elements. I do that in the Java world anyway, but mostly for load balancing and other administrative purposes. I''ve often thought separating the web server from the application server was sometimes too many layers of indirection for small systems. It seems now that I need an app server for the J2EE components and something else (FastCGI, I guess) for the Rails applications. A J2EE app server does more than just executing the servlets and JSPs. It also provides a wide range of services, like naming, security, transactions, resource pooling, and all the other so-called enterprise services that the big vendors charge so much for. (Other than open source JBoss, but you get the idea.) It sounds to me, then, that there is no "Rails Application Server". Instead, the Rails framework builds those services into each web application individually. That must be what convention over configuration is all about. FastCGI handles the multithreading of web apps, but everything else is in the framework itself. It''s hard not to feel like we''re going backwards there, but the gain in simplicity and productivity is wonderful. I do wonder, though, whether that means there will eventually be a market for a Rails Application Server, though. Thanks for your help, Ken Kousen James Duncan Davidson wrote:> Ken Kousen wrote: > >> The Rails book talks about running Rails under Apache, but is there a >> (relatively) easy way to deploy it to either Tomcat or JBoss? Is the >> CGI servlet the only option? > > Sounds like a relatively easy way to set yourself up a very bruised > forehead. First, running Rails in CGI mode is anticlimatic at best. The > setup of the Rails environment on each request would be painful. So, > you''d really want some Servlet that ran FCGI. And, even if one exists > (which, quite frankly I don''t know if one does), just thinking about it > makes my head hurt. Setting up Rails in a production environment can be > challenging enough. > > Even if you get it working, it''s not the right tool for the job. If > you''re just trying to dink around with Rails, use WEBrick. If you want > to put something up for real, use Lighty[1] or Apache. If you want to > set up a server with some requests going to Rails and other requests > going to some Servlets, set up Apache with connectors to send some > requests to Tomcat and others to Rails via FCGI. > >> That''s interesting. One of the big reasons to use J2EE is that servlets >> scale much better than CGI scripts because only a single instance of each >> servlet is used to service all requests. Does that mean that using Rails >> with Apache is going back to the CGI approach? The Rails book lists FastCGI >> as an alternative to CGI. Does that change the situation? > > FastCGI != CGI. The ability to have a long running program serve > multiple requests is _exactly_ what FastCGI[2] is all about. > > Bottom line: This is a very different world than the Servlet one, > especially when it comes to setting things up. Lots of learning and > grappling with some very different concepts has to be done to make the > transition well. But don''t worry, it can be done. > > [1] http://duncandavidson.com/essay/2005/12/railsonlighty > [2] http://cryp.to/publications/fastcgi/-- Posted via http://www.ruby-forum.com/.
Ken Kousen wrote:> I''ve often thought separating the web server from the application server was > sometimes too many layers of indirection for small systems. It seems > now that I need an app server for the J2EE components and something else > (FastCGI, I guess) for the Rails applications.I agree about not wanting layers of indirection for small systems. But if you''re to the point of needing to integrate J2EE components and Rails and whatever else onto a server, you''re outside the scope of a small system. For example, in a Rails-only setup, you could just run Lighty with the right config and be done with it. It''ll manage everything for you. One process to start, one to kill. But, when you start mixing things, it gets complicated. For example, I''ve got a server on which i serve Subversion repositories as well as some Rails apps. In that case, I use Apache and do enough configuration voodoo to make it work well. At this point, there''s no "easy". Just "possible".> A J2EE app server does more than just executing the servlets and JSPs. > It also provides a wide range of services, like naming, security, > transactions, resource pooling, and all the other so-called enterprise > services that the big vendors charge so much for.Oh, I''m quite familiar with what a J2EE-compliant implementation provides.> It sounds to me, then, that there is no "Rails Application Server". > Instead, the Rails framework builds those services into each web > application individually. That must be what convention over > configuration is all about. FastCGI handles the multithreading of web > apps, but everything else is in the framework itself.No, Rails isn''t a server. Rails is a framework. The server is Lighty or Apache or whatever you want it to be (as long as you can configure it up). The framework handles requests that the server forwards to your application. Once you step from development into production, there are many choices of how to deploy your application based on the Rails framework. Over time, I expect that there will be some choices to help ease this. Just as in the early days of using Java Servlets there weren''t a lot of ways to run them except for Jeeves (aka Java Web Server). That changed rapidly as servlets were adopted. We''ve just hit 1.0 of Rails. There''s still some figuring out how things are best done. But, it''s early days still. It''s still somewhat DIY. It''s still a bit of a frontier.> It''s hard not to feel like we''re going backwards there, but the gain in > simplicity and productivity is wonderful.It''s not backwards. Just different. If you were to use a much simplier web application framework built in Java, you''d feel a bit of the same feeling. One data point. -- Posted via http://www.ruby-forum.com/.
Paul Barry wrote:> I agree with everything said here, but for reference, an FCGI does > exist: > > http://www.caucho.com/resin-3.0/thirdparty/php.xtp#Configuring-FastCGIServlet > > Might actually work well, anyone try it?Heh. That''s interesting. I''ve got mad respect for the Caucho Resin guys... Thanks for the pointer. Maybe somebody will give it a spin. -- Posted via http://www.ruby-forum.com/.
James Duncan Davidson wrote:> Ken Kousen wrote: >> I''ve often thought separating the web server from the application server was >> sometimes too many layers of indirection for small systems. It seems >> now that I need an app server for the J2EE components and something else >> (FastCGI, I guess) for the Rails applications. > > I agree about not wanting layers of indirection for small systems. But > if you''re to the point of needing to integrate J2EE components and Rails > and whatever else onto a server, you''re outside the scope of a small > system. For example, in a Rails-only setup, you could just run Lighty > with the right config and be done with it. It''ll manage everything for > you. One process to start, one to kill. > > But, when you start mixing things, it gets complicated. For example, > I''ve got a server on which i serve Subversion repositories as well as > some Rails apps. In that case, I use Apache and do enough configuration > voodoo to make it work well. At this point, there''s no "easy". Just > "possible". >Yup, I get that. I''m going to have to do the same, since I have several Java apps already and want to use Rails in a big way now too.>> A J2EE app server does more than just executing the servlets and JSPs. >> It also provides a wide range of services, like naming, security, >> transactions, resource pooling, and all the other so-called enterprise >> services that the big vendors charge so much for. > > Oh, I''m quite familiar with what a J2EE-compliant implementation > provides. >Sorry, I never meant to imply that you didn''t. If anyone does, it''s you. :)>> It sounds to me, then, that there is no "Rails Application Server". >> Instead, the Rails framework builds those services into each web >> application individually. That must be what convention over >> configuration is all about. FastCGI handles the multithreading of web >> apps, but everything else is in the framework itself. > > No, Rails isn''t a server. Rails is a framework. The server is Lighty or > Apache or whatever you want it to be (as long as you can configure it > up). The framework handles requests that the server forwards to your > application. Once you step from development into production, there are > many choices of how to deploy your application based on the Rails > framework. Over time, I expect that there will be some choices to help > ease this. Just as in the early days of using Java Servlets there > weren''t a lot of ways to run them except for Jeeves (aka Java Web > Server). That changed rapidly as servlets were adopted. >Yes, I understand that. I''m just trying to learn how do deploy to existing servers rather than new ones... and wow, I haven''t thought about Java Web Server in years.> We''ve just hit 1.0 of Rails. There''s still some figuring out how things > are best done. But, it''s early days still. It''s still somewhat DIY. It''s > still a bit of a frontier. > >> It''s hard not to feel like we''re going backwards there, but the gain in >> simplicity and productivity is wonderful. > > It''s not backwards. Just different. If you were to use a much simplier > web application framework built in Java, you''d feel a bit of the same > feeling. > > One data point.I''m sure you''re right. I''m just trying to anticipate the questions from clients who already have a web server (probably Apache or IBM Http Server -- which is of course the same thing) and don''t want to change it just to do Rails development. Thanks again for your help. And by the way, thanks so much for your development of Ant and Tomcat. I can''t even imagine making a contribution of that magnitude. :) Ken Kousen -- Posted via http://www.ruby-forum.com/.
Ken Kousen wrote:> I''m sure you''re right. I''m just trying to anticipate the questions from > clients who already have a web server (probably Apache or IBM Http > Server -- which is of course the same thing) and don''t want to change it > just to do Rails development.The best answer to those questions from your clients is probably to proxy the functionality in. It creates the least impact on an existing setup and lets you run Rails in the best possible way which, right now, is Lighty as far as I''m concerned.> Thanks again for your help. And by the way, thanks so much for your > development of Ant and Tomcat. I can''t even imagine making a > contribution of that magnitude. :)Not a problem. :) -- Posted via http://www.ruby-forum.com/.
Jruby, anyone? -- Posted via http://www.ruby-forum.com/.