Bugs in my parsley…

February 4, 2011

The dependency injection in Parsley is nice when it works, but what do you do when your objects aren’t configured properly and you get an error like this?

Error: Error in message receiver
at org.spicefactory.parsley.core.messaging.impl::DefaultMessageProcessor/unhandledError()[I:\Spicefactory\Parsley\parsley-core\org\spicefactory\parsley\core\messaging\impl\DefaultMessageProcessor.as:134]
at org.spicefactory.parsley.core.messaging.impl::DefaultMessageProcessor/handleError()[I:\Spicefactory\Parsley\parsley-core\org\spicefactory\parsley\core\messaging\impl\DefaultMessageProcessor.as:128]
at org.spicefactory.parsley.core.messaging.impl::DefaultMessageProcessor/proceed()[I:\Spicefactory\Parsley\parsley-core\org\spicefactory\parsley\core\messaging\impl\DefaultMessageProcessor.as:107]

There’s the brute force approach: just comment stuff out until it stops breaking, then you know where the issue is. This is crude, time-consuming and problematic…what if you forget to uncomment the code out? This happened to a client of mine recently.

You can step it up by configuring logging for Parsley. I added the following to my application’s <fx:Declarations> block:

        <mx:TraceTarget id="logTarget"

With logging on, I learned a little more about my error, namely:
Caused by: Error: Unsatisfied dependency: Context does not contain an object of type mx.rpc.remoting::RemoteObject

Better, but where exactly in my code is this occurring?

Time to step it up again and enable source code level debugging. First, you need the source code. I selected “Import…” then “Checkout Projects from SVN” and checked out http://opensource.powerflasher.com/spicefactory/svn/parsley/trunk/main. This gave me an error at the end, but it didn’t really matter for my purposes.

Once I got the source code, I edited my project’s settings, went to Run/Debug Settings and edited my main application’s launch configuration to add the Parsley folder to the Source path (with ‘Search subfolders’ checked).

So, next I just searched for where “Unsatisfied dependency: Context does not contain an object” messages were thrown and set breakpoints wherever they occur. Long story short, I stopped inside ObjectTypeReference.resolve() and worked my way up the call stack to find that the problem was with my “SaveUserCommand” class that had this erroneous declaration:

        public var service:RemoteObject;

Well, that was a little annoying, but a good “learning moment.” Moving on…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: