Is there a way to stop ColdFusion 11 from caching Fusebox circuit.xml.cfm files?
I have to restart the coldfusion service every time I make a change to a fuseaction file and it's getting tiring.
There are 2 settings in play here. One is "trusted cache" - a setting in the CF admin that does not "check" for a modification once a class has been compiled. You can turn trusted cache off and CF will begin to check for modifications.
The second (and more likely) setting is "parsed" setting. This setting actually saves all your include files into a "parsed" directory and compiles the from there. You can try adding the following to your URL:
Fusebox.parseall=true or alternately Fusebox.loadclean=true - one of these might work.
Finally there is a "mode" setting you can modify to "development" from "production" - that will cause the whole thing to be reparsed.
This is from memory - but maybe it will be enough to get you going. good luck! :)
Related
Looking at the docs, all the logging paths specified for console-capture and requestlog are relative to jetty.base, normally in $jetty.base/logs . That's ok for many purposes but, I really want logs to go into /var/logs/jetty , just like a lot of other processes would do. I've tried setting this in console-capture as /var/log/jetty, but that just tries to save log files in $jetty.base/var/log/jetty, which isn't what I need.
Is there some way to do this? I'm looking for the simplest possible approaches to saving logs. This is the last thing I need to do before my Jetty installation is fully in production. Overall it's been great. This is all with Jetty 9, latest release, on Ubuntu.
Start by not using console-capture.
You have progressed beyond the limited scope of console-capture with your requirement.
You'll want a formal logging framework, pick one, like "logback" (which the Jetty devs recommend), or java.util.logging, or log4j.
Use one of the logging-* modules to setup Jetty's server classpath to start using that logging library.
Now configure that logging library (example: if you are using "logback", the file ${jetty.base}/resources/logback.xml is what you configure)
Finally, configure your access logging to use slf4j.
Boom, all of your logging is now going to your logging library of choice, and it's configuration can be used to slice / dice / roll over / filter / etc the logging in any way you want.
You can have it split into different logging output files, combine them into one, roll on different rules (size, number of lines, duration, time, etc).
Definitely made some progress on this. For some reason, console redirect was taking the absolute path correctly while the request logger was not. For that, I made my configuration relative: ../../../var/log/jetty
This seems like a clunky way to do it but it does seem to work. I'm still getting a failure on startup but weirdly enough it's running fine and I don't see exceptions so I need to figure that out now.
I am trying to use Coldfusion CFPRINT to print UPS labels to a network printer. The starting labels (png files) are great and I can print them locally to the zebra printer and they print and work wonderfully. The barcodes produced by CFPRINT however are of such poor quality that a barcode scanner cannot read them. My research shows that Coldfusion uses the jpedal java library which resizes the images to 72 dpi - which is just not crisp enough for a scanner.
I read about using a jpedal setting: org.jpedal.upscale=2 but I have no clue as to where you would utilize this.
Any suggestions on how to fix this CFPRINT resolution issue using Coldfusion?
(Just to add a bit more detail to the comments)
That is a JVM argument. There are several ways to apply it:
Add the setting to your jvm.config file manually. Backup the file first. Then add -Dorg.jpedal.upscale=2 to the end of the java.args section. Save the changes and restart the CF Server. Do not skip the backup step! Errors in the jvm.config file can prevent the server from starting. So it is important to have a good copy you can restore if needed.
Open the CF Administrator and select Server Settings > Java and JVM > JVM Arguments. Add -Dorg.jpedal.upscale=2 to the end of the arguments. Save the settings and restart the CF server.
Again, I would strongly recommend making a backup of the jvm.config file first. As #Mark noted in the comments, some versions of CF have been known to mangle the jvm.config file, which could prevent the server from starting. But as long as you have a good backup, simply restore it and you are good to go.
IIRC, you could also set the property at runtime, via code. However, timing will be more of a factor. Their API states system properties must be set before accessing JPedal. The docs are not clear on exactly what that means. However, the implication is the system property is only read once, so if you set it too late, it will have no affect.
// untested
sys = createObject("java", "java.lang.System");
prop = sys.getProperties();
prop.setProperty("org.jpedal.upscale", "2");
sys.setProperties(prop);
Side note, I was not familiar with that setting, but a quick search turned up the CF8 Update 1 Release Notes which mention this setting "improves sharpness, but it also doubles the image size" and also increases memory. Just something to keep in mind.
I've been having a sporadic problem for a few weeks where on restarting the CF Server (Enterprise 9) one of my applications runs without ColdFusion referencing all the variables in the Application.cfc file. It's in the same folder as the CFML pages, it IS properly capitalised as Application.cfc, but it seems to just be ignored. Obviously this causes problems with datasource name and all the other variables I set in Application.cfc. For reference, I'm using an Application.cfc file based on Ben Nadel's excellent intro at http://www.bennadel.com/blog/726-ColdFusion-Application-cfc-Tutorial-And-Application-cfc-Reference.htm . Usually my requested template runs as an include and I can see it in the stack using debugging output, now I can't see it there at all. It's as if the file just doesn't exist.
Has anyone else experienced this, or can you think of possible solutions? Note that at times a restart has got the whole thing running perfectly smoothly.
Re folder structure it's really simple: the Application.cfc file is in the web root along with executable CFML templates - included templates, images, CSS etc are in separate folders referenced via relative paths.
There is another application with its own similar Application.cfc file that is in a sub-directory of the web root. This is running perfectly.
Try clearing your template cache. I've see cases where CF just gets flakey and the cached files are causing issues. Another option: Does ColdFusion have permissions to read/execute the Application.cfc? If this WAS an issue but is no longer an issue I've seen cases where the template cache was causing these files not to be found. Again, delete these files (from disk, not the cfadmin) and try again.
Today, no matter what I did, my application just would not recognise a change I did to a file I uploaded. I even put a cfabort at the top of the page and it just ignored it.
Now, this is a production server, so there were some things I normally have to do for the fusebox framework to load the new pages. However, all the usual processes failed and I even tried numerous others. Let me list them:
Normal Process:
&fusebox.parseAll=1&fusebox.password=whatever <- Did not work
&fusebox.load=1&fusebox.password=whatever <- Did not work
Other things I tried:
* changed mode from production to development-full-load <- Did not work
* called onApplicationStart to reset app <- Did not work
* changed the application name to reset app <- Did not work
* deleted parsed folder and regenerated <- Did not work
No matter what I did (they may have been more that I just don't recall at present) nothing would refresh the page. The only thing that worked after I was at my wits end, was to stop the Railo server, restart it and then run the thing I tried first again, being:
&fusebox.parseAll=1&fusebox.password=whatever
That worked. So my only assumption can be that somehow, somewhere in the one of the applications, the cached code was being used to regenerate the parsed files instead of the actual updated file.
Has anyone experienced this before and do you have any solutions to avoid this. I can not keep restarting my production application just to update a changed file.
Thanks
From what you've said it sounds like Trusted Caching may be turned on, which is an odd name but basically means "I trust that these files will not change, so don't bother checking" or something like that. The main thing is it doesn't look at your cfm/cfc files for changes, which is faster, but of course very annoying when you make changes.
On Railo, that can happen at the per-mapping level, so first thing is to check all your mappings to see if the "Trusted" option is enabled - unless your site is high enough traffic that it's beneficial, for a Fusebox app it's probably more hassle than it's worth - so for any relevant mappings, unless you specifically need it, go ahead and disable it.
There is also a similar global caching option - in Railo Web Admin, go to Settings>Performance/Caching and most likely you want to have "Inspect Templates" set to "Once". If it is set to "Never", this is same as Trusted cache, which again is faster but not best for a changing site.
However, you may have noticed there is a "Clear template cache" button below - if you prefer to keep it on "Never" you can press this button each time the code changes, and it will rebuild the cache with the latest files.
I'm starting some work on an existing ColdFusion application with no version control and what look like unused cfm files (test.cfm, test2.cfm etc.). I'd like to get a picture of what files are actually part of the application so I can get it into git or subversion in a manageable state.
How would you go about this? A regex and some methods to find and map cfinclude and cfcomponent tags? Is there some existing tool that does this?
Ben Nadel has a method to examine the live stack trace from a running template. It seems to me that you could easily plop this into your application and log the results to a database. Once you've done that, you've got a good idea of what's in use and what's not.
I think the easiest way, however, is to enable debugging (standard caveat here about development server, etc). The standard ColdFusion debugger will give you a complete list of every file used during the execution of a single page. ColdFire will do the same thing in a handy Firebug extension (click ColdFusion then click Exec Times).
It should be pointed out that the built-in debugger even shows you the files included from CFC calls, and the files included from within those calls as well. It is all inclusive.
Ben Nadel on Stack Traces
Ray Camden's ColdFire
Sample of CF Debugging from a live page:
Put it into git first! Then, if you screw up, you can easily roll back.
(If you're concerned about having a 'clean' repository, when you're finished and fully tested, you have the option to just remove the single .git folder and create a new one.)
Then, as Tomalak suggests, use cflog on every file. Infact I'd say maybe even log twice, at the top and bottom of each script, could potentially help you to map out how the application runs.
A regex is not advisable. Since ColdFusion is quite flexible in the way files can be included or referenced, there will be no way to determine the definitive list of dependencies from the source code alone.
You could insert a <cflog> into each file and build a log from the running application. Examine the log after the application was active for a while and all functionality had been accessed at least once.
Don't bother instrumenting each file, just cflog the page name in OnRequest inside application.cfc - the target page is an argument.
Of course then the issue becomes code coverage and the ability to fully excercise the app.
<cffunction name="onRequest" returnType="void">
<cfargument name="targetPage" type="String" required=true/>
<cflog file="Usedpage" text="#Arguments.targetPage#">
<cfinclude template="#Arguments.targetPage#">
...
</cffunction>
cfinclude won't tell you if a url is supposed to load the file directly. I've seen system where some files are not included via an index.cfm even when the framework expects it. I have it in my own work where index.cfm loads most code but reset.cfm bypasses the framework to reset configs and session data.
Download a trial of Dreamweaver and define a ColdFusion site. DW can create a site map and tell you which files are not included, linked, cfmoduled and so forth. I don't know if it can figure out unused CFCs, but CFMs should be easy. Note that I haven't used DW for years, but it had this functionality around CF 4/5.