I don’t think there is a LogBox-specific forum, so hopefully no one will mind me posting my question here to the main ColdBox list.
I am deploying LogBox OUTSIDE of a ColdBox app as a standalone logger. All of my components for this project are outside of the web root in a folder to which there is a CF mapping to:
-appNameCFC
± com
± peterbell
± lightwire
± timblair
± restfulCF
± companyName
± packageName
± logbox
±system
± core
± logging
You get the picture…
Basically I don’t particularly care to create a mapping for every framework I use. It just seems kind of messy and tends to dilute the readability of my code when I have to check 10 mappings to figure out where my createObject’s are resolving their paths to. I’d like to have a single mapping to “appNameCFC” and then reference everything consistently as “appNameCFC.com.peterbell.lightwire.LightWire” etc.
The standalone version of LogBox assumes the “logbox.system” namespace which means I either need to:
- Modify all LogBox core files to reference where I have placed it
- Create a “logbox” CF mapping.
Am I just being ridiculously stubborn and need to get over my irrational fear of multiple mappings, or is it a valid desire to want to be able to tell LogBox (through the config file, I guess) “where” it is so I can place it anywhere I please?
Thanks!
~Brad
Hi Brad,
Have you looked at the Coldbox options for changing the path it is installed in? The same functionality I believe will also update the paths in the Logbox functionality that comes with Coldbox 3.0. You may be able to use the refactoring tools to do what you want or at least look at them to see what they do to make Coldbox and Logbox work in other than the standard location.
Tom
Huh whaddya’ know-- I wasn’t even aware that CB had a refactoring tool.
http://wiki.coldbox.org/wiki/Refactoring.cfm
Looks like it’s an Ant script that does the following search and replace:
-
coldbox.system
That’s pretty cool, Luis. So technically, this falls under my first option of “Modify all LogBox core files…”. I hadn’t considered that too seriously because it just seemed dirty, but I guess it’s comforting to know it’s actually encouraged to a degree.
Of course, the other little hitch here is that when I am done with this project I’ll hand it back to the company I’m contracting from and they may have different mapping names on their server than I have on ~ my local development box has. That’s also a big reason I was hoping to keep everything self-contained so they could just drop it in and at most change a setting to two.
~Brad
Have you thought about using a DI container like Coldspring and
injecting the LogBox factory into your code so you can just call
instance.LogBox.info("foo") ? Or am I just misunderstanding the
problem you are trying to solve?
Judah
I believe you are misunderstanding my problem. I am using a DI engine-- Lightwire specifically. If you look at my example directory structure below you'll actually I listed it in there. 
The problem however is simply instantiating the LogBox component (and LogBoxConfig for that matter) when they are placed in a mapping OTHER than logbox.system. This is an issue regardless of whether I instantiate it manually for via an Ioc/DI object factory.
For example, right now my component path to LogBox core CFC is NOT logbox.system.logging.logbox.
Instead it is appNameCFC.com.logbox.system.logging.logbox (for the reasons listed in the OP).
I just tried my second option of creating a mapping called "logbox" but leaving the logbox folder where it is (appNameCFC/com/logbox) but it presented a new problem. Even though I created my LogBoxConfig object with the following path logbox.system.logging.config.LogBoxConfig (which uses my new mapping) dumping the metadata on the CFC after creating it still shows a component path of appNameCFC.com.logbox.system.logging.config.LogBoxConfig. I'm not even sure if this is a CF bug or expected behavior. (CF 8.0.1) Perhaps you are not supposed to have a mapping to directory that is a subdirectory of another mapping. (?)
Weird-- restarting ColdFusion cleared that up. Must have been CF caching the component path somewhere...
Well, that being said, creating the "logbox" mapping does work as I expected it would.
I'm still open to any other suggestions or opinions on my original suggestion about being able to specify a path to the framework. The more I've thought about it, the more problems I've come up with though. For instance, it is simple to specify a dynamic path to createObject, but I don't think variables can be used for the "type" attribute of cfargument when specifying an argument type. Ex:
<cfargument name="config" type="logbox.system.logging.config.LogBoxConfig" required="true" />
I think that would probably make it impossible to put the base component path in a config file somewhere. You would pretty much have to refactor or create a mapping.
~Brad
Here are my two cents. Refactoring is definitely an option, that is why I provide the guide and ANT scripts. This was done with the intent that you wanted to embed any of the ColdBox Platform frameworks in your applications, so they are part of your code.
If not, I would recommend sticking to per application mappings. I love the per app mappings and find them very very useful when dealing with external libraries and frameworks. Again, that is me and my preference, I find that always going to Application.cfc is the right thing and I can see what my application uses, ORM settings, etc.
Luis F. Majano
President
Ortus Solutions, Corp
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
Yes, ColdFusion caches the path that each CFC resolves to. I thought
there was a button in the admin to clear that cache? Maybe that's only
in CF9?