RE: [coldbox:17035] [3.5.3] AOP, DI, and FrameworkSupertype

I’m not 100% on aspects, but my understanding is that the way your aspect is injected into the target CFC (with the help of a run-time stub) probably means that the method in the aspect is executing outside of its original context in the CFC where you defined it. That’s means that the “variables” and “this” scope that you have access to would be that of the target CFC being wrapped. That’s my guess anyway. It would be nice if ColdFusion offered some sort of closure for mixins and the variables that were defined in their original scope.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Thanks for looking into this… I created a project which illustrates my issues: https://github.com/bendalton/coldbox-aop-problem

I added the stacktrace/errors to issue1 and issue2.html.

I’ve never quite understood how to create CB apps which work in sub directories, so you’ll probably need to use something like MAMP to map this directory to a temporary domain for testing… e.g., http://bens-aop-problem/

Actually, some additional context about the problems…

It looks like my DI/MessageBox issue is NOT caused by incorrect injections, but instead by the ‘flash’ scope variable used in MessageBox.cfc having the type of string and not having ‘put’ available.

This actually illustrates that I’m using a slightly different version of CB than 3.5.3… BUT I encountered the same problem when attempting to update my private fork to 3.5.3. The problem manifests itself in a different context, but in the end the MessageBox plugin (and perhaps other plugins) aren’t correctly getting a reference to the flash scope.

So, this problem is NOT directly related to AOP.

The other problem does still appear to be related to AOP (missing methods from FrameworkSupertype).

Cheers!
Ben

I recant my previous assertion that this is unrelated to AOP.

If I inject the MessageBox plugin into any Aspect, that instance/bean ends
up with a null value for the Flash scope. Then, anywhere else in the
application that I reference MessageBox, it is broken.

So, by avoiding this particular injection and by using an interceptor for
the functionality needed AND by calling announceInterception() on the
"target" of the advice.

I pushed this code back to the github repo.

So, for the purposes of this example, everything works. However, in the
greater context of my application, I fear I won't be able to do things so
cleanly.

I need to reference other dependencies in my advice that will likely break
in the same way MessageBox does.

*So, the question at hand is...*

So, do I need to use "provider" in my inject syntax? I find the
documentation about this approach in the WireBox wiki page to be confusing.
If this is the approach I need to use, could someone please provide
guidance on how to defer these dependencies?

   - coldbox:plugin:MessageBox
   - coldbox:setting:mySetting@MyModule
   - model:modules.my-module.model.MyService

Thanks!
ben

All you had to do was put the stack trace in here, with the code that is failing around that line, but from my observation the error messages no longer reflects the actual code.

Both the errors in both files are basic problems, the setNextEvent means you are trying to call this from an object that doesn’t have it, so you need to get the right object to call it on. But your code doesn’t use setNextEvent where it says the error is and I don’t see it so this error no longer applies.

The other one is a basic syntax in your code, but again it is no longer in your code, so how can we help you if your code has changed and the error message is not reflect in this change.

Ben, please post the error message you are getting, and the lines of code around the problem from your code.

When all else fails, make sure you have restarted ColdFusion and try again. If you have updated ColdBox and not done this it is possible to have such errors you initially talk about. But again when the error’s match the code maybe we can help, till then how do you expect us to help with dodgy information.

As my last message stated, these workarounds a might not be possible for a more involved aspect and while I still don’t understand why the supertype methods don’t work, I believe I just need to change my DI approach to defer evaluation if those properties.

Yes, you might have the original error message. But the code doesn’t reflect that any more. For example Issue2.html says can’t find nextevent, and yet there is no NextEvent in your AOP Aspect.

So how do we help you, then?

I posted a link to the code on github, it's a hosted git-based SCM tool.
It contains all revisions made to the code since I reported the problem. As
I pasted in the last link, there's a commit with the broken code, and a
commit with the working code.

e.g., (here's the aspect)

Sorry if I didn't make it clear..

For further clarity: http://www.screencast.com/t/Qbt4lFbES

So your expectation was for everyone to traverse through the changes to get the right match up :frowning:

Andrew, I’m sorry I wasn’t clear enough. The relevant files only have two revisions in total, one called “problems” and one called “working”. I REALLY TRIED to be as clear as possible to make it easy for people to help me.

I also thought i provided enough context in the emails and my problems and posting my modified working code was important to answer my latest set of questions. I should have posted it in a separate branch for clarity.

But, in the end, the problems aren’t in my code/syntax. They were/are that AOP DI behaves differently than DI in any other part of the a Coldbox app AND despite the fact that the Aspect (VTMOSecurity.cfc) is extended at runtime with FrameworkSupertype methods automatically, none of those methods are accessible.

The former problem is being addressed by using providers and the latter by finding other ways to accomplish the same functionality. But both are odd nonetheless.

-b

Yes you did, and I am not trying to come across as cranky here either, I just wanted to say that the extra effort you took might have hindered a quicker response to your problem.

And you probably did for those who really know WireBox in and out, like the developer himself, for someone like myself all I saw was an error that no longer related to that code. And yes I may have been smart enough to click on the revision, but I didn’t and assumed that the error message in the html files were suppose to match.

Anyway I learnt something more about providers, and I am glad that Brad was able to help you get forward.