Forum: Ruby on Rails Rails on Tomcat or JBoss?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ken K. (Guest)
on 2006-01-05 00:29
(Received via mailing list)
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:removed_email_address@domain.invalid> 
removed_email_address@domain.invalid
Sky Y. (Guest)
on 2006-01-05 02:09
(Received via mailing list)
Only Java applications can be deployed to Tomcat and JBoss.
Gregor M. (Guest)
on 2006-01-05 03:12
Sky Y. 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?
Gregor M. (Guest)
on 2006-01-05 03:13
Gregor M. wrote:
> Thats not entirely through,

entirely true, ouch...
James duncan D. (Guest)
on 2006-01-05 04:12
Ken K. 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/
Paul B. (Guest)
on 2006-01-05 04:45
(Received via mailing list)
I agree with everything said here, but for reference, an FCGI does
exist:

http://www.caucho.com/resin-3.0/thirdparty/php.xtp...

Might actually work well, anyone try it?
Ken K. (Guest)
on 2006-01-05 05:06
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 K.


James Duncan Davidson wrote:
> Ken K. 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/
James duncan D. (Guest)
on 2006-01-05 06:18
Ken K. 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.
James duncan D. (Guest)
on 2006-01-05 06:23
Paul B. wrote:

> I agree with everything said here, but for reference, an FCGI does
> exist:
>
> http://www.caucho.com/resin-3.0/thirdparty/php.xtp...
>
> 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.
Ken K. (Guest)
on 2006-01-05 16:31
James Duncan Davidson wrote:
> Ken K. 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 K.
James duncan D. (Guest)
on 2006-01-05 19:37
Ken K. 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. :)
Guest (Guest)
on 2006-01-06 06:50
Jruby, anyone?
kris (Guest)
on 2006-05-16 23:29
I think JRuby will soon allow Java backends from Rails, inc. Tomcat
This topic is locked and can not be replied to.