Comments on: J2EE Web Frameworks

By: David Crow

David Crow — Wed, 20 Oct 2004 17:39:03 +0000

One option that we’ve been looking at is J2EE unlying engine (Tomcat) and then ColdFusionMX (preferably Blackstone version 7.0), JRuby and Jython. But you’re right, the complexity (development environment, tools, configuration) and development cycles (time = money) is what we are experiencing. It feels like 4 times the code, 6 times the configuration.

Coldfusion is great, we just need something a little more elegant for our non-user driven events and data manipulations. The combination of Fusebox and CFCs has worked really well for most projects, but we need a more robust abstraction and persistance layer. We have been looking at moving a lot of our data access objects into Hibernate objects and continuing to use CFMX as the presentation layer and the controller. But when we start to look at the nice-to-have features (incepetors, validators, workflow, etc.) we have found that other solutions offer more.

Part of our difficulty is addressed in Fusebox 4.x. We need to begin moving away from Fusebox 3.0, but since our latest application has only been live since July a major rewrite is not happening.

We probably need to move from CFMX for Windows to CFMX for J2EE. Currently, the systems administrator does not (and will not allow) any additions to the CLASSPATH on our production Windows 2K3 machine running IIS and CFMX6.1. This has hampered any extensions or augmentation to the existing Coldfusion apps using other technologies.

We’ve tried using a skunkworks approach to add rogue servers and functionality, but since there is no support at the very top for anything that would rock the status quo, it becomes very hard to implement. All of our machines are behind atleast 2 layers of firewalls and are not accessible to the outside world. For the inside world our boxes are only accessible on the same subnet. The servers are controlled by a separate department with separate reporting structures. There are obvious team and organizational issues that dampen our spirits.

However, we seem to have support to move to J2EE and Oracle (9.2), but still in a very locked down, controlled fashion. But we have some support. Moving to J2EE appears to give us the flexibility to do things like Ruby on Rails using JRuby if we choose.

By: Solomon

Solomon — Wed, 20 Oct 2004 17:13:02 +0000

Wow. It’s really too bad that you guys are moving to J2EE from ColdFusion. 4 times the code, 6 times the configuration, and unlimited headaches to boot. I would be really interested in hearing what the business/technical justification is for the move. My team is experimenting with Ruby on Rails, although there is not much in the way of documentation for using it on Windows. From a J2EE prospective, our clients are growing tired of the development cycles, maintenance and resource costs, as thee growing complexity of J2EE. They are looking for robust alternatives to cut cost, PHP, Ruby, Python, we will see.

By: David Crow

David Crow — Tue, 19 Oct 2004 23:57:22 +0000

My IT group has a hard time understanding n-tier development, never mind a scripting language like Ruby for enterprise development. We’ve fought long an hard to move them to J2EE (we were using COBOL, PL/SQL and a little bit of Perl for most projects, not just legacy systems). Their not (enterprise systems) group has gone with the Macromedia product suite, lots of ColdFusionMX, Breeze, Flash Communication Server, etc. This works just fine, but it ties me to a single vendor, and excludes a lot of other (easier, better, faster) solutions to many of the problems.

We’ve had 2-3 major projects that has forced the rest of the IT to understand newer platforms. But for the most part they don’t actually understand, they just follow route directions. So there is no support and no reward for learning new technology.

With JRuby, Ruby on Rails might be back on the list of tools. My staff and I have zero experience with Ruby or Python and a fair bit of experience with J2EE. The Instiki and Basecamp projects are fabulous and we should probably have another look at Ruby.

Any insight into J2EE versus Ruby would be great?

By: David Heinemeier Hansson

David Heinemeier Hansson — Tue, 19 Oct 2004 12:46:43 +0000

I’m sad to hear that Ruby on Rails is out of the race merely because the IT gatekeepers haven’t heard of it. What exactly were their reasoning for shuning Ruby? Couldn’t they get it to compile? Didn’t they even want to try?

Hopefully, you’ll dig deeper for an answer. Maintaining the status que due to ignorance is a terrible way work.