Railo Blog
- May 14, 2013
- Railo Teams Up with Daemon in Asia Pacific to Create Professional Service Excellence
LONDON, UK, May, 11, 2013 — The Railo Company Ltd; creators of the Open Source Railo Server and a leading global provider of CFML products and services and Daemon; a well established web development company based in Australia, announced that they are teaming up. Through the partnership, joint customers can rely on Daemon to support Railo Server throughout the APAC territory.
Railo Server uses a mixture of tag and script syntax to deliver the easiest yet the most powerful of web languages. Based on the CFML standard, Railo provides an easy way to build Java EE based web applications without the complexities of Java.
The partnership forms a centre of technical excellence and a Sales and Marketing alliance between The Railo Company and Daemon. Gert Franz, CEO of The Railo Company, said:
"We’re delighted to have Daemon on board to help us develop Railo’s presence in the ASIA Pacific region. The partnership is an important message to the CFML community and is important in spreading the global message that CFML and Railo continues to build a strong global presence."
Geoffrey Bowers, CEO of Daemon commented:
"We are thrilled by Gert Franz’ vision for the development of CFML and Railo Server by creating an ideal and natural partnership with Daemon."
Mr Bowers added:
"As experts in CFML and Railo Server development, we look forward to providing professional services and consulting around performance optimisation, development, frameworks, training, as well as project management and delivery, your team can benefit from the knowledge and experience of the talented Daemon team."
About The Railo Company
The Railo Company (http://www.getrailo.com) is simply one of the world's leading CFML companies. Based in the UK, and with offices in Switzerland and the USA, Railo is backed by an active development community as well as investment from members of the Bold Alliance in Europe and Blue River, Inc. (the geniuses behind MURA CMS) in the USA. For more information, visit http://www.getrailo.comAbout Daemon
Formed in 1996, Daemon Pty Limited is a leading wed development company in Australia. Daemon has created bespoke, beautiful Web solutions for more than a hundred renowned Australian companies and government organisations. Many of these companies have worked with Daemon for multiple Web projects and are repeat customers. With Railo Server, Daemon’s clients can look forward to supporting a growing number of CFML clients throughout the Pacific-rim. For more information, visit http://www.daemon.com.auFor more information:
The Railo Company Ltd
Mr Andrew Johnson
VP Business Development
Tel: +44 20 3289 2900 (London)
E-mail: aj@getrailo.com
- March 14, 2013
- Railo 4.1: Explicit Datasources in Application.cfc
In Railo Version 4.1 we have put some thought into making your applications portable. One of most obvious things that comes to mind as a requirement for an application is defining the datasource(s) that it needs.
Already you can define the name of a datasource you are using by doing:
In version 4.1 we have enabled you to define the WHOLE connection string to the datasource in the Application.cfc file. The easiest way to see this is to actually create a datasource connection in the Railo Web Administrator. Once you have done that click on the "Edit" datasource button:
Then, at the bottom of the Edit Datasource screen you can see the snippet that you can use to actually define this datasource in the Application.cfc, for example:
You can now copy and paste that into your Application.cfc: delete the datasource from the administrator and use the "mydatasource" datasource as you would have done anyway!
The generated example above is the "native" way that Railo needs datasources defined. But this is not all, we have a "simpler" way to define datasources, and that is by giving it the fields you would expect in the administrator. So for the above example (where we used the class and connection string) we can also define it with the field names you would expect:
Default and Inline Datasources
Defining default datasources can also be done by using the
this.defaultDatasourceparameter. You can then either refer to a datasource you have defined: or create a datasource within the parameter itself :Finally this is also true for ORM settings. You an define a datasource within your
this.ormsettingsstructure too:Side note about passwords:
You might notice that the password is encrypted in the "password" attribute. This is shown by the "encrypted:" prefix to the long string of code. What Railo has done is get your password and encrypted it. Making it safer to use within your code.password:"encrypted:94fae38de2f70330df8ed879571bef699cd4bde7241f94f2309ee97fd0358be8".Of course, you don't have to use encrypted strings. you can inou can replace the clear text password if you like rather than using the
"encrypted:xyz"format.Have fun with Railo!
- March 8, 2013
- Railo 4.1: Smarter Template Compilation
Version 4.1 of Railo brings with it many updates and improvements. One of these improvements that this version brings is the new way in which Railo Server now manages Java class information.
Each time a CFML template is modified, Railo recompiles it and generates a new Java class file. This has, up until now, had two major implications:
- The JVM keeps the compiled class information in an area called the Permanent Generation (commonly referred to as PermGen). This area is a finite resource, so the more changes you make to your templates the more memory is consumed. The problem is that, as the name implies, this information is supposedly "Permanent" and therefore the memory is not reclaimed by the Garbage Collector the same way as the object memory on the Heap does.
- In order to dispose of the loaded classes, Railo had to dispose of the class loader that loaded that class, which resulted in the undesired disposal of all the other classes that were loaded by that class loader. That of course meant that all of the classes that were disposed of unnecessarily needed to be loaded again.
So what's new now?
Now Railo has the ability to modify the Java bytecode of a loaded class -- so instead of unloading a bunch of classes and then loading them back -- Railo simply updates the bytecode for the Java class in place, which results in a huge performance gain and improved PermGen memory management.The only thing you have to do in order to take advantage of this new feature is to enable the Java Agent for the JVM. This can be done easily by using the command line switch
-javaagentand specify the location of the railo-inst.jar in the format:-javaagent:{path-to-jar}/railo-inst.jarIn most cases when you login to the Railo Server Administrator, Railo will tell you the correct path to the jar file. For example, on a typical Railo Express setup that path is
"lib/ext/"so to use it simply open the batch/shell file that you use to start Railo, and add-javaagent:lib/ext/railo-inst.jarto the command line arguments.A typical command line would be:
java -javaagent:lib/ext/railo-inst.jar -Xms256M -Xmx1024M -jar start.jarUsually we conclude our messages with the statement "Have fun with Railo", but we think that this time it would be more accurate to say:
Be productive with Railo!