I've said more than once that folks should avoid using hidden, undocumented features in ColdFusion. This warning applies especially to the ServiceFactory. Did you know that in ColdFusion 8 you can restrict access to the factory? In the settings page there is a new option:
Disable access to internal ColdFusion Java components
Disables the ability for CFML code to access and create Java objects that are part of the internal ColdFusion implementation. This prevents an unauthenticated CFML template from reading or modifying administration and configuration information for this server.
So what happens when this is enabled? Consider this simple code:
<cfset monitor = createObject("java", "coldfusion.runtime.RequestMonitor") />
With the above option disabled, it runs fine, but when turned on, you will get:
Permission denied for creating Java object: coldfusion.runtime.RequestMonitor.
Access to Java objects in the ColdFusion package has been disabled by the administrator.
So just keep it in mind when developing. I won't deny that I've used these internal objects myself in the past, but now I avoid them like the plague. Almost anything you need (almost) is available via the Admin API anyway.
Archived Comments
While I agree with your sentiment, I don't agree with the concept really. Even documented tags get depreciated and changed between versions. CFCHART and CFGRAPH for example.
Instead we should be advocates for better coding practices. For example instead of saying 'don't use the admin objects', you should instead build version specific libraries for using the admin api and alike:
lib_cfusion.cfc -> the library you use to run coldfusion specific functions
lib_bdragon.cfc -> the library you use to run bd specific functions
lib_cfusion_7.cfc -> uses the coldfusion 7 libraries
lib_cfusion_8.cfc -> uses the coldfusion 8 libraries
lib_cfusion_8_admin.cfc - version 8 admin api library.
etc
This way if the api changes all you need to do is create a cfc for the new version and pass the version as part of the arguments for each function.
This is the way a lot of javascript libraries work, why not implement it in coldfusion?
I should have mentioned that the lib_cfusion.cfc is extended by the lib_cfusion_8.cfc and lib_cfusion_8.cfc is extended by lib_cfusion_8_admin.cfc
lib_cfusion.cfc
|_ lib_cfusion_8.cfc
. |_ lib_cfusion_8_admin.cfm
You could just have two levels really, it's up to you. The functions used are in the lib_cfusion.cfc : eg <ctmmffdump> cfscript replacement - which has difference attributes from v7 to v8.
I'll post more on my blog later today (AU time)
I don't quite think we are on the same page here. I never said to not use documented tags. I don't think there is anything wrong with that. Deprecated tags should be avoided, but they still work. I'm talking about stuff that is NOT documented and is not guaranteed to work. Shoot - parameterExists still works and has been deprecated for over 5 years.
This has nothing to do with coding practices. It's really about just following the "rules", the rules being the docs.
You are basically saying it IS ok to use the admin objects, but only if you run them in an environment that matches the CF version. I say it is never ok and should be voided. Period.
*cough*
Don't know what you're talking about Ray....
*hides under a rock*
;o)
I wanted to let you know that ADDT, which was interaktonline MXKollection(a add on MXI that adobe now sells) uses ServiceFactory in their Login functions, under the KT_functions.inc.cfm and is becoming a huge pain for people that move up to cf8 in the shared environments where this option is disabled. This completely screws up all applications that are created with ADDT.
Here's another little tidbit. I'm finally getting to play with Flex and ran the main sample application Adobe provides to show connectivity to a database via Coldfusion. So the application works great on my localhost but as soon as I try to put it up on my shared host I get:
Permission denied for creating Java object: coldfusion.server.ServiceFactory.
Access to Java objects in the ColdFusion package has been disabled by the administrator.
All because of the following line of code:
<cfset factory = createObject( "java", "coldfusion.server.ServiceFactory" )>
Now, mind you, this is the first sample application you will get from Adobe regarding database connectivity between Flex 3 and Coldfusion and most places, it won't run. Not to mention, my host says that it supports all tags except for CFExecute and CFRegistry which would lead you to believe CFObject will work for any circumstances.
Brad, please email me off blog (use my contact form). I know the guys who worked on this code and I can hook up with them.
Well, I was WRONG. Turns out that in my haste of pushing code to my shared host, I left the datasource incorrectly named. My pointing fingers at the CFC was due to my inability to hit the CFC with a direct web request like this:
http://brad.melendy.com/pro...
This generates an error on my shared host but not on my localhost.
However, it works great when you hit the Flex app:
http://brad.melendy.com/pro...
So fooie on me. I'm just glad it works. :-)
Glad you got it. I noticed some missing var statements in the CFC. I've pinged my contact about getting them fixed. While not critical, Adobe should try to always provide good code.
So it's a year later and I'm running into this issue for the first time. ;)
Sometimes being a forerunner can be really challenging... I started doing database introspection back on ColdFusion 5 when all we had were custom tags and at the time I was using a combination of information_schema and other proprietary APIs for different databases. My objective of course was to create what is now fairly common with ColdFusion, and that's database agnostic software (relatively speaking). These days DataFaucet does it, Reactor does it, Transfer does it, DataMgr does it, etc. But at the time when I started, it was pretty much unheard of.
Around the time that 6.1 was released I finally updated the tools to use the JDBC sql.metadata object because it was much more consistent and reliable than the information_schema... and as far as I know, it still is...
But the past couple days I've been "going backward" actually trying to implement a back-up system for DataFaucet that will fall back on a combination of cfdbinfo and information_schema if the serviceFactory isn't available.
I would love for this to just be cfdbinfo all the way! Unfortunately it can't be, because the folks at Adobe who implemented it decided to change the standard AGAIN! Now there are some changes I wouldn't mind -- there's a bunch of data in there that's somewhat cryptic and not very useful. The problem is that they made very fundamental changes to the API and they dropped a bunch of information that I actually need.
So great, I can get the columns from the foreign key constraints, but they don't have any information about their schemas! Are they all from the default schema, or does it return them from any schema? Either would be problematic. And I have no information at all about the name of the constraints. With the JDBC version, I can drop a foreign key constraint (because you need the name for the SQL statement), but with cfdbinfo? Not a freaking chance!
Hopefully maybe in a future release they'll fix the holes and I'll be able to use cfdbinfo for everything... In the meantime they've basically brought me back to the kind of frustration I was dealing with on CF5. AND! Because the JDBC data is still more robust and reliable, it's still the default solution - it only falls back on cfdbinfo and information_schema if it can't get access.
http://www.datafaucet.com for those who are interested. I probably should have added this to my previous comment. :)