Redirecting Errors to a File in Windows Batch Scripts

In my post on Redirecting Output to a File in Windows Batch Scripts, I discussed the basics of output redirection into a text file and how this can be used for logging, including error logging by using the >& operator to combine the stderr and stdout streams. But Mark asked, “How do you just pipe stderr without joining it to stdout?” Good question!

So normal output redirection is handled with just the > or >> operators (depending on whether you want to overwrite or append the target file), like so:

dir >> myfile.txt

The operator outputs the stdout stream by default. But it can be modified to output the stderr stream by just specifying that stream with the operator. Remember, stderr is stream 2. So, you would do like so:

dir 2>> myfile.txt

This would write only the error output to the file.

Line Debugging Causes CF to Not Start

So you go to turn on line debugging in ColdFusion, and when you save your changes, it warns you that the ColdFusion service will fail to start if the debugging port is already in use. Great, but what do you do if this actually happens?

I was at a loss for a few minutes on how to get ColdFusion started again so that I could fix the issue. Well, the configuration change is in your ColdFusion installation under ~/runtime/bin/jvm.config. So on a typical Windows installation, it may be c:\\coldfusion9\\runtime\\bin\\jvm.config.

Note: Before proceeding, it is always good practice to make a copy of the config file before editing it.

In jvm.config, there is an “Arguments to VM” section that has a java.args setting that may start with something like this:

java.args=-Xdebug -Xrunjdwp:transport=dt_socket, server=y, suspend=n, address=5095 -server -Xmx512m

(There will likely be many more arguments as well.)

The first two arguments contain the debugging settings that are probably preventing ColdFusion from starting. Remove the -Xdebug and
-Xrunjdwp:transport arguments, so that the beginning of the line will now look like this:

java.args=-server -Xmx512m (and additional arguments…)

This will be enough to get ColdFusion to start up. You can then go into ColdFusion Administrator to either change the debugging port or turn off the line debugging.

Notes: Improved Flash Remoting and Adobe AIR Integration in ColdFusion 9

These notes are taken at Adobe MAX 2009.

You can use HTTPService, WebService, RemoteObject components in Flex to pull data in different ways. Now what about ColdFusion 9?

ColdFusion’s Flash Remoting has been improved. So Flash applications that have ColdFusion 9 as a backend will interact much faster, and it can handle circular references.

There is now direct data translation between ActionScript and CF types, instead of previously having an intermediate Java layer that handled this. This involves changes in services-config.xml, but no code changes are required in your apps. Support for the old style remoting is still present for backward compatibility.

So how much faster is it? Drastically faster. Easily x9 faster, and that increases as the number of transactions occurs, according to the whitepaper Adobe has released about it.

BlazeDS. ColdFusion 9 is now integrated with BlazeDS as the default installation.

Configuration File. Services-Config.xml is now split into 4 files. There are a handful of ColdFusion-specific properties under the channel definition now. An “enable-small-messages” property is there and should be set to “false”. This is important for the new Flash Remoting in CF9, because BlazeDS’s default is “true”.

There is an AMFChannel component in Flex for the new Flash Remoting (Note: You can alternatively tell the AMFChannel component to have enableSmallMessages=”false”). Finally, the endpoint class is changed for the new CF9 one.

Offline AIR apps with ColdFusion 9

Now the fun stuff. ColdFusion 9 has an ORM for AIR! Build offline AIR apps without the SQL mess and conflict handling. There is a CF-AIR persistent framework for SQLite on the client side. CF keeps track of all updates to local database and synchronizes with the server, including conflict resolution.

By having ORM on the client- and server-side, these two are integrated through the CF-AIR persistent framework.

In the application code for the demo, there were customer.cfc and address.cfc persistent objects. Then a sync CFC is used for providing the fetch and sync functions for communication with the AIR client.

Step #1: Create the persistent CFCs.

Step #2: Create the sync CFC. He called it custmgr.cfc. The CFC has implements=”ISyncManager” as an attribute. Then you have fetch() and sync() methods that handle the transactions. Here you can provide your logic for handling certain scenarios, such as conflicts.

Step #3: On client side, create equivalent AS classes that map to the CFC via the [RemoteClass(alias=””)] metadata tag.

Step #4: Use the CF-built AIR libraries provided to fetch data from server, with the SyncManager component. It’s very simple, practically just point it to the sync CFC and do a fetch() method. To work with the database, you then openSession() and can create new AS objects and call save() on the session to insert/update/etc. Finally, using commit() will commit the results and invoke the sync() process.

On the client side, it can receive conflict notification and receive both versions of the data so that you can decide what to do with the conflict.

It is very exciting to have some help implementing synchronization without having to purchase LCDS. Using the CF9/AIR integration libraries will be very nice.

Notes: Advanced ORM in ColdFusion 9

These are notes from Adobe MAX 2009 about advanced ORM in ColdFusion 9.

Join Mapping. You can have a CFC whose primary table is “Person”, but it has properties that fetch values from a joined table, such as the “City” property from an “Address” table. Interesting.

ORM Initialization. When application first starts, it looks to see if ORM is enabled. If so, it creates/loads the Hibernate configuration, the loads Hibernate mapping files, searches for persistent CFCs (you can point it at only a particular directory to speed things up), generate Hibernate mapping for persistent CFCs, then even generate the schema on the database if it doesn’t exist, and then finally build the Hibernate Session Factory. Once this is done, it will not occur again unless you tell it to, because this initial setup is an expensive operation. You can use ormReload() to force it.

ORM Session. All ORM operations happen in the session. It provides some simple caching. The session tracks changes made to the objects. So it doesn’t actually execute SQL until a session is flushed, which happens when the request completes or when you force it with ormFlush().

When using CFTRANSACTION, the Hibernate session will be flushed and closed at the end of your CFTRANSACTION.

Object States. When you create an object with EntityNew(), CreateObject(), etc, the object is transient and is not known by Hibernate yet. Once an object is saved or loaded, it is in a persistent state. The kicker is “detached” objects. If the Hibernate session ends, and object that you have will become “detached” since the session ended. So if you have lazy loading for your object, for instance, it will throw an error because Hibernate has nowhere to lazy load the object’s data. However, you can use EntityMerge() or redo an EntityLoad() to bring it back into a persistent state.

Concurrency Control. You can use the “optimisticlock” attribute of a CFC to “All”, “Dirty”, “Version”, or “None” to control how record updates occur. “Version” is the default which uses a timestamp to check the version of the record vs. the object. “All” does a where statement of all record fields, and “Dirty” only handles the changed fields.

Fetching strategy. How will you fetch relationships of tables? “Immediate”, “Lazy”, “Eager”, or “Batch” fetching. “Immediate” fetches everything immediately. The default “Lazy” fetches things on demand. “Eager” fetching fetches everything in a single SQL statement, good for frequently used one-to-one relationships. There was a bit of confusion in regard to “Batch” fetching.

Caching. Session-level cache fetches data the first time and will not reload subsequent requests. EntityReload() will force a reload. Secondary-level cache can cache data across Hibernate sessions. It can be in-memory, disk, clustered. They have the default caching engine as EHCache.

How to use secondary cache? Enable it first. In application.cfc, use ormsettings.secondarycacheenabled=”true”. Then in your ORM CFC, the cacheuse=”” attribute defines the caching strategy (such as “read-only”, the most performant), and cachename=”” defines the name of this specific cache.

Secondary cache can also be used on relationships. And when using ormExecuteQuery() functions to use HQL to query the database, you can cache as well with cacheable=”true” as one of the options. This can be used in EntityLoad() too.

When cleaning up caches, there are ormEvictXXX() functions to remove entities, collections, and queries.

Event Handling. Hibernate lets you set ormsettings.eventhandling=”true” to have many CFC level events, like preLoad(), postLoad(), preInsert(), postInsert(), preLoad(), postLoad(), etc. This can be used for logging or other nifty features. Wow! That’s awesome. Nice hooks.

Interesting user questions. One gentleman asked about using an XML file as a datasource through Hibernate. That would be interesting to try/use.

This session could have been 90 minutes. There are a lot of advanced things that can be done with the ColdFusion integration with Hibernate from the ColdFusion API.

  Theme Brought to you by Directory Journal and Elegant Directory.