Hi, All:
I’m having issues attempting to inject datasource into a custom plug using autowire. The below works fine in handlers, models, etc., just not in custom plugins:
property name=“dsn” inject=“coldbox:datasource:dsn” scope=“instance”;
In all cases, I get an injection DSL error. I am able to get the datasources, in the configure() method, by accessing through the settings.
Ideas?
Kevin S. Anderson
What is the error?
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Hey, Brad:
Attaching a screenshot. The error message is, “Builder.BuildCFCDependencyException : [N/A]” with lots of detail.
I can get the datasource by using controller.getSetting(“datasources”).dsnAlias, but that is not the preferred method.
Thanks!
Kevin
Are you trying to use the injected value in the init()? Please show some code.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Following is the code snippet with the property injection and the start of the init() method:
component
extends=“coldbox.system.Plugin”
displayname=“Authentication Plugin”
accessors=“false”
autowire=“true”
{
// Inject datasources
property name=“sysdbdsn” inject=“coldbox:datasource:sysdb” scope=“instance”;
property name=“sysgisdbdsn” inject=“coldbox:datasource:sysgisdb” scope=“instance”;
/**
Thanks for the additional info. Looking again at the error, I think Andrew may be right-- the error is not happening when trying to use the injected property, but rather when trying to inject it in the first place. I think a full stack trace is in order to see when this plugin is being built in relation to the overall ColdBox lifecycle. If the plugin is getting created while the framework is still loading up, the data sources might not be defined yet.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
I am sure this has been discussed before, a long time ago. The solution that I would go with is inject a method that will return the settings.
On a side note, I am not sure a plugin is not a good place to do authentication, a service would be better I think.
I have a workaround so I’m not going to worry about it too much. The reason for going with a plugin is because this would/could be used in multiple applications in our environment, and it is built to handle a lot of different environments (eg: Local Database, NTLM, Passport SSO, etc.).
In any event, I believe I’ve ran into this before, trying to autowire. Thanks for all the great feedback!
Cheers!
Kevin S. Anderson
INDURE Team Software Engineer
Intelligent Software Solutions Inc.
Global Enterprise Solutions Division
Phone: 719.452.7456 | Cell: 719.930.2599
Email: kevin.anderson@issinc.com
Can you share your workaround? I had additional suggestions to try, but I was waiting to share them until we got more information about the error. Specifically, if the issue turned out to be the plugin getting created prior to the framework being loaded, I was going to suggest that you just add “provider:” before your DSL to defer the actual resolution.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
That’s what a module is supposed to achieve.
Now I’m confused. My understanding is that a “module” basically provides a pluggable application with its own models, views, etc., although it can inherit from the base app.
A plugin, to me, provides the ability to provide an abstracted functionality, that is service oriented, similar to all the plugins provide in ColdBox (eg: mailPlugin, etc.), which extend the framework. By doing this as a plugin, it is not tightly coupled to the application.
Ah, well… The nice thing about standards is that there are so many of them, right? 
Kevin S. Anderson
INDURE Team Software Engineer
Intelligent Software Solutions Inc.
Global Enterprise Solutions Division
Phone: 719.452.7456 | Cell: 719.930.2599
Email: kevin.anderson@issinc.com
Hi, Brad:
My work-around was to add the following lines to the init() method:
instance.sysdb = controller.getSetting(“datasources”).sysdb.name;
Not elegant, but functional, I guess.
Kevin
A module can be what ever you need it to be, there is no set requirement for it to be tied to the base application, nor is it set in stone it has to provide views or even handlers.
I have gone as far as to create a module, just to add features based on interception points. Because it is a module, it is portable if nothing ties it to its base application. It only becomes tied if you make it so.
I agree with Andrew, if you are looking into building reusable security, a module would be the way to go. You can have the domain model (User, Role, Permission, SecurityService, etc) along with the appropriate controller handler for handling authentication and redirection all packaged nicely.
I’ve been thinking of building such a module for ColdBox similar to Grails Spring Security plugin (which we use for our Grails projects) but have been swamped this past year (someone may already have something like that too)… but either way highly recommend the module route.
</2cents>
This could quickly become a hot debate, however, I don’t agree with using a module, for a couple of reasons:
There are no user routes to any of this. It is a modular service only.
Using it as a module is, in my mind, major overkill.
The application only provides REST services. This plugin simply takes care of the numerous security providers that may be used by the system.
There are several reasons, but I hope that sums them up. Coldbox states that plugins are the way to extend the framework, which is what this is… simply an extension to the framework, not an extension to the application itself.
In any event, not a major sticking point, but I think a plugin makes more sense as it is controlled strictly by configuration, not the application environment itself.
Cheers!
Kevin
I think Kevin, you may need to revisit Modules. They can be as simple or complex as you need them, so yeah if you want a debate your on, because your perception on them is kinded misguided a lot, especially being over kill.
The example I gave before, has two files, ModuleConfig to set up the interceptor and the interceptor itself.
How is that any different to what your doing now?
with version 4, the idea of plugins is going away. theyre turning into modules now. everything is a module. simple or complex.
