embedding Ruby on Rails

I'm interested in the possibility of deploying Rails in a Java/JEE
environment, as described in Charle's message below.  

If you were to deploy Rails using a "CGI Servlet" approach, using the
FastCGI interface seems the only practical way to go for performance
reasons.

I know that Caucho has a Resin servlet that implements the FastCGI
interface and allows the standard Rails to be plugged in to Resin.  

The problems with the Caucho servlet are that it's closed source and not
free.  Also, I'm not sure that it works outside of Resin.   

Anyone have any experience or recommendations in this area?  Web
searching on my part has not turned up any open source FCGI servlet.

On a somewhat related note, we've open-sourced some code we're calling
Ruby On Spring
(http://thebogles.com/blog/2005/10/more-on-rapid-prototyping-using-jruby
-and-spring/) that allows Spring model and controllers to implemented in
JRuby.  This is of course not the same thing as embedding Rails, but
useful in some circumstances.

Date: Tue, 21 Feb 2006 13:48:24 -0600
From: "Charles O Nutter" <headius@xxxxxxxxxxx>
To: jruby-user@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Jruby-user] JRuby on Rails
Reply-To: jruby-user@xxxxxxxxxxxxxxxxxxxxx

The thought of deploying Rails using a "CGI servlet" has come up in the
past, and I agree it would be the best way to deploy Rails in a typical
Java/JavaEE environment. I can't speak for Tom, but I think the tack
he's taking is that Socket needs work anyway, so WEBrick is as good a
challenge as any to make that happen; having a working Socket will also
allow much of the builtin DB code in Rails to work out of the box,
without JDBC connectors.

However, I do agree with the CGI servlet deployment...I can't wait until
I can deploy a Rails app inside an n-server cluster with full failover
and JDBC-based adapters to container-managed connection pools. Too cool.

So then, speaking of JDBC-based adapters...Neither Tom nor I have dug
much into the internals of ActiveRecord adapters, and so we're not sure
what would be required to make this work. How much do you understand of
the implementation of these adapters? Enough to start playing around
with something?

If I were to say how people could best help us get Rails working, it
would be to create scripts that excercise small parts of Rails
independent of the full, running application. For example, a script we
could run that would use ActiveRecord along, or other subsystems on
their own. Running the full end-to-end is illustrative and certainly
calls out bugs quickly, but it doesn't really give us an idea of how
close we are to getting everything working.

Beyond that, I know there's a number of utility scripts within Rails
that handle various parts of generation, administration, updating, and
so on. I am not yet familiar with those scripts, so I'm mostly sticking
to the bits I know. Anyone else trying out these scripts and reporting
successes and failures would be most welcome. You ought even be able to
use JRuby against an existing, pre-generated Rails install to test some
of those additional scripts.

On another note, it's good to know that I'm not just writing those blog
entries for myself. I'll try to keep updating it.

- Charlie
On 2/21/06, Nick Sieger <nicksieger@xxxxxxxxx> wrote:
> Hey guys,
>
> Saw Charlie's post today:
> http://headius.blogspot.com/2006/02/making-progress-on-rails.html
>
> First of all, great news!  Glad to hear you're getting this going.  
> This =
is
> definitely exciting stuff  I thought I'd weigh in with a thought.
>
> Running Rails on WEBrick -- it would certainly be cool to get WEBrick 
> working, but in my mind, there's a potentially easier path that may
avoid
> the Socket and IO issues.   Create a JRubyCGIServlet that would
attempt t=
o
> run Rails as a CGI using JRuby inside Tomcat or another existing 
> servlet container, and then implement a compatibility shim between 
> servlet HttpServletRequest/Responses and Ruby's CGI.rb.  Have you 
> thought of this before?  This is simplifying the problem greatly, so I

> may have overlooke=
d
> something, but it seems like an interesting approach.  This approach 
> woul=
d
> also be much more palatable to existing java shops since you could run

> Ra=
ils
> completely within the existing java infrastructure.
>
> The other major remaining issue I can think of right now of course 
> would =
be
> to implement JDBC versions of the popular database adapters.  It seems

> li=
ke
> you may have to do this somewhat specifically to each database driver 
> sin=
ce
> the DB-specific connection code is usually require'd in by the 
> connection adapter.  The JDBC versions would probably have to simulate

> and replace t=
he
> Ruby versions.
>
> Do you have a running list of the major roadblocks that exist for 
> running Rails?  I'm definitely interested in this enough to 
> potentially carve som=
e
> time in the near future to work on it.  What would it be best for me 
> to start playing with?
>
> Cheers,
> /Nick
>
>




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642