[coldbox:4203] Modules not loading

I have a very simple convention structure which works on both Windows and ubuntu, however the module ForgeBox which can be run on Windows seems to throw the following error on ubuntu and I am at a loss to explain why.

Application Execution ExceptionError Type: HandlerService.EventHandlerNotRegisteredException : [N/A]

Error Messages: The event: forgebox:manager.index is not valid registered event.

Hmm, seems strange, can you verify the cases? It should be case sensitive compliant.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

The cases look fine so far, I’ll double check it again soon.

When I did a line debug I found that the modules had no registered handlers, if that is something to help figure it out it might point me in the right direction.

Ok everything is fine as far as cases go, I am at a loss to explain this.

I have noticed that in some of the paths (via line debugging) they are system.modules…forgebox, notice the double dot is this normal?

I downloaded forgebox again and placed it back into see if there might be another problem I might have caused, now as my very small application works fine on both Windows and Unix and the only thing is that I have got custom conventions outside of what is the norm. I am going to assume that these conventions are causing the issue for it to not work on Unix.

Really am at a loss to even explain this one.

Ok have tracked it down to the projects config of conventions paths, for example if I have this in my projects coldbox.cfc.

conventions = {
handlersLocation = “system/controllers”,
}

The module expects to find the handlers in the modulepath/system/controllers, and it also expects that the event be changed as well.

I see major problems with this, and although I can see the benefits I am not sure this is going to work.

That is to be expected my friend. The modules respect the parent’s conventions, they do not take it upon themselves to modify them. So if you modify the conventions, that is up to you. I can never guarantee what conventions the user’s might desire to work with.

It is an important note in the docs that says, if you use your own conventions, then make sure they are consistent.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Is this something that you changed recently?

Because it worked about a month or so ago, which is why it works on the Windows server as it hasn’t been updated as yet.

I see a major problem with this, because if I install other peoples modules then I am forced to manually go and change all the directories, and then the all the handler calls, routes and other things. Is this still by design what you are asking for us to put up with?

I am not sure at what version I have on the Windows Server as it was an update from SVN, but rest assured with my changed conventions the ForgeBox module does indeed work.

Also is the docs where the following is listed public, because I do not see this written anywhere…

At this point in time this was the first pass as modules and the decision was to make it inherit from the parent. There is a ticket to enable per-module conventions. I am still divided in the approach to take in modules.

One part of me would like this to be inherited from the parent, the other part in me is to make it standard and NOT changeable and another part of me is to keep it standard and changeable.

I need user input in order to make a decision before final release. At this point in time, I am thinking of going back to standard conventions and making them NOT changeable. This way, the modules are cross-platform, interchangeable and no messy figuring out parent structures.

Anyways, this is a point of discussions, so please make your cases.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

I have to agree part of me wanted this as well. In fact I raised it with you on the forums, in which you thought it was a bad idea.

The problem I see is that here is a stock standard module, ForgeBox. It is supposed to work out of the box and it doesn’t. This is because I moved all my handlers and views etc., into categories for this application.

To help explain this a bit more, before you introduced modules I was looking at my own method of implementing it. Which went along the lines of this as far as conventions goes.

Wwwroot

-system

-user

Under System I would hold all the functionality that was going to be to have the base system work, such as the handlers, views etc. In the user directory this was going to be any plugin/module to the system to enhance the application beyond the system.

So basically, I could define a user view that overwrote the system view by redefining the layout or the view to give it a different look and feel or functionality. I can still see this working, but I am excited about modules because it sort of helps were I wanted to go.

But I don’t feel that the full directory path system.module.handler should be inherited by a module, because it means I can’t just plug it in with serious modifications, I do think that the last directory in that path can be used for the convention definition just not the full path. Unless it is changed, by the user in the modules own convention path.

One thing that I was thinking about is that maybe, by default the module follows the standard convention which is what ForgeBox can be used as a guide here. If I write a module and want to inherit the parent application, then maybe I can have a setting that would do this. As well as a config setting in the moduleconfig to look at as well.

Hopefully that makes some sense.

I am thinking the order could be default to standard convention, then parent convention and last but not least overwrite by adding the convention to the module config file.

Thoughts?

I see that the code in SVN had been changed to fix this problem, after updating it on Linux I am still getting this error.

Application Execution ExceptionError Type: HandlerService.EventHandlerNotRegisteredException : [N/A]

Error Messages: The event: forgebox:manager.index is not valid registered event.

I am still at a loss to explain this.

Are you sure you are using SES? because that is not valid ses
Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

All I know is this.

My main application works fine, if I browse any of these urls in my application the correct page is displayed.

http://localhost/space/andyscott/
http://localhost/space/blog/
http://localhost/space/contact/

However if I try to browse ForgeBox

http://localhost/forgebox/

I get the error that I have reported, the setup is as follows.

Routes.cfm

Straight after posting this I went back to the config.cfc and I noticed this.

coldboxExtensionsLocation = “/system/extensions/”,
modulesLocation = “/system/modules”,
pluginsExternalLocation = “user/plugins”,

Extensions seems to work with the extra forward slash, but modules doesn’t and I found that if I removed this then I was able to run ForgeBox without any problems.

HI Andrew,

Just so I can write a good ticket for this. When you change the modulesLocation to have the extra slash it works but if not, it fails?

// FAILS
modulesLocation = “system/modules”

// WORKS
modulesLocation = “system/modules/”

Is this correct?

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

No the other way around, but from your latest tickets you figured that out.