Viewing Category: Transfer ORM  [clear category selection]

Creating the Transfer Definitions Path as Needed

While firing up a clean installation of a web application, I got an error (as expected) that the Transfer definitions path did not exist. To make fresh deployment of a web application easier, I modified my Transfer configuration, which is done inside ColdSpring. I created a component that wraps the actual Transfer configuration, and will create a missing path if needed. The same result could have been achieved using AOP and inserting a before advice pointcut, but that too requires writing out a piece of generated code -- the problem I'm trying to solve. Here's the wrapper:

<!--- /model/transfer/TransferEnvironment.cfc ---> <cfcomponent extends="" output="false">   <cffunction name="init" returntype="TransferEnvironment" access="public" output="false">     <cfreturn super.init(argumentCollection=arguments)/>   </cffunction>     <cffunction name="setDefinitionPath" returntype="void" access="public" output="false">     <cfargument name="definitionPath" type="string" required="true"/>       <cfif not directoryExists(expandPath(arguments.definitionPath))>       <cftry>         <cfdirectory action="create" directory="#expandPath(arguments.definitionPath)#" mode="775"/>         <cfcatch>           <cfthrow type="TransferConfigurationException" message="The Transfer definition path (#arguments.definitionPath#) does not exist, and could not be created."/>         </cfcatch>       </cftry>     </cfif>     <cfset super.setDefinitionPath(arguments.definitionPath)/>   </cffunction> </cfcomponent>

The ColdSpring XML using the wrapper is practically unchanged from what it was when using the actual Transfer configuration component:

<bean id="transferFactory" class="transfer.TransferFactory" lazy-init="false">   <constructor-arg name="configuration">     <bean class="model.transfer.TransferEnvironment">       <property name="configPath"><value>${transferConfigFile}</value></property>       <property name="datasourceName"><value>${transferDatasourceName}</value></property>       <property name="definitionPath"><value>${transferCodeGenPath}</value></property>     </bean>   </constructor-arg> </bean> <bean id="transfer" class="" factory-bean="transferFactory" factory-method="getTransfer"/>

Railo Extension Provider with Transfer ORM

I wrote a Railo extension provider server to scratch my own itch -- that itch being that I wanted to install the latest Transfer ORM easily in a bunch of places. I spent a considerable amount of time getting the Ant build to be perfect. It's now simple run the build and dist targets to pull down the latest from Subversion and package a new Railo extension. All of the code for this project is on Github: jlamoree/railo-extension-provider

The root URL is a listing of the extensions available. The server is at and I will likely add more extension packages over time. I running this site over SSL, but the default certificate authority chain doesn't contain one for my signer. I could make hash digests for the files available, but it would be a manual process to verify them. Perhaps I'm the only one concerned about proving the authenticity of my server.

While perfecting the Subversion Ant task, I found a Google Code project named svntask that is far simpler than the Tigris SvnAnt tool that requires SvnClientAdapter and JavaHL. The svntask is pure Java and needs only the SVNKit library.

It is worth mentioning, however, that the binary release does not nave the checkout command. I really wanted to use the checkout, rather than maintaining an existing repository to update. I built the project from source to get com.googlecode.svntask.command.Checkout, and it works fabulously. To save you from such trouble, my dear droogs, you can download a copy here: svntask-r32.jar The following is a chunk of my build file:

<svn> <checkout url="${svn.url}" path="${svn.path}"/> <info path="${svn.path}" committedRevisionProperty="svn.revision"/> </svn>

The result is that the svn.revision property contains the latest Subversion revision, used in file naming and token replacement.

Quick and Dirty Configuration FIle Security

I follow the convention that XML configuration files for Mach-II, ColdSpring, and Transfer ORM go in the $WEBROOT/$APPROOT/config directory. This directory is web accessible, and unless otherwise protected, would leak information that could be compromising. There are many ways to secure this information, but a quick and dirty way to do it is add a .htaccess file to the source tree:

# /home/www/sites/ Order by allow,deny Deny from all

Of course, this will only work if Apache is configured with the default AccessFileName directive and the config directory is beneath a path with AllowOverride specifying (at least) Limit. For example:

# /etc/httpd/conf.d/ <Directory /home/www/sites/> AllowOverride Limit </Directory>

Another method that I use on sites with large sets of URL rewrite rules, is creating a rule to forbid access to matching URLs. For example:

# /etc/httpd/conf.d/ RewriteRule ^/app/config/.* / [L,F]

The rewrite has the same effect, but doesn't require the .htaccess file or AllowOverride directive.