Installation questions / problems; hoping for some guidance

[Ron Stewart]

I'm trying to get a copy of Xindi set up on one of my development boxes to evaluate it and have bumped into several problems just in getting it set up.

My dev box is running Mac OS X 10.9.5, with Adobe ColdFusion 10 deployed via WAR on Tomcat 7.0.55, and running against Java 1.7.0_67. I should also preface this with the statement that I have never done anything with FW/1 to date, and that may be a part of what I am bumping into.

I downloaded the CFML version of the ZIP archive from https://github.com/simonbingham/xindi/zipball/master and extracted it to a folder "wiki" off my server's webroot. I have a datasource configured in the CFadmin and the datasource verifies. I modified the ./Application.cfc file's getConfiguration method to specify a name ("wiki" for now) but didn't tweak anything else in there for now.

I browse to http://localhost:8080/wiki/index.cfm?rebuild=true and I get the default public page. So far, so good... but this is where I start to encounter problems.

1. If I browse to just ./wiki/index.cfm, I get the public landing page but all of the other pages linked from there (e.g., ./wiki/index.cfm/design, ./wiki/index.cfm/training, etc.) result in completely blank pages. Looking at the URL format, those looked to me like something related to an SES-friendly URL format, so I changed the "generateSES" setting for FW/1 to false on line 42 of ./Application.cfc and reloaded. After that change, I do get content that appears more like I would expect on most of the links off the landing page and the links are of the form ./wiki/index.cfm?action=home, ./wiki/index.cfm?action=design, etc. This doesn't particularly concern me, as I don't necessarily care about search engine friendliness within the context where I am considering using Xindi. Moving on...

2. The next thing I bump into is that when I try to go to the content admin interface at ./wiki/admin, the application throws an error:

Error Occurred While Processing Request

Provide an application name.

Creation of unnamed applications has been disabled in ColdFusion administrator.

 

We do in fact run our servers with creation of unnamed applications disabled. At this point in this process, I am not particularly concerned about this setting so I am OK with turning that restriction off in order to move forward. I toggled the setting within the CF admin, reloaded the application, and browse to ./wiki/admin and am redirected to the following URL:

http://localhost:8080/wiki/index.cfm/admin:main

which results in a completely blank page. This again appears to be related to SES URLs, but there's nothing in the ./wiki/admin/Application.cfc to configure this, it appears to just be redirecting to that URL without accounting for whether the application has been configured to run w/o SES URLs.

I'd welcome any thoughts on where I should look or what I might need to do in order to get the admin interface working.

3. Next problem: although most of the links in the public part of the site seem to work, if I attempt to go to the "Site Map" link that appears at the bottom of most of the pages (http://localhost:8080/wiki/index.cfm?action=navigation/map), the application throws the following exception:

Error Occurred While Processing Request

Java method security exception.

A security exception occurred while invoking Java method on a "java.lang.Class" object. MethodName is GetClass. Possible cause: Either the createobject function and cfobject tag are disabled in the security sandbox or you are trying to create a class in the ColdFusion package and that is disabled.

 

The error occurred in /Users/ron/Sites/apps/wiki/frameworks/hoth/HothTracker.cfc: line 235

Called from /Users/ron/Sites/apps/wiki/frameworks/hoth/HothTracker.cfc: line 179

Called from /Users/ron/Sites/apps/wiki/frameworks/hoth/HothTracker.cfc: line 61

Called from /Users/ron/Sites/apps/wiki/Application.cfc: line 118

233 : http://fusion.dominicwatson.co.uk/2007/09/coldfusion-objects-are-java-objects.html **/

234 : private function GetClassHeirarchy(obj) {

235 : local.thisClass = obj.GetClass();

236 : local.sReturn = thisClass.GetName();

237 : 

Resources:

Check the ColdFusion documentation to verify that you are using the correct syntax.

Search the Knowledge Base to find a solution to your problem.

Browser   Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2176.0 Safari/537.36

Remote Address   0:0:0:0:0:0:0:1

Referrer   http://localhost:8080/wiki/index.cfm?action=news.article&slug=sample-article-b

Date/Time   03-Oct-14 06:28 AM

Stack Trace

at cfHothTracker2ecfc847514610$funcGETCLASSHEIRARCHY.runFunction(/Users/ron/Sites/apps/wiki/frameworks/hoth/HothTracker.cfc:235) at cfHothTracker2ecfc847514610$funcPARSEEXCEPTION.runFunction(/Users/ron/Sites/apps/wiki/frameworks/hoth/HothTracker.cfc:179) at cfHothTracker2ecfc847514610$funcTRACK.runFunction(/Users/ron/Sites/apps/wiki/frameworks/hoth/HothTracker.cfc:61) at cfApplication2ecfc199238983$funcONERROR.runFunction(/Users/ron/Sites/apps/wiki/Application.cfc:118) 

coldfusion.runtime.StructBean$SecurityException: Java method security exception.

at coldfusion.runtime.StructBean.checkPermission(StructBean.java:96)

at coldfusion.runtime.StructBean.invoke(StructBean.java:482)

at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:2465)

(rest of stack trace snipped)

I know that createObject() and cfobject are not disabled, as we use them heavily in our applications which I also have running on this same dev server. I get similar exceptions if I attempt to go the sample pages which are linked off the "Consulting" dropdown menu on the public landing page. Having said that, the "News" page works and going to the sample pages linked from the "News" page works.

If any of you can provide guidance as to where I've gone wrong in setting this up, I would be grateful. If I can provide any additional diagnostics to help troubleshoot, let me know what might help.

Thanks in advance!

-- 

/ron

[John Whish]

Hi Ron,

I've not run Xindi on CF10 before. Looking at point 3, I'd say that's actually an error in Hoth (which ironically is a library for handling errors), so if you comment out line 118 in Application.cfc you should get to see the original error. https://github.com/simonbingham/xindi/blob/master/Application.cfc#L118 

What error does that show you?

Cheers,

John

--
You received this message because you are subscribed to the Google Groups "Xindi CMS CFML" group.
To unsubscribe from this group and stop receiving emails from it, send an email to getxindi+u...@googlegroups.com.
To post to this group, send email to getx...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/getxindi/0ee31aa4-374a-47e2-86b7-6a7da25d9ba0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ron Stewart]

Thanks for the follow-up, John.

Commenting out line 118 of Application.cfc and trying to go to the navigation map link generates the following exception (screenshot 1, attached):

Exception in onError

Element CONFIG.EXCEPTIONTRACKER.EMAILNEWEXCEPTIONS is undefined in RC.

The stack trace starts at wiki/Application.cfc line 119, works its way through the FW/1 framework.cfc, and ends at wiki/public/views/main/error.cfm line 4.

Looking a little at wiki/public/views/main/error.cfm, I moved the <cfdump > tag up above the check that was throwing that exception (since it seems like the application is still encountering problems handling an underlying error), and see the following being thrown from deep within FW/1:

struct
Detail	Actions are not allowed to embed sub-directory paths.
ErrorCode	[empty string]
ExtendedInfo	[empty string]
Message	Found a slash in the action: 'public:navigation/map.default'.

See screenshot 2.

I'm hoping this actually sheds some light on where things are going sideways...

[Ron Stewart]

A bit more follow-up on this: based on my original #2, above, and the nature of the error being thrown in #3, I decided to investigate a hunch. I haven't seen it stated anywhere (perhaps I just missed it), but both of these (my #2 and the error being thrown) seemed to me to be implying that Xindi and/or its default content are assuming the application and the application server are configured for SES URLs. Where I am running on Tomcat, my CF10 server is not. So I tweaked the CF10 web.xml to work with ./wiki/index.cfm/* and backed out the one change I had made to ./wiki/Application.cfc on line 42 (described in my note #1, above) related to this setting. In my limited poking this morning, everything now seems to work.

At this point, I can start actually playing a bit with the capabilities of Xindi.

I'm left with a couple of thoughts/questions remaining:

1. Given what I've seen, I need to convince myself that the Hoth-based error-handling is working (the nature of the exceptions being thrown don't seem to me to be related to the SES URL configuration, but I suppose that is something so fundamental in the underlying application architecture that it could break everything in weird ways).

2. I'll go back and re-read the entries in the Xindi wiki to see if I missed something about the requirement for SES URL handling as an underlying requirement/assumption. If it isn't there, it seems like it would be helpful to touch on it. If it is there, perhaps it could be made a little more prominent?

3. I'm wondering about the unnamed application setting for the admin, and the implications of that, particularly in situations where someone might deploy multiple copies of Xindi on a given CF server and need them to run as completely separate applications. Part of this is likely to be ignorance on my part, as we have always required named applications on all of our servers so I just don't know how multiple unnamed applications interact in terms of their application scopes. 

[Simon Bingham]

Hi Ron,

Good to hear you resolved your earlier problems.

`1. Given what I've seen, I need to convince myself that the Hoth-based error-handling is working (the nature of the exceptions being thrown don't seem to me to be related to the SES URL configuration, but I suppose that is something so fundamental in the underlying application architecture that it could break everything in weird ways).`

I think, as John suggested, the issue with SES URLs not being configured on your server was somehow causing Hoth itself to through an error. I'm assuming Hoth is working correctly now? 

`2. I'll go back and re-read the entries in the Xindi wiki to see if I missed something about the requirement for SES URL handling as an underlying requirement/assumption. If it isn't there, it seems like it would be helpful to touch on it. If it is there, perhaps it could be made a little more prominent?`

I'll add something to the wiki about SES URLs being required. Currently, SES URLs are mentioned in reference to Railo (https://github.com/simonbingham/xindi/wiki/3.-Frequently-Asked-Questions#why-dont-the-ses-urls-work-on-railo), but not ColdFusion.

`3. I'm wondering about the unnamed application setting for the admin, and the implications of that, particularly in situations where someone might deploy multiple copies of Xindi on a given CF server and need them to run as completely separate applications. Part of this is likely to be ignorance on my part, as we have always required named applications on all of our servers so I just don't know how multiple unnamed applications interact in terms of their application scopes.`

I've created an issue for this - https://github.com/simonbingham/xindi/issues/130.

Thanks,

Simon

[Ron Stewart]

Thanks, Simon. 

I'm going to introduce an error somewhere specifically to make sure the Hoth framework is functioning, and will follow up.