Security update... Explain this madness...

Hello

I just updated one of our CF 8.0.1 facilities with the most recent security patch and it broke CFIDE instantly. When you look at the stack trace there is ongoing suspicious things. Please take a look at in bold print in the trace below...

1. why he tries to run CFIDE to c:/work? My installation is not yet on the C: drive

2. why the devil is 'ColdFusioon' referenced. Its obviously a type o. Not to mention that the patch for CFIDE is once more quite wrong?

I thought I'd come on the forums and see people everywhere in this topic.

Being that I did not find related positions be it im just wondering if this a personal problem and perhaps im overlooking something. the update is if trivial im see how I could have forgotten anything.

Anyone out there care to chime?

Stack trace

java.lang.NoSuchMethodError: coldfusion.tagext.GenericTag.doFinally (V) cfl10n2ecfm1746172653.runPage(C:\work\ColdFusion\cf8_u1_final_hotfix\cfusion\wwwroot\CFIDE\administrator\cftags\l10n.cf m: 153) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:192) at coldfusion.filter.CFVariablesScopeFilter.invoke(CFVariablesScopeFilter.java:63) at coldfusion.tagext.lang.ModuleTag.doStartTag(ModuleTag.java:280) at cfApplication2ecfm1983805352._factor3 (C:\p4\ColdFusioon\cf8_final_hotfix\cfusion\wwwroot\CFIDE\administrator\Application.cfm:101) at cfApplication2ecfm1983805352._factor7 (C:\p4\ColdFusioon\cf8_final_hotfix\cfusion\wwwroot\CFIDE\administrator\Application.cfm:4) at cfApplication2ecfm1983805352.runPage (C:\p4\ColdFusioon \cf8_) final_hotfix\cfusion\wwwroot\CFIDE\administrator\Application.cfm:1) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:192) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:366) at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65) at coldfusionfilter. CfincludeFilter.include(CfincludeFilter )

Call me Charlie, please.

I wonder if there may still be some potential confusion however.

Are first of all, to be clear, since you say that you run 8.0.1, you sure that you have downloaded the zip 8.01 (of http://kb2.adobe.com/cps/857/cpsid_85766.html)? It has zips for 9.0, 9.01, 8.0 and 8.01, it seems important to be sure to use the right one.

Second, equally important, are you positive that you run 8.0.1? I saw a lot of people discover that they are not running the version that they think they are. The good news is that it is reported in the CF Admin, and since you say you can get things to work, go ahead and launch the Admin CF (which was not and now works) to ensure that adjustment or Information System summary pages really don't show in market 8.0.1. In this case, please do not trust of assumptions you may have.

Thirdly, this administration now, working on that going through IIS? In other words, is there a port on the URL, for example the 8500 or 8300? If Yes, while you are using the built-in web server and IIS, and therefore you would NOT usually use the CFIDE, which is in the inetpub\wwwroot but rather in the wwwroot where CF is installed (for example c:\coldfusion8\wwwroot for CF8 Standard or Enterprise Server or C:\JRun4\servers\cfusion\cfusion-ear\cfusion-war\CFIDE mode for the cfusion in CF8 Enterprise multiserver instance). In this case, you may have applied the patch to the wrong place, which could explain a problem.

But then the fact that you say restore you the old files and all of a sudden it works makes look that's not the issue.

Yet, as we continue explored the possibilities, you say 'this has happened both of our cf development servers 8 One is multiserver while the other is CF8 Standard... The instance to try to apply it to the GI would indeed "cfusion" in both cases. »

To be clear, there is no instance of cfusion in the Standard (or Enterprise Server) deployment, in multi-server deployment. A server running CF 8 Standard (or Enterprise Server mode) would rather a directory c:\coldfusion8 (on Windows, you're running) with no cfusion directory it contains (it has a \servers\coldfusion, technically). Given that this correction will in the CFIDE, is not quite as big a deal.

But the biggest problem is that we could update the CFIDE in inetpub\wwwroot but saw their URL of Admin SEE loading from (and the code search in) inside CF instance instead. This is the confusion that happens all the time, as a result of the flexibility of the CF (whether or not to use the built-in web server) and the fact that most of the people don't just simply spend their days to dive into this level of detail.

I note also that since you said that you use this site by your CFIDE inetpub\wwwroot, (there's nothing of technically wrong with it, too long as you really use IIS to open your CF Admin), this means also you could point on the technical side of a website (all or part, or a virtual directory in IIS) to use the CFIDE directory While can say this web site in order to pass any CFM file that it finds in any particular CF search engine you have installed.

Again, I'm grabbing at straws for you, but I could see how you could technically get an error if you tried to run the code in this fix to one version against another person (because they offer different versions). Looking at the CF Admin (assuming that you are running the CF Admin) to confirm the version (and the location of the CFIDE mapping indicated that she) should help.

Tell us what you find.

/Charlie

Providing CF troubleshooting services at carehart.org/consulting

[email protected]

Tags: ColdFusion

Similar Questions

Maybe you are looking for