Issue 179: index.cfm broken
Status:  Fixed
Owner:
Closed:  Feb 2010
Reported by johncbla...@gmail.com, Feb 22, 2010
What steps will reproduce the problem?
1. Download
2. Place in webroot
3. Go to /mxunit/index.cfm

What is the expected output? 

Not an error. :-)

What do you see instead?

(see attached screenshot)

What version of the product are you using? 

1.0.8

On what operating system?

OSX / CF9

Please provide any additional information below.

The attached index.cfm is a fixed version. 

Issues:
Line 46: <cffile action="write" file="#context#MXUnitInstallTest.cfc" output="#testCase#" />

This is writing to the /mxunit folder but...

Line 57: <cfset testSuite.addAll("#componentPath#MXUnitInstallTest") />

Ahh...it is attempting to pull the file from the componentPath which is not correct. It should be:

<cfset testSuite.addAll("#context#MXUnitInstallTest") />

Just like the cffile write on line 46.

Also, 
Line 55: <cfset componentPath = left(testSuiteMeta.name, len(testSuiteMeta.name) - 
len(testSuitePath)) />

Throws an error and the error displays on the page (see screenshot). Why? Glad you asked.

Lines 84-86:
		<!--- TODO Remove --->
		<cfdump var="#cfcatch#" />
		<cfabort />

Uh oh...someone forgot to remove a dump. Remove that and you get a nicely formatted error but 
still an error since line 55 is wrong.

Line 55 tries to do a left operation like so: left("TestSuite", -10). (at least on my system)

I've replaced this with:
<cfset componentPath = replacenocase(testSuitePath, testSuiteMeta.name, "", "all") />

This works perfectly fine and, i assume, achieves the same thing (get the test filename out of the 
path).

Anyways...hope this helps out.
Screenshot232.jpg
251 KB   View   Download
index.cfm
3.1 KB   View   Download
Feb 22, 2010
Project Member #1 Zoram...@gmail.com
I already removed the dump for the MIT branch, but I'll work on the component path 
too.
Owner: Zoramite
Labels: Type-Defect
Feb 22, 2010
#2 johncbla...@gmail.com
Good deal.
Feb 22, 2010
Project Member #3 Zoram...@gmail.com
Can you try it with the following instead:

<cfset componentPath = left(testSuiteMeta.fullname, len(testSuiteMeta.fullname) - 
len(testSuitePath)) />

I don't have ACF handy to test with.
Feb 22, 2010
#4 johncbla...@gmail.com
That does work because the fullname and name are the same value: TestSuite.

This does work though:
<cfset componentPath = left(testSuiteMeta.fullname, len(testSuiteMeta.path)-len(testSuitePath)) />

Here is my dump of the meta:
DISPLAYNAME	 TestSuite
FULLNAME	 TestSuite
HINT	 Responsible for creating and running groups of Tests.
NAME	 TestSuite
PATH	 /Volumes/Dev/Personal/jcbii/presentations/2010/MXUnit/source/mxunit/framework/TestSuite.cfc
TYPE	 component

Ha! I just realized why my above replace worked. :-)

The file is written to /mxunit. I removed the use of #componentPath# in the testSuite.addAll(...) so that 
variable is never used.

Either way...blindly using left() without verifying the length, etc is a recipe for troubles. :)

BTW, my replace fix fails too once I add the variable into the addAll(...) but the componentPath var isn't 
needed on my end so I just nixed it anyway.
Feb 23, 2010
Project Member #5 virtix
This may be related to this thread:
http://groups.google.com/group/mxunit/browse_thread/thread/ca7d99fcc3e46219

I "think" what may be happening is how coldfusion retains the metadata with respect
to how a component is instantiated. I would expect it should be the same if a
component is created using createObject(..., 'fully.qualified.path.MyCFC') vs.
createObject(..., 'path.MyCFC'), but I think it's different.

bill
Status: In
Feb 23, 2010
#6 johncbla...@gmail.com
Yeah, seems to be about the same.

I think the problem is whether or not mxunit is in the component path or not. Using the metadata seems 
unreliable and should probably rely on the #context# instead (since that is where you are writing the file 
anyway).

Looking forward to the fix.
Feb 23, 2010
Project Member #7 virtix
john, have you configured a webserver to work with cf? if so, can you post your
configuration?

bill 
Feb 23, 2010
Project Member #8 Zoram...@gmail.com
I was doing some testing this morning when I got to a computer that is has cf8, cf9, 
railo, and openBD.

I've attached the files that i used to test if you would like to run it and see what 
the out is.

I'm curious why the output of fullname or name would be different on OSX CF9...?

I'll try and test this out when I get home tonight on a ubuntu box and see if I get 
anything different.

I could just do a diff on the paths and replace the slashes, but I'm curious now what 
the differences between versions and cf servers are.
test.zip
500 bytes   Download
Feb 23, 2010
#9 johncbla...@gmail.com
@virtix
For this specific case, I'm using CF 9 on Apache. What specific config(s) are you looking for?

@Zoram
Here is the output:
struct
EXTENDS	
struct
FULLNAME	 WEB-INF.cftags.component
NAME	 WEB-INF.cftags.component
PATH	 /Applications/ColdFusion9/wwwroot/WEB-INF/cftags/component.cfc
TYPE	 component
FULLNAME	 testing
NAME	 testing
OUTPUT	 false
PATH	 /Volumes/Dev/Personal/jcbii/presentations/2010/MXUnit/source/test/resource/testing.cfc
TYPE	 component
Feb 23, 2010
Project Member #10 marc.es...@gmail.com
Bill, did you or anyone else ever file this as a bug with Adobe? If not, I'll do that
b/c this has been happening for years and it's highly irritating!
Feb 23, 2010
#11 johncbla...@gmail.com
Great idea. Can anyone confirm whether this happens on Railo or not?
Feb 23, 2010
Project Member #12 Zoram...@gmail.com
I programmed it originally on Railo and it works fine.. hence how it got in there in 
the first place.

What I am curious is if it is a problem from how apache works with cf9 or if it is cf9 
itself.

Testing with tomcat 6 and the cf9 war on XP, it worked fine. Testing with cf9 war on 
Ubuntu with tomcat 6 works fine. It works fine on railo in all the cases I've tried. 
OpenBD also worked when I originally wrote it using the name. (the fullname doesn't 
work in OpenBD right now).

In all cases it gives test.resource.testing as the name.

I'm curious if it is something with the apache connection or if it is something with 
having ACF installed with JRUN instead of the war.

Anyone have some apache/CF9 setups they could test the zip on?
Feb 23, 2010
Project Member #13 Zoram...@gmail.com
I would still like to find out exactly why the ACF9 on OSX is the only one that is having 
trouble with the metadata name.

In the meantime I added a simple check to make sure it would not try to do a negative 
value to the left function and to default to a `mxunit` component path.

See r1343 and r1344
Feb 24, 2010
Project Member #14 virtix
I would like to report the bug to Adobe, but I think we need to be able to reproduce
it. We need both Mac, Windows, and Linux, both 32 and 64 bit - ideally. I can do the
Linux. On the list I was urging Jeff to try the tests on his Win.

I think it has to do with the webserver connectors on various OS. Again, it's been
reproducible on CentOS (32 or 64 bit?), Apache w/virtual hosts, and CF8.

It's fine with XP 32 bit, Apache w/virtual hosts.

bill
Feb 24, 2010
Project Member #15 Zoram...@gmail.com
With input from the list made changes in r1346 to create an instance of the component 
and pass that to the add all function hereby circumventing the entire issue of 
determining the component path completely.
Status: Fixed
Feb 24, 2010
#16 johncbla...@gmail.com
I have copied this to my system and everything works perfectly fine.

Fix confirmed.

Thanks!
Feb 24, 2010
Project Member #17 marc.es...@gmail.com
For what it's worth, I've seen this bug on CF6.1, CF8, and CF9.
Feb 25, 2010
Project Member #18 virtix
related bug filed with Adobe:
http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=82247
Feb 25, 2010
Project Member #19 marc.es...@gmail.com
Voted
Feb 25, 2010
#20 johncbla...@gmail.com
Same. Voted as well.