My Digital Life
I might have missed this earlier, but I just noticed that Railo is now formally available on JBoss.org.
http://jboss.org/projects/matrix
The link to Railo is under the category “Programming Model”. The links for direct download and documentation are not yet there (as they are for other projects).
Also, it is accessible through the main nav: Projects > Programming Model > Railo.
The twiddle utility that ships with JBoss is quite powerful. However, one has to struggle to find examples of how to use it.
After trying a bunch of things, here are examples of some of the command that were quite useful for me:
twiddle.sh -s localhost invoke "jboss.system:service=MainDeployer" deploy "file:///Users/indy/Desktop/railo-jboss1.local"
twiddle.sh -s localhost invoke "jboss.system:service=MainDeployer" undeploy "file:///Users/indy/Desktop/railo-jboss1.local"
twiddle.sh -s localhost:1499 invoke "jboss.web:host=a1,type=Host" addAlias railo-jboss1.local
twiddle.sh -s localhost:1499 invoke "jboss.web:host=a1,type=Host" findAliases
I also saw the following three resources and found them quite useful:
Today I needed to deploy an application that lived outside the usual
deploy folder. I also needed the ability to deploy/undeploy that application
without actually having to restart the JBoss instance.
The jmx-console provides the ability to deploy/undeploy apps. But to do it from the command line, I used the twiddle utility that lives in the bin folder.
Deploying an application can be accomplished by:
twiddle.sh -s localhost invoke "jboss.system:service=MainDeployer" deploy "file:///Users/indy/Desktop/railo-jboss1.local"
And undeploying an application can be accomplished by:
twiddle.sh -s localhost invoke "jboss.system:service=MainDeployer" undeploy "file:///Users/indy/Desktop/railo-jboss1.local"
This is quite an elegant solution if you need to do something like this.
Over the last few weeks I’ve been working quite intensively with Railo. And over that period I’ve been migrating a lot of my current applications to Railo. The migration process has been relatively painless and that is really impressive. There are two things to look out for: compile-time errors and runtime errors in the code that you migrate.
Railo makes it really easy to uncover compile-time errors. It provides a setting in the Web Administrator that goes off and compiles all the cfm and cfc pages in your application. Imagine if your application has a lot of cfm and cfc files. How complex would it be to test if all of them work ok or not.
Checking for compile-time errors is important as Railo is slightly less forgiving than the Adobe ColdFusion compiler. The Railo compiler verifies tags, attributes, arguments in a little more strict manner — which I think is a positive thing. Not only does it help to keep the code sharp, but also leads to gains in performance.
So to test for compile-time errors, without having to physically click through each cfm page in your application or instantiating each cfc, you can simply setup a mapping in the Server Administrator to the folder where your application lives. Once the mapping is setup, simply go to edit the mapping and hit the compile button. Railo goes through all the cfm and cfc files, compiles them, and reports on any errors it finds.
Here are some screenshots of what needs to be done to check for compile errors:
I rely heavily on flashlog.txt for tracing Flex code. But I just couldn’t get the flashlog.txt to go today — I am rebuilding my box.
So I started looking at the Adobe technote on this matter “Debugging Client-Side Code in Flex Applications”. However, the Flash movie on this technote was not giving accurate information about my Flash player.So after looking around a little more, I found another technote called “Version Test For Adobe Flash Player” that correctly identifies my Flash player.
So I have the correct version of Flash Player, but I still couldn’t get the flashlog to record any trace output. My mm.cfg file was configured correctly and was present at the correct location. There was a blank flashlog.txt file in the location specified in mm.cfg. But no matter what I did, it did not trace any output.
Then I came across the following in the Flex Builder documentation:
The default log file location changed between the initial Flash Player 9 release and the Flash Player 9 Update. In the initial Flash Player 9 release, the default location is the same directory as the mm.cfg file and you can update the log file location and name through the TraceOutputFileName property. Beginning with the Flash Player 9 Update, you cannot modify the log file location or name and the log file location has changed, as follows:
Windows
C:\Documents and Settings\user_name\Application Data\Macromedia\Flash Player\Logs
Macintosh
Users/user_name/Library/Preferences/Macromedia/Flash Player/Logs/
Linux
home/user_name/macromedia/Flash_Player/Logs/flashlog.txt
I checked the location mentioned here, and the file was there and has the trace information!
It was the move from Flash Player 9 to Flash Player 9 Update that caused me this grief.
And why is it still in C:\Documents and Settings\user_name\Application Data\Macromedia\Flash Player\Logs directory?
Why not C:\Documents and Settings\user_name\Application Data\Adobe\Flash Player\Logs?