Open BlueDragon at cf.Objective()
Vince Bonfanti hosted a Birds of a Feather session this evening where he officially unveiled the
Open BlueDragon project.He walked the (fairly large) audience through
downloading and running the binary distribution of OpenBD on both Tomcat and JBoss and noted that "ready-to-run" distributions will also be available (Jetty-based initially, with Amazon EC2 and VMWare images following soon).
This was followed by open Q&A for a while and then he showed the source code in Eclipse and demonstrated how to build and run OpenBD from source.
He ran into a bug - triggered by a bad environment setting - and used the step debugger to identify the problem in just a few minutes, then fixed the code and rebuilt and successfully ran the project. I think that was very persuasive for several folks in the audience.
A couple of things really stood out for me:
- The WAR distribution - the binary - was only 11Mb
- Getting this running on Tomcat was as simple as:
- Download openbluedragon.war (11Mb WAR)
- Download Tomcat (6.3Mb ZIP)
- Unzip Tomcat
- Put openbluedragon.war in Tomcat's webapps folder
- Start Tomcat - bin/start.bat (Windows) or bin/start.sh (Mac OS X - you may need to make the scripts executable first: chmod +x bin/*.sh) - Tomcat unpacks the WAR into the webapps/openbluedragon/ directory for you
- Hit http://localhost:8080/openbluedragon/
- The source distribution is only 14Mb as a ZIP file
The small size was a real eye-opener after recently downloading the 456Mb ColdFusion 8.0.1 Linux 64-bit installer.
Vince used Fusebox 5.5.1 and the new Fusebox cat club sample apps as his demo code. He unzipped the openbluedragon.war, copied in the Fusebox core files and cat club folder, edited the bluedragon.xml file to add a data source, zipped the directory back up as demo.war and dropped it into Tomcat. Then he hit localhost:8080/demo/ in his browser and showed the Fusebox sample app running. In other words, he quickly created a custom J2EE web application containing the application code and deployed it as if it were Java code with just Windows Explorer's ZIP file management and WordPad.
The walk through the source was very interesting. Each tag in OpenBD is implemented as a Java class and a CFML page is converted to a sequence of Java objects on which to call the render() method. He showed a couple of tag implementations, the core engine (which all the initialization and setup code) and the main page request handler.
Adding new tags looks to be pretty easy (if you know Java) and he also mentioned that a standard plugin extension point would make it very easy to add-on all sorts of sophisticated functionality as external classes / JAR files.
Note: now the
public download page is available, I have updated several links in this post to hit generic pages instead of specific files.
Tags: bluedragon · cfobjective · coldfusion · j2ee · openbd · oss
11 responses so far ↓
1 Brad B. // May 3, 2008 at 9:49 PM
2 Sean Corfield // May 3, 2008 at 10:43 PM
Getting the right project facets and library paths set up is a bit of a pain if you want to use the Servers view to auto-publish to Tomcat and control it via Eclipse.
3 Matt Woodward // May 3, 2008 at 11:06 PM
4 Sean Corfield // May 3, 2008 at 11:09 PM
5 Sean Corfield // May 4, 2008 at 4:11 AM
6 Jim Priest // May 4, 2008 at 5:51 AM
7 Jim Pickering // May 4, 2008 at 6:48 AM
8 Sean Corfield // May 4, 2008 at 7:39 AM
9 Sana // May 4, 2008 at 7:57 AM
j2ee configuration are far different than normally how we handle websites. The difference between context-root, webroot, cf-mapping should be highlighted.
As we all know you always rock, having a cfloop array, what a great start.
10 Sean Corfield // May 4, 2008 at 8:05 AM
Tomcat and context roots is pretty straightforward. If you have foobar.war and you put in in Tomcat's webapps directory, it will be unpacked to a foobar/ directory and you will use http://localhost:8080/foobar/ as your base URL.
11 Sean Corfield // May 4, 2008 at 8:08 AM
In particular: "When using a single server, the performance when using a native webserver in front of the Tomcat instance is most of the time significantly worse than a standalone Tomcat with its default HTTP connector, even if a large part of the web application is made of static files."
Leave a Comment