Thursday, November 13, 2014

CF: Allowing different extensions for scheduled task log files

This is a quick post for people that run into this dilemma where there scheduled task stop working upon upgrade. They may receive this type of error in their browser:

Initialization Error: Valid extensions are : log,txt. - Invalid extension of the file name.

At first you go "What the Heck!". Then, look through gazillion lines of code to find where we could have produced this error and could not pin-point it.
Then, more digging to find the culprit:
With the advent of ColdFusion 10 & 11 and the exposure of the scheduled task vulnerability there was a change to what extensions where supported for your log files when you schedule tasks. As a security element these files can only be log and txt files.

However, the raw capture of the task run is normally neither, more often than not, especially with debug for the local IP enabled the output is HTML.
Thus, we have, now, for many years, used htm as the preferred extension, since the raw capture of the task run is HTML, thus, easy to view in the browser.  Forcing it into txt would only makes us rename the file before opening in the browser again.

Nightmares of unneeded code change ensued...

Fortunately, the solution seems simple enough.
a) Stop the ColdFusion instance
b) Find the neo-cron.xml
c) find the line that read like txt,log
d) add your extension to that line, e.g. txt,log,htm
e) start instance

Hope this helps others who give themselves the "Duh" slap.

Cheers,
B.


Friday, June 6, 2014

CF: CCFML or Making the Case for a Different CFML Future

Looking at the demands of our enterprise and the product road-maps as far as they have been disclosed by either Railo or Adobe we discovered a gap between what we are trying to achieve and what the technology is going to offer.

So, I have taken upon me to summarize a few thoughts and suggestions that I would like to share to see whether we can sway the Railo/Adobe general product direction.

I believe that focusing ever more innovation resources on the concept of RAD (Rapid Application Development) and language improvements, though interesting and useful, are not making CFML standout sufficiently to make a long-term difference and detract people from leaving or encouraging  new people to join.

In my opinion, the next level of server improvements need to be substantially different from other offerings and, this, in turn, requires a rethinking of what Railo/ACF offerings are.
Specifically,
Abandonment of the concept of Application Servers
Remove the need for download/installs
Remove the need for server administration and management
Redefine offering as packaged “infrastructure” with smart policy and deployment
Use clear convention based guidelines for subsystems (cache, application, storage, db)

Ok, now you say, what the heck are you dreaming about?
Good question, that.

In short, I am proposing that we work towards a true Cloud CFML platform === CCFML.

Let me explain:

We come from a heritage of dealing with individual servers and have embraced that concept wholeheartedly for many years. However, in the age of the cloud we should question those expectations.
How much more attractive could CCFML be when you only need a github/subversion account to deploy your code and a few policy definitions on how large you want your Application to scale and how fast.
When there are application problems, you can define policies how much CPU a process may consume, add more CPU cycles specifically for it, and/or cache. All automatically.
You application works automatically, fully scalable, across the globe on CFML.
You are kept abreast of any problems, bottlenecks and are given options to upscale CPU, refactor code, or add instances. But, best of all, you let the Cloud CFML take care of everything that a global CFML service should.
You want to push a new version, just change code and click deploy/schedule button.

Whatever decisions need to be made to get us this platform nirvana should be in the forefront of cfml future enhancements. This would require more standardization of convention so that we can have auto- configuration over coding whenever possible.
Behavior for deployment will need to be defined and “standard conventions” documented.
Here is just a selection of things that need to be answered on the way towards such a CCFML platform:
- Which distributed cache to implement and deploy
- Deployment system magic (version, install, upgrade, start, stop, pause engines)
- How do you scale session across servers
- How to communicate among cluster members
- How do you join servers to clusters
- How do you create a unified lightweight Application scope across the cluster,
- How to measure and set time,
- How to define and use a shared file-system
- How do you delineate code files storage vs. user assets
- How do you provide Application policy definitions for scaling
- How to manage and analyze code performance
- Create Application Manager (instead of Server Manager)
- Assigned Server roles, e.g. stateless vs. statefull servers
- Global logging and analysis
- Etc., etc.
There are probably many elements I don’t quite understand or have not considered. This is where I would ask for the smart people of the community to jump in, but, the point I am trying to emphasize is that future innovation should be directed towards creating such a platform rather than focusing on the minutiae of the language syntax.

The CFML language is quite mature and tweaks on syntax can only have limited impact on stopping developer attrition while an easy to use application platform has the potential to attract developers.
This model also provides a clear path for providers of this tech to charge for the services with the value recognition they are looking for.

The good news is that we have many components already; the next step is to create the working package and provide CFML as a first class cloud service.

We would not be the first, others like Microsoft with Azure and .net and the Java/Scala Play! Frameworks have already started the thought model and are getting traction. I fear that if we hesitate too long we may miss an opportunity to reverse course.

I hope this is not too confusing of a ramble and I am looking forward to feedback.

-Bilal