Wednesday, July 23, 2008

ColdFusion 9: Server.cfc

I have been pretty quiet about ColdFusion 9, aside from a few comments here and there. I wanted to take a moment to comment on Server.cfc. I'll be blunt and say that in it's current described form I think it will be useless. First let me describe Server.cfc. Server.cfc will provide users the ability to hook into the server start up and shut down events. This will be done by creating a Server.cfc. With this you can now react to onServerStart and onServerEnd.

Sounds promising right? Here's the problem, you can have 1, yes 1, Server.cfc per ColdFusion instance. How many of us deploy 1 application per ColdFusion instance? I know we certainly do not do this, heck we generally deploy 30+ apps to one CF instance. So now if I want each application to be able to do something at start up I have to constantly add functionality to Server.cfc for each application. This seems like a monumental mistake. I'd rather see the server hooks added to Application.cfc and the server scan for Application.cfc files on start up. ColdFusion has come so far to make application self sufficient (mappings, session control, settings override) making one Server.cfc would be a huge step backwards if you ask me.

7 comments:

Anonymous said...

Give it time man...I don't believe there's even an alpha out yet!

Anonymous said...

Doing something to an application at server startup sounds about as sensible to me as wanting to something to a session at application start-up.

I suppose you're creating a connection between the server starting and the next likely thing to happen after that is someone browsing to your application and the application kicking off. And indeed, as a result of that, their session kicking off. And their request kicking off.

But I think that situation is expressing connectivity between events that is common coincidence, rather than actually causal.

The Server.cfc should deal with events around start-up of the server. If you need something to happen when your application starts, then OnApplicationStart is the time to do that. You should not be using OnServerStart to kick-off applications.

IMO

--
Adam

Adam Haskell said...

Adam,

I think this is a matter of semantics but I understand what you are saying. What I want is the ability for my application to start when the server starts. So if that means I set a property THIS.startonservestart or a method onServerStart it really doesn't matter to me the end result is the same. Why should I wait for my first visitor to parse out my application's configuration, or load up my cache? I want that to happen when the server starts so the application is ready for my visitor. I think each application should have the option to hook into the server start.

Unknown said...

I can see this one both ways really. With this feature, I would use the server scope for common storage. Variables that all my applications may need. Examples might be data structures of states, countries, server wide objects used to keep all applications on a server consistent. These could be CFCs or common arrays / structs.

With that mentality, I lean toward the single Server.cfc. If I see an application referencing a server variable, I shouldn't have to look multiple places to find it. Applications should not be allowed to set variables at the server level because they are application variables unless they should be available to every app on the server, which contradicts placing them in the application.cfc.

On the other hand, shared hosting throws a kink into the problem as well as the potential of having a framework set server variables via a management application. An example would be allowing the coldbox framework / plugins etc. to be cached at the server level and other properties managed at the server level.

The last point that was made was also a good one. When the server starts, if a function in the Application.cfc was called, would the application also be inited at that time? Or would the application actually be loaded later? That's also one hell of a search for the server to do across all web accessible folders for application.cfc files.

Anyway, my mind is done wandering now.

Mike.

Anonymous said...

The problem with scanning the server for application.cfc's would be that it's an awfully resource intensive activity... It's possible not all the apps may be under the same web root, leaving you to scan the entire server (or risk leaving some out), and I wouldn't be surprised if it doubled the amount of time it takes for the server to load. And then there's the issue that adding it to application.cfc would make it basically invisible to a server administrator what apps are doing what in those events, whereas a server.cfc makes it transparent and easy to manage... But I already know I see things differently.

I might say the same thing you've said here about the way onApplicationStart works, because so many frameworks / tools, etc. might want you to do what? Copy and paste code into the onApplicationStart! BLECH!

Not that doing something onApplicationStart is so bad, but that copying and pasting code into that event method isn't the best solution for managing it. Which is why the onTap framework has a system for automating the inclusion of code from multiple sub-applications at application start using a series of config cfcs (in the new version 3.2).

And of course I would write my server.cfc to behave the same way, allowing anyone who had an application designed to run at the server level to create its own config.cfc to facilitate that, and then all you have to do is drop in the config.cfc for each server-level app you want to run on that server. Tidy, efficient and easily manageable.

Check out the code in onTap 3.2 and how its ioc manager works -- might change your mind about server.cfc.

Anonymous said...

There's definitely a use for it! I manage a big system where maybe 150 applications reside. Each application uses the same core code. As we move from custom tags to cfcs, I want to cache some cfcs in the server scope. I am currently trying to find a way to shove those into that scope on server startup without putting code in every application.cfc file, which is how I found this post. I wish that server.cfc existed now!

Brad Roberts said...

I'm a little late here, but here's (the start of) an idea....

Have an onServerStart method in Application.cfc. When an application is run with an onServerStart method, CF "registers" that Application.cfc. So now, when the server starts, CF invokes all of the onServerStart methods it has registered. If the onServerStart method is absent from Application.cfc, CF can "unregister" it in the CF Administrator.