Install Issue - MXUnit Outside Webroot

83 views
Skip to first unread message

Jeff Chastain

unread,
Jan 31, 2010, 7:36:31 PM1/31/10
to MX Unit

I know I have done this before, but I am running into issues tonight.  I just pulled down a copy of MXUnit 1.0.8 and unzipped it into a folder outside of my web root.

 

                /frameworks

/mxunit

                /webapp/

                                /www

 

I have a CF (8) mapping setup to point to the MXUnit folder with the name ‘mxunit’.  I have an IIS virtual directory setup to point to the same folder, also with the name ‘mxunit’.

 

When I browse to http://sitename/mxunit, I get the header and the welcome message.  Then, I get an error dump in index.cfm:55 – The 2 parameter of the Left function, which is now -10, must be a positive integer.

 

Looking at index.cfm, I see it is trying to compute the component path to the MXUnitInstallTest.cfc file which should be ‘mxunit.MXUnitInstallTest’.  If I dump the testSuiteMeta.name, I get ‘TestSuite’.  If I dump the testSuitePath variable, I get ‘framework.TestSuite’.  Obviously the testSuitePath variable is longer than the testSuiteMeta.name variable, thus giving the -10 that is not a valid argument for the left function.  It also does not have the ‘mxunit’ path anywhere there.

 

So, any ideas what is going on here?

 

Thanks

-- Jeff

bill shelton

unread,
Feb 1, 2010, 6:50:42 AM2/1/10
to mxunit
Jeff,

This looks like the same issue Ray was having. I "think" it might have
something to do with the CF/IIS connector and component metadata, but
it also could be something we changed in the last release. Can you
help a Linux user troubleshoot the issue? If possible, create the same
directory structure but instead of mxunit, create an arbitrary app ...
"myapp" and create the cfmapping and IIS virtual directory to /myapp.
Now, in myapp put a cfc in there (mycfc.cfc) and an index.cfm that
dumps the metadata from the cfc.

<!--- index.cfm --->
<cfset cfc = createObject('component', 'mycfc') />
<cfdump var="#getMetadata(cfc)#" />

Note the "name" and "fullname" metadata items. They both "should" be
myapp.mycfc.

I know this is a lot to ask, but it would be a big help, Jeff!

thanks,
bill

On Jan 31, 7:36 pm, "Jeff Chastain" <li...@admentus.com> wrote:
> I know I have done this before, but I am running into issues tonight.  I
> just pulled down a copy of MXUnit 1.0.8 and unzipped it into a folder
> outside of my web root.
>
>                 /frameworks
>
> /mxunit
>
>                 /webapp/
>
>                                 /www
>
> I have a CF (8) mapping setup to point to the MXUnit folder with the name
> 'mxunit'.  I have an IIS virtual directory setup to point to the same
> folder, also with the name 'mxunit'.
>

> When I browse tohttp://sitename/mxunit, I get the header and the welcome
> message.  Then, I get an error dump in index.cfm:55 - The 2 parameter of the

Jeff Chastain

unread,
Feb 22, 2010, 4:09:58 PM2/22/10
to mxunit
Bill,

Sorry, I must have missed this message some time back. Now googling
for a solution again, I just came across this. I setup the following
test based upon what I think you were describing ...

/myapp
/mycfc.cfc
/index.cfm

With a CF Mapping pointing to /myapp and an IIS virtual directory
pointing to /myapp, I get both the name and fullname metadata keys
equal to 'mycfc'. I changed the createObject command to use
'myapp.mycfc' as the component path, and the result was the same.

Not sure what this tells you or if it was the right test, but let me
know if not.

Thanks
-- Jeff

bill shelton

unread,
Feb 22, 2010, 7:45:58 PM2/22/10
to mxunit
Jeff,

Thanks for helping out. Can you try the following ?

1. Stop the CF server
2. Make sure the createObject statement looks like
createObject('component', 'myapp.mycfc')
3. Start the CF server
4. Report what the meta data says.
5. Now, stop the CF server again
6. Change the createObject statement to createObject('component',
'mycfc')
7. Start the CF server
8. Report what the meta data says.

I would expect the name and fullname to be myapp.mycfc in both cases.
But, I suspect it may result in myapp.mycfc and mycfc respectively,
which would would reproduce this issue.

Thanks again for your help! I think we're closing in on this pesky
critter.

bill

bill shelton

unread,
Feb 24, 2010, 8:43:43 AM2/24/10
to mxunit
Jeff,

Can you also post the underlying IIS and Windows versions; e.g., IIS7,
Windows Server 2008 64bit?

bill

Patrick McElhaney

unread,
Feb 24, 2010, 9:29:02 AM2/24/10
to mxu...@googlegroups.com
I have the same problems on Snow Leopard / CF8. I have the MXUnit code
outside the web root, with a symlink to it under the web root.

After looking at how TestSuite.AddAll() works I found a simple fix.
Instead of trying to figure out where the component lives, just create
an instance and pass it to TestSuite.addAll().

<cfset testSuite.addAll("MXUnitInstallTest", createObject("component",
"MXUnitInstallTest")) />

I've the attached a patch as well as the full index.cfm after modification.

Patrick

> --
> You received this message because you are subscribed to the Google Groups
> "mxunit" group.
> To post to this group, send email to mxu...@googlegroups.com.
> To unsubscribe from this group, send email to
> mxunit+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mxunit?hl=en.
>

index.cfm
allow-mxunit-outside-webroot.diff

Patrick McElhaney

unread,
Feb 24, 2010, 9:55:54 AM2/24/10
to mxu...@googlegroups.com
I accidentally applied my patch on top of another fix that was checked
in yesterday. Let's try that again. Here's a patch to the latest
revision (1344), which replaces the existing fix.

I think my solution is better since it cuts off the problem at the root.

Patrick

allow-mxunit-outside-webroot-against-1344.diff
index.cfm

Randy Merrill

unread,
Feb 24, 2010, 10:01:36 AM2/24/10
to mxu...@googlegroups.com
I concur :)

The MIT branch is now creating the install test and passing the component to the addAll(). See r1346

Thanks for the help and input!
--
Randy Merrill
Reply all
Reply to author
Forward
0 new messages