Takai has posted a brief howto on running RoR apps in Glassfish, which Charles and half the free world is linking to. Since I seem to have been in a run of profoundly negative discussions around here lately anyway, allow me to get all Jay Sherman on this one too:
Iiiiit stinks!
Yeah, running Rails apps in JEE servers is cool, and it has the possibility to really open up a new world for Rails, but this seems to be sidestepping one of the things I most wanted to see. Let’s look at the instructions.
1. Copy follow files to
/lib
…
2. Edit/domains/ /conf/domain.xml
…
3. create config file to/domains/ /conf/rails.xml
…
4. generate rails app to/domains/ /applications/rails
Seems to me #1 should be optional and the rest of it should be:
“ant war”
“ant sun-appserv-deploy”
WAR packaging is one of the things JEE has going for it in a big way. I know Tim has talked about PHP and Ruby vs Java at the language level, but he and everyone else on the planet will generally concede that the tooling for Java is second to none, and this seems like part of that. However, anyone who remembers what deployment of webapps was like back in the day, or people who still juggle tgz’s of their apps around between servers for PHP or RoR absolutely adore the simplicity of WAR based deployment. Having Grizzly simply redirect requests to Rails isn’t even on the list of things I would have worried about at this point in the game, and leaving me with another directory structure/non-remote based deployment doesn’t seem like progress.
This was the impression I got as a target for JRuby from the get go, and while I understand it might be slower — come on, if we cared a whole lot about slow at this point, would we really be talking about Ruby at all? :P — just having a template Servlet that can send off requests to the JRoR environment seems like a much better option here.
This concludes this Andy Rooney moment.
WTF? Every time I try to run a Rails application in JRuby it terrifies me that people are actually telling people that this is even remotely ready for primetime. For starters Rails has this rich set of plugins available, less than half of which work with JRuby. I like JRuby, I can't wait for Rails to be ready on JRuby, it runs these days but not very well.
robert, I'm 100% in agreement with the idea that WAR packaging is the way to go, but I seem to always have to copy at least few JARs to my container's lib directory to support container managed resources. I do like WAR as a standard deployment format, but I'm not particularly satisfied with the way one has to package JARs with a particular WAR file (or the Classloader mechanism in general).
I'm actually hoping that Java moves a little closer to the way Rails handles gems. You can either choose to reference a gem installed on a system OR you can freeze a gem within a particular application. I'd like to see Sun evolve the Classloader - something akin to a local "JAR repository", most of us already have that in the form of a ~/.m2/repository directory. (subliminal advertisement: Maven maven maven maven.)
Well, I kind of have a mixed reaction to your comments. I generally like Jars packaged with War files. I like that level of specificity and control. Generally the only thing I ever want in the server's lib directory are database drivers. Any other time, you end up with problems of versioning if you have multiple apps using multiple versions of packages on the same app server.
I think the JSR-277 a stuff kind of maps to what you are talking about -- including a new classloader system. Frankly, I hate it. It seems overly engineered and too complex for my taste. It seems to me that the Maven repo system is perfectly good for 80% of apps right now, and there are just a few things I would add to it (the ability to embed an MD5 sig in your dependency declaration, for instance). GEMS isn't a bad system, really, and within the scope of your Ruby development it might be OK. One thing, though, that strikes me in the enterprise is "I don't want my web server getting software -- ever -- that I didn't explicitly give them. Whether GEMS or JSR-277, I don't like the idea of trusting that my web servers are going to get the right version, or a version at all, of something automagically.
Assuming that sigs can actually side step man-in-the-middle problems, even saying that your app server should be able to reach out and fetch something off the net is scarey, and it also seems like a can of potential worms as there might be something available in an local or dev environment repo that isn't available to the production server. Bam! Deployment rollback or troubleshooting after hours.
I don't want to pile on Charles and the JRuby team. I know they have their hands very very full just getting language compatibility fleshed out right now, but given that Rails seems to be edging slowly to de facto standard, I hope to see RoR pick up some of the really good stuff the Java environment has to offer as well.
Oh come now, deployment to GlassFish is exactly a *day old*. I agree, it should be far easier, but this proves it can be done. Wiring up ant tasks--or my preference, Rake targets--to automate all the nonsense is an absolute no-brainer, and I wouldn't settle for anything less.
It's proof of concept work man, cut some slack :)
Plus, did you even read my blog? I've got a single ant target that builds a *complete Ruby interpreter in a single JAR*. You honestly think I'd settle for anything less than a similar target to build a Rails WAR file?
Come now...you must have patience, grasshopper.
Do you ever re-read your typing before you post it????
It's proof of concept work man, cut some slack :)
I understand that much, but it seems like proof of concept in the wrong direction :P
Replacing AsyncWeb with Grizzly isn't what, I think, most people have in mind when they think of Rails in JEE. I don't want Ruby support in the app server, I want my Rails app to be deployable to an app server. That is a subtle difference, but an important one.
Well, rest assured, that's coming too. One step at a time.
aaa
Wait a minute, Ror is a dynamic development language that lets you prototype quickly. It lets you change quickly. If I'm going to use this as a development platform, I want it all laid out on the file system. I want to tweak things about my app and see that they are changed. The key there is that I want to do that without a build/war step.
I'm sure that it won't be long before they'll have an easy war packaging for releasing a rails app. But in the mean time, I don't want to set up a development environment to require that step, it just slows things down.
If I recall, the first steps I ever saw for deploying jsps to a web container started with cd to webapps, mkdir myapp, mkdir myapp/WEB-INF
Well, it's operation has always been suspect, but since the beginning of time we have had deploy-in-place web apps in Java. Just because you *can* deploy as a WAR doesn't mean that is how you have to work during development.