I haven't looked back over the entire thread on this, but did anyone look at the possibility that this is simply the cacheRealPath issue that has plagued multi-homed CF installations in the past?
FWIW, I am 99.9% sure that "com" is not a reserved mapping at the CF level, so your reply from CT is confusing (maybe they were thinking "com" in terms of java packages?). Other than the issue of name collisions on multi-home machines, what else are you looking for clarification on? > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Nando > Sent: Wednesday, November 19, 2003 10:42 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] cfc paths > > > Hi all, > > <snip author="Massimo"> > The issues raised by Jim are important, but they scare me much > less than the > risk for name clashing... I don't pretend to say relative paths are the > ultimate solution, but we have a problem, a pretty serious one, > and we need > a solution. > </snip> > > I've been following this thread, and i'm wondering if this is a > "confirmed" > problem, especially as Ben Curtis couldn't replicate it. Right now, i have > all my components under a "com" subdirectory and the site will be > hosted on > CrystalTech. And they all have pretty ordinary names, like Person, Text, > etc. So the potential for a clash, if this can actually occur, is pretty > high with my naming scheme so far. > > <snip author="Robby"> > I'm on Crystal Tech as well Jim ... I noticed when they brought > in the 'add > your own mappings' that they have reserved the com mapping. I love the > convention, but I could see why the death of it's use on their part. Heh, > try being a mach-ii developer to boot. From what I gathered in a > light email > conversation with a CT tech on the issue it's been going off the hotplate > faster than domain names on ebay in the 90s. All in all when it comes to > conventions such as package naming, ColdFusion and sharedhosting > isn't going > to play nice. period. > </snip> > > Ummm, that's a little confusing ... so I thought I'd write CrystalTech and > ask them directly why that mapping was reserved on their system ... here's > the answer i got back: > > <snip author="CrystalTech Support"> > It is reserved by MX6.1, not our system. Therefore, there should be > more information about that on their website www.macromedia.com . > </snip> > > ??? - Well, that didn't help. I can map to a subdirectory named > "com" on my > dev installation without any problem. > > <snip author="Macromedia LiveDocs"> > http://livedocs.macromedia.com/coldfusion/6/Developing_ColdFusion_ MX_Applica tions_with_CFML/buildingComponents5.htm When you refer to a component using the fully qualified name, ColdFusion looks for the component in the following order: * ColdFusion attempts to resolve the physical path from the request, such as /com/mycompany/catalog/product/saw.cfc, to a component file located in directories under the web root or directories under ColdFusion mappings. * Otherwise, ColdFusion attempts to resolve the physical path in the custom tag root, such as {customTagRoot}/com/mycompany/catalog/product/saw.cfc,. When a component is invoked using any of the interfaces mentioned previously, ColdFusion generates the key name in the component metadata structure in the following order: * If a component file exists in a directory accessible by ColdFusion mappings, use GetRealPath function to evaluate the component physical path. The URI path string after .cfc and the leading slash is removed, and all slashes are replaced with dots. * Otherwise, ColdFusion loops over the custom tag roots looking for the ancestor directory of the component. The physical path string after the root path and file extension are removed, and all slashes are replaced with dots * Otherwise, ColdFusion uses the file name without the extension as the component name. </snip> Ok, now i'm totally lost. If anyone can clear something up here, i'd appreciate it - Thanks! ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
