Hoping someone on here knows ColdFusion, and further, may know what is going on.
<cfscript>
sz_test1=ExpandPath("/app/folder/afternoon.jpg");
sz_test2=ExpandPath("app/folder/afternoon.jpg");
WriteOutput(sz_test1&"<br />");
WriteOutput(sz_test2&"<br />");
abort;
</cfscript>
Simple code, simply outputting ExpandPath() results.
Situation:
Website running ColdFusion 11 prints out an image to a page based on time of day.
Simple page, if it's in afternoon, you get afternoon.jpg, otherwise morning.jpg.
ExpandPath is required since we actually output the page contents to a pdf (cfdocument + cfimage), which isn't important for purpose of this question. But letting you know so no one suggests not using ExpandPath as a resolution..
Problem
Somehow on this page, just 5 minutes ago, the resultant for variable sz_test1 would come back with the ColdFusion path. Not the web root path.
C:\Coldfusion11\CFIDE\app\folder\afternoon.jpg
whereas sz_test2 would give:
C:\inetpub\wwwroot\app\folder\afternoon.jpg
So naturally the file doesn't exist in the first case.
But now, suddenly, ColdFusion is no longer doing that. Both tests return the exact same result. This has been consistently happening (consistently inconsistent results) for a few weeks.
Question:
Anyone know what would cause the ExpandPath() function to:
Return inconsistent results when prefixed with a slash
Return different results suddenly without any change to the code (or environment) whatsoever.
You might want to try using
thisPath=getDirectoryFromPath (getCurrentTemplatePath);
thisFile="#thisPath#/folder/afternoon.jpg";
It's a little bulky but might get rid of the inconsistent behavior.
Related
I have been trying to use Clojure Script with Light Table and lein-cljs without much success.
The main problem seems to be with dependencies. It seems like evaluating a cljs (ctrl-shift-enter) page does not recursively evaluate the dependencies. The result of this is that I have to manually evaluate each dependent file. If I refresh the HTML page, or make a change I have to do this all over again. Other times evaluating a page doesn't work, and just gives me good not found error.
Clearly this is not usable. Am I doing something wrong? For Clojure it seems to work just fine.
Stack Overflow is probably a bad place to learn more about Light Table. I'd drop into the Light Table channel at #lighttable on irc.freenode.net. Somebody can help you there!
I am hoping I can get an answer to this. We recently migrated a ColdFusion site to a new server, which has ColdFusion 9. The older server had 7 on it, maybe 8. Everything was working find on the old system. Now, I get the Element Undefined Errors.
The Application.cfm (not .cfc) is in the webroot where it always was. There is no Application.cfc file.
Here is a screen shot of the Application dump:
Here is a sample page with the error: http://www.luxurylifestyle.com/listings/send_message.cfm?id=26552
So, in the screenshot above, there is the captchaseed, etc., but when it tries to call it - it says it's undefined.
Any help is GREATLY appreciated! I am sure this is something easy, but I've never done this migration before, so have no idea why it won't work.
ADDED FROM THE COMMENTS
In the Application.cfm, located in the web root, there is the following:
<cfset APPLICATION.captchaseed = 'ACDEFGHJKLMNPQRTUVWXY34679'>
Here is a link to the screen shot with the cfdump.
Here are a few examples of the undefined errors for reference: http://www.luxurylifestyle.com/listings/send_message.cfm?id=31820
http://www.luxurylifestyle.com/newsletter_box_action.cfm
I don't think we've got enough to answer this yet, but let's try.
Can you check your file system between send_message.cfm and the Application.cfm in your root directory, and check if there's any other Application.cfm in between.
Also check for any <cfapplication> tags in any of the files making up the request.
Can you also check your code for anything that might be clearing the application scope, or elements in it.
Can you also pls put a try/catch around the line that's erroring, and dump out the application scope at that point.
I suspect you have a second being initialised somewhere during your request which is overwriting the one you're expecting. This is, currently, just speculation.
I'll update this answer as more info comes in.
I have a fairly long cfc file, about 1800 lines long, that worked fine in ColdFusion 8, but after upgrading my development system to ColdFusion 9 and doing some testing I get a compile error for a cfc and the message says "Branch target offset too large for short". I modified the file to eliminate some unused functions and consolidated one to make it shorter and this resolved the problem to get it to work. But still, why did it die on me now when I upgraded to CF9? Anyone else run into this problem in previous or the current version of ColdFusion? Are there any solutions other than modifying the cfc file such as upgrading the jvm?
EDIT
If you have an answer to the questions I have, great! Post that, but don't waste time telling me something that I already know. If you are going to post a response, please read the question carefully and answer only if you know the answer. Don't do a google search and post crap that I already know and utilized to get the code to work. The question is, why did it work in CF8 and now not in CF9? Are there other solutions besides what I did?
This is a problem inherent with the JVM as you already know, CF9 has likely added more innate functions to a component and if the methods are all referenced via a giant switch statement with a short being used as the offset, we have less offset pointer space to work with each successive version. People moving from CF7 to CF8 also had the same problems.
So short answer is no.
Most recommendations you find basically tell you to split a large method into a smaller method and several helper methods. The first time I ran into an issue this worked for a large cfc I had. But then as it got bigger no number of helper functions would fix it. Eventually it had to be split into multiple cfcs.
PS: This guy said removing a transaction helped (CF7), there are none wrapping my calls though, so it's not a guaranteed fix I guess http://www.coldfusionmuse.com/index.cfm/2007/9/28/Branch.Target.Offset
Edit
Looks like my previous issue was a different function being too large, splitting the CFC into multiple CFCs was in error. I've since split that problem method into smaller methods, and have been able to consolidate all the functions in one CFC. So that is the solution it seems.
If you haven't already, try running the Code Analyzer in the CFAdmin page, "Debugging & Logging > Code Analyzer". This is a useful tool to find some changes which were made in the language between CF8 and CF9.
We had to change several variable names and function names as CF added them in 9.
Also check here:
http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7ff0.html
CF version: 10
OS: Linux CentOS 6.0
Did face a similar issue where I had 1300+ lines of code in my cfc and one fine day I get the "Branch Target offset.." error. I tried
Code Analyser to find any loopholes of legacy- DID NOT FIX
Edited the cfc to trim down any last bit of redundant code or comments - reduced around 20+ lines of code - DID NOT FIX
I split the code into 2 cfc and extended one to the other- DID NOT FIX
I removed any unwanted dump of queries and arrays (part of testing) : THIS WORKED
so I would suggest ensure you don't have any dumps of large data content. Hope this helps.
coldfusion.compiler.FactoredNodeAggregation cannot be cast to coldfusion.compiler.ASTfunctionDefinition
I get the above error when attempting to replace a really, really old legacy custom tag with a new custom tag that has some substantial workflow improvements. I only have one idea on how to debug this: comment out different parts of the code (binary search style) until it will compile, narrowing my search until I find the problem code.
Has anyone else ever seen this error before? Any idea what it could possibly be? Contextually, it sounds like I'm trying to use ... something... as a function that isn't defined as a function. That doesn't ring a bell so I'm going to try the binary search idea.
Update: It's running on CF 8.0.1, and doesn't use any <cfscript> blocks at all. Using the binary search of commenting out, I've narrowed it down to a CFThread that starts a background thread that never re-joins the page (by design).
If I comment out the entire contents of the thread, the error goes away (so the cfthread tag itself doesn't appear to have problems on its own...). If I copy the contents of the thread to its own template, that template will compile fine (so the thread contents doesn't appear to have problems on its own...)... so... in theory it should work? I don't know. This is me with my arms up in the air. (WTF?)
I think I've already disproven this idea by un-commenting a small section without the error coming back, but a CFThread should have access to local custom tags that the template creating the thread would have, right? so if there's foo.cfm, it could be accessed from the page as <cf_foo>, and the thread could do the same?
In the last week I've been in contact with the ColdFusion Engineering team at Adobe about this issue and they confirmed for me that this is a bug in ColdFusion.
Specifically, if the number of lines of code inside the thread tag body was too large, it would cause a compile error. The work-around, which I discovered a day or two before I got my answer, is to use a <cfinclude /> to import your thread contents from another file; or to put the code into a method somewhere and call that method from inside the thread body. (Presumably, a custom tag or other clever methods of encapsulation would also work.)
That explains the part of the whole thing that was driving me absolutely insane: that commenting out various parts of the thread body would sometimes make it compile... and now I know it was because enough of the thread body was commented out.
They report that they have fixed the bug, so I assume it will be fixed in the next cumulative hot-fix (if there is one), and in ColdFusion 9.
Since I can't comment yet, Adam, is it really a bug with CF or with the JVM? There's a similar limit on how many lines of code can be compiled within a CFFUNCTION, but the limit is really in the JVM, not the CF tag.
Oooh, that's one I've not seen before.
Depending on what the custom tag does, rather than commenting out different parts, you could try using cfabort - same technique, but only one line to change rather than uncommenting and re-commenting (which can be fiddly and time-consuming).
Also, are you able to test the custom tag in isolation, with completely simplified arguments/etc?
If you're able to post the code, there might be something odd that jumps out at a fresh pair of eyes?
that error usually comes up when you have a function that is set to remote. kinda funny that your getting it with a custom tag though. are you sure that the custom tag doesn't have any functions in it? can you post the code?
Strange that it is a compilation error. If the code base is not too huge I would make sure all variables in the thread and called udfs are explicitly scoped.
Next I would move as much externally referenced data into the thread arguments scope to isolate the interactions with the page.
Finally if that does not clear it up I would try mangling the names of every variable, function and udf the thread accesses a bit with some test prefix just to make sure that you have not hit a bug where one of your vars or funcs is causing a namespace collision in the jvm in the context of the original page.
Tricky problem.
Have you deleted the compiled class files and saved the original source to a new file just in case something weird occurred during a save?
Have you tried reinstalling CF8.01? Maybe some files got corrupted?
I'm increasingly becoming aware that there must be major differences in the ways that regular expressions will be interpreted by browsers.
As an example, a co-worker had written this regular expression, to validate that a file being uploaded would have a PDF extension:
^(([a-zA-Z]:)|(\\{2}\w+)\$?)(\\(\w[\w].*))(.pdf)$
This works in Internet Explorer, and in Google Chrome, but does NOT work in Firefox. The test always fails, even for an actual PDF. So I decided that the extra stuff was irrelevant and simplified it to:
^.+\.pdf$
and now it works fine in Firefox, as well as continuing to work in IE and Chrome.
Is this a quirk specific to asp:FileUpload and RegularExpressionValidator controls in ASP.NET, or is it simply due to different browsers supporting regex in different ways? Either way, what are some of the latter that you've encountered?
Regarding the actual question: The original regex requires the value to start with a drive letter or UNC device name. It's quite possible that Firefox simply doesn't include that with the filename. Note also that, if you have any intention of being cross-platform, that regex would fail on any non-Windows system, regardless of browser, as they don't use drive letters or UNC paths. Your simplified regex ("accept anything, so long as it ends with .pdf") is about as good of a filename check as you're going to get.
However, Jonathan's comment to the original question cannot be overemphasized. Never, ever, ever trust the filename as an adequate means of determining its contents. Or the MIME type, for that matter. The client software talking to your web server (which might not even be a browser) can lie to you about anything and you'll never know unless you verify it. In this case, that means feeding the received file into some code that understands the PDF format and having that code tell you whether it's a valid PDF or not. Checking the filename may help to prevent people from trying to submit obviously incorrect files, but it is not a sufficient test of the files that are received.
(I realize that you may know about the need for additional validation, but the next person who has a similar situation and finds your question may not.)
As far as I know firefox doesn't let you have the full path of an upload. Interpretation of regular expressions seems irrelevant in this case. I have yet to see any difference between modern browsers in regular expression execution.
If you're using javascript, not enclosing the regex with slashes causes error in Firefox.
Try doing var regex = /^(([a-zA-Z]:)|(\\{2}\w+)\$?)(\\(\w[\w].*))(.pdf)$/;
As Dave mentioned, Firefox does not give the path, only the file name. Also as he mentioned, it doesn't account for differences between operating systems. I think the best check you could do would be to check if the file name ends with PDF. Also, this doesn't ensure it's a valid PDF, just that the file name ends with PDF. Depending on your needs, you may want to verify that it's actually a PDF by checking the content.
I have not noticed a difference between browsers in regards to the pattern syntax. However, I have noticed a difference between C# and Javascript as C#'s implementation allows back references and Javascript's implementation does not.
I believe JavaScript REs are defined by the ECMA standard, and I doubt there are many differences between JS interpreters. I haven't found any, in my programs, or seen mentioned in an article.
Your message is actually a bit confusing, since you throw ASP stuff in there. I don't see how you conclude it is the browser's fault when you talk about server-side technology or generated code. Actually, we don't even know if you are talking about JS on the browser, validation of upload field (you can no longer do it, at least in a simple way, with FF3) or on the server side (neither FF nor Opera nor Safari upload the full path of the uploaded file. I am surprised to learn that Chrome does like IE...).