To be honest if Rails is capable of replacing J2EE for your application, then you were working on a toy.
That's all part of the architectural choice: if you're building a toy, then you don't to build it with an industrial class framework.
I've had the experience in reverse: working on a system built on a toy framework which started to fall to pieces the second it became obvious* that it required industrial level tooling. In that case it lead to irreplaceable data loss.
* It was obvious to me from the start that an Enterprise-level framework was required. I got the hint from the 30-page auditing requirements specification.
Oh come on. The evidence that tech like Rails can be used to build non-toy apps is abundant. When shops like Thoughtworks are bailing on Java for Ruby you know you can no longer shut down rational discussion of choices with weasel words like "toy" and "enterprise class". Rails is not the hammer for every nail but it wasn't long ago that doing the "right" thing meant pounding in every nail with a walrus like J2EE.
I think it's interesting that the emphasis on defending something like Rails is based on a comparison to J2EE. My real gripe with Rails is about how it disparages good enterprise-class database practices, and so this is why I'd call it a "toy" system.
That doesn't mean you can't do interesting things with it, but rather that you are essentially talking about an application closely tied to the db schema it stores its data in. The idea of enterprise-class applications sharing their data in a common database is something entirely foreign to (and incompatible with) the Rails way.
This doesn't mean it can't be used in an enterprise environment. For example, you could have a Rails/MySQL app with data imported periodically into a PostgreSQL multi-application database, but I wouldn't call the former "enterprise-class."
> When shops like Thoughtworks are bailing on Java for Ruby
They're swapping Java for Ruby, not Java for Rails.
Ruby is, performance aside, a really nice language. It's certainly possible to build something "enterprise class" in Ruby. Especially as soon as you start treating Ruby as a meta-language and build your own DSLs in it
Rails on the other hand isn't really enterprise grade. It's constrained by Active Record, and the immaturity (and lack of popularity) of the alternatives.
That's all part of the architectural choice: if you're building a toy, then you don't to build it with an industrial class framework.
I've had the experience in reverse: working on a system built on a toy framework which started to fall to pieces the second it became obvious* that it required industrial level tooling. In that case it lead to irreplaceable data loss.
* It was obvious to me from the start that an Enterprise-level framework was required. I got the hint from the 30-page auditing requirements specification.