[OT] Setting Up Open Blue Dragon

[billy]

This is a bit off topic, but may be of interest. I wrote some
rudimentary instructions on how to setup Open Blue Dragon on Tomcat
and JBoss. For me, it was straightforward to get up and running and to
test mxunit.

Please feel free to comment and suggest improvements:
http://code.google.com/p/mxunit/wiki/SetupBlueDragon

The one thing I really like about Open Blue Dragon is that it now
opens the door to writing software in CFML and distributing that to a
wide audience. You can bundle and distribute your application with
OBD, and even with Tomcat or JBoss, as a J2EE .war or as a standalone
app. Your customers are no longer required to be running an existing
ColdFusion server.

bill[y]

[Peter Bell]

Hi All,

Just an FYI, I installed the latest build and I got the following error - not only in the install checker but also in the test runner:

Expression Exception - in /Users/peterbell/Sites/workspace/default/mxunit/framework/ComponentUtils.cfc : line 69

    The 2 parameter of the Left function, which is now -1, must be a positive integer

It's a problem with the pathing in ComponentUtils.getComponentRoot() and I replaced the last line (the return, which was throwing the error) with a hard coded

return "/mxunit/"; 

which worked for us (with mxunit in the web root).

This was a bit of a last minute hack as we were supposed to be presenting to the Scottish CFUG, but it worked. Just in case anyone else has the same problem.

FYI, if anyone wants to see a recording of  Ben Nadel and myself proving that *anyone* can do TDD, check it out - 

http://adobechats.adobe.acrobat.com/p83492033/

Not advanced, but an interesting experiment. Feedback appreciated!

Best Wishes,

Peter

[Alan Livie]

Hi Peter. Good presentation.

I missed the end of the presentation due to my son hitting me in the head with a tennis racket! Just watched the bit I missed.

One thing I noticed when converting my cfcunit tests to mxUnit was the setup method had to change from private to public

So my setup function begins: <cffunction name="setUp" returntype="void" access="public">

Try that on your unit test and see if it helps your setup() method.

Alan
________________________________________
From: mxu...@googlegroups.com [mxu...@googlegroups.com] On Behalf Of Peter Bell [pb...@systemsforge.com]
Sent: 08 May 2008 22:50
To: mxu...@googlegroups.com
Subject: [mxunit:414] Possible install error

[Jon Messer]

I had this happen to me too, and I tracked it down to something whacky about the Mac Apache combo, if apache is being served from some where other than the default place.

I had my webroots in /var/www, which for some reason (probably file system permissions) was causing getMetaData() to return just the component name not the full path, which is what ComponentUtils was expecting.

I verified this by just doing a createObject then a getMetaData() and sure enough the name property was without the.dot.path.to.MyCFC it was just MyCFC.

So I moved my sites to the normal Mac location of /Library/WebServer/Documents and it works fine now... I still can't tell the difference in permission between the two directories... other than /var being a symlink to /private/var but that didn't work either.

[Peter Bell]

Thanks for the heads up. I like to keep my apache docs within my users root in <username>/Sites, so for now I'll just leave my hack in and re-implement when I download new versions. I'd try to contribute a proper patch, but I don't think I'm gonna get the time any time soon.

Best Wishes,

Peter

[Peter Bell]

Hi Alan,

Thanks. I'd have to check out the recording again, but I've got a
feeling we just did something silly like not put cfscript tags around
our code or something, because I just dropped the User =
createobject() into setup now, pulled out the createobject from the
methods, and all the tests passed (I deliberately broke it to get them
all red and then fixed to get them green again to make sure the green
was for real.

The joys of coding live in a presentation!

Thanks for turning up. Hope it made some sense . . .

Best WIshes,
Peter

[billy]

Peter and Jon,

My hunch is that Jon is on the right track with this.This has been
rather frustrating as I have not been able to reproduce this on
Windows, even though I have set up Apache virtual servers nearly
identical to Peter's specs. The only thing I can think of at this
point is that it has to do with how getMetaData() is returning
information in certain Mac/Apache configurations. It's clear that, in
Pete's case, it's not returning the expected values.

Here's what I propose:

1. I will add an optional "install-root" configuration item in mxunit/
framework/mxunit-config.xml. This will be used if getInstallRoot() is
empty. So, instead of changing the framework core code, you can update
that item in the config file.

2. I would like to see what is returned from getMetaData() using
Peter's configration. This can be done inside and outside the MXUnit
context. Specifically, what is returned from getMetaData().name?

Thanks for your patience with this! And it sounds like the preso went
well, despite the last minute panic. I'll be sure to check it out
today.

All the best,
bill[y]

[Peter Bell]

Hi Bill,

I dumped the md variable within /mxunit/framework/ComponentUtils.getComponentRoot() - line 59.

The "name" attribute was just ComponentUtils

There was a "path" attribute which was   /Users/peterbell/Sites/workspace/default/mxunit/framework/ComponentUtils.cfc 

I'm not sure that I see any metadata here that would help you. Excluding the extends and function data all I have is:

HINT   Internal component not generally used outside the framework

NAME ComponentUtils

OUTPUT true

PATH /Users/peterbell/Sites/workspace/default/mxunit/framework/ComponentUtils.cfc

TYPE component

fullname ComponentUtils 

At first I was wondering if path would be any use. The word "path" sounds promising, but when you look at the value you see that's the physical path, so if you change 

    package = listToArray(name,".");

to

    package = listToArray(md.path,"/");

it (unsurprisingly) doesn't work as it's trying to find components with class paths of Users.peterbell.Sites.workspace.<etc> . . . FWIW, if you wanted this, an easier solution would just be to expandPath(".") (or in this case, expandPath("../..") as you want two levels up), but I still don't think that's giving you what you want.

Anyhow, hope the additional information helps . . .

Best Wishes,

Peter

[Jon Messer]

That's what led me to believe it was apache, getMetaData().name should be the full dot path, and as soon as I put all my sites in the "expected" place it worked.

The weird thing is that in all other aspects coldfusion was working fine, just sites that use getMetadata().name explicitly and expect a dot path as the result were failing.

Making the change actually allowed me to run one of our work sites on my mac that wouldn't run because of this issue but for some reason I hadn't tracked the problem down to getMetaData()...

[Marc Esher]

I believe this is not a mac-only issue. I would not believe it, but I
saw it personally on a colleague's machine after he had installed
mxunit and tried going through the example tutorials. he magically
"fixed" the problem by running a test from within the eclipse plugin
(i.e. the test was initiated externally).

I'm wondering if the dreaded cfcexplorer being run in the "install"
page is somehow messing with CF, scrambling its brain or something.

[billy]

Eureka! Or, damn that water's slimy...

For some reason, Peter, your configuration is not returning the fully
qualified name of the component; e.g.,
mxunit.framework.ComponentUtils, which is what I expect. I'll have a
configurable fix for this in short order. But, this also warrants some
more research, and that would be what the expected values should be
returned from getMetaData()? My assumption is that it should return
the same values regardless of environment. So, if you've mapped mxunit
directly under the webroot, it should return
mxunit.framework.ComponentUtils.

BTW, nice job on the Pair Programming and TDD preso w/Ben! I'm going
to forward that to some folks here at work. I think your perspective
is quite convincing.

Thanks!
bill[y]

[Marc Esher]

Hey guys,
I came across this while investigating a separate issue but I"m
wondering if it's related.

this was a bug fixed in the 8.01 updater: 70782 When a mapping was set
for "/", complete component and interface paths
were note resolved correctly.

Peter, any chance you're still running without the updater and have a
"/" mapping?

I wonder if you installed the updater if your need to "hack" the
index.cfm file would go away.

Marc

[billy]

Peter,

I put a patch out in the repo. It does a couple of things:

1. In ComponentUtils.getComponentPath(), if getMetaData().name
returns ComponentUtils, "", or ".", it will use the following entry
from mxunit/framework/mxunit-config.xml:

<config-element type="userConfig" name="componentRoot" value="mxunit"
override="false" />

2. If it's _still_ failing, you can try to manually change this entry
in the mxunit-config.xml file and specify override="true" and the
value="mxunit" will be used as the root. The value attribute can be
changed too, to something like value="site.apps.mxunit", etc..

Please give that whirl. This should work. It also gives people the
ability to override mxunit's default behavior by allowing for the
specification of the componentRoot.

bill[y]

[Peter Bell]

Hi Bill,

Glad the mystery is revealed! Thanks re: the pair programming. I think
the approach really works for "remote test infection" and the pairing
with Ben has certainly helped me to get more into the habit of "test
first" - something neither of us were doing consistently before.

Best Wishes,
Peter

[Peter Bell]

I'm on a Mac on Leopard, so I actually installed 8.01 as 8 is a royal
pain to install on Leopard whereas 8.01 is "click n go". ALso, I don't
have a "/" mapping.

Oh well . . .

Best Wishes,
Peter