well, as long as CFM pages are loading, IIS should be handing things off and returning them properly. This should not interfere with CF and the Flex services, never did for IIS 6, the last time I got near that mess :) Errors about the Flex services not starting should be in the CFAdmin logs section if there is a issue, I'd expect, though could be in the JEE logs instead.
CF9 changed the config in this area a bit too http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WS5B9C73A8-5FA2-4a54-B0C6-CECA2E20052D.html Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Tue, Jun 28, 2011 at 9:43 AM, Laurence MacNeill <[email protected]>wrote: > So, the built-in Flex services are not starting up or are misconfigured, > then... Gotta be that, because I've *never* hard-coded anything in my > services-config and remoting-config files... Ever... (Just for kicks, I'm > checking them again -- but I gurarantee you there's no hard-coded links in > there). It's all {server.name} and {server.port}, etc, etc... > > My major question, now, is this -- how do I get the built-in Flex services > to start up? If those services aren't starting, why is there no error > message in any of the logs? Might it be an IIS 7 permissions issue of some > sort? If so, to whom do I give permissions, and to what? > > Thanks, > L. > > On Tue, Jun 28, 2011 at 9:37 AM, Douglas Knudsen <[email protected] > > wrote: > >> if http://localhost/flex2gateway fails to load a blank page, then the >> built in Flex services have not started up or are misconfigured. Be sure >> your xml config files you copied have no hardcoded IPs or such. In fact, >> there is no need to have domains or IPs in there, they make use of JEE >> properties. I would put the original services-config and remoting-config >> back in, restart, and test. If http://localhost/flex2gateway then loads >> a blank page, start from there. >> >> I'll also note, the crossdomain file will have naught to do with all this >> unless you are hosting a Flash app on ANOTHER server and pointing it to your >> CF server. Test this all out after localhost is working, go with the power >> of Ockham :) >> >> Douglas Knudsen >> http://www.cubicleman.com >> this is my signature, like it? >> >> >> >> On Tue, Jun 28, 2011 at 9:24 AM, Eric DeCoff <[email protected]>wrote: >> >>> When all else fails.. >>> >>> Go to the fiddler >>> >>> http://www.fiddler2.com/fiddler2/ >>> On Jun 28, 2011 9:06 AM, "Laurence MacNeill" <[email protected]> >>> wrote: >>> > It appears to be working -- we can serve regular https:// pages with >>> no >>> > problems... >>> > >>> > Any ideas why I'm still getting a "500" error when I browse to >>> > http://localhost/flex2gateway ? I've tried every suggestion I could >>> find on >>> > Google when I searched... Nothing has made a diffference... (Well, I >>> can't >>> > try re-installing CF9, like some of the suggestions say to do, because >>> I >>> > don't have physical access to the machine... But one would think these >>> > web-hosting guys would have a drive-image they'd use to create new >>> > web-servers, rather than having to go thru all the installation >>> rigamarole >>> > every time they make a new server... So installation shouldn't be an >>> issue, >>> > one would think...) >>> > >>> > Anyway... I'm still open to any suggestions... Thanks, >>> > >>> > L. >>> > >>> > On Tue, Jun 28, 2011 at 8:13 AM, Eric DeCoff <[email protected]> >>> wrote: >>> > >>> >> Laurence, >>> >> >>> >> Have you checked to see >>> >> If your service on port 443 working >>> >> On Jun 28, 2011 1:47 AM, "Laurence MacNeill" <[email protected]> >>> >> wrote: >>> >> > Progress? Maybe? >>> >> > >>> >> > I browse to http://localhost/flex2gateway on the new server, and I >>> get >>> >> the >>> >> > following: >>> >> > >>> >> > 500 >>> >> > >>> >> > java.lang.NullPointerException >>> >> > at >>> >> >>> jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:285) >>> >> > at >>> >> >>> jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543) >>> >> > at >>> >> >>> jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203) >>> >> > at >>> >> >>> jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:320) >>> >> > at >>> >> >>> jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428) >>> >> > at >>> >> >>> jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:266) >>> >> > at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66) >>> >> > >>> >> > >>> >> > That certainly seems to me like the problem, eh? If the flex2gateway >>> >> itself >>> >> > isn't working, then no matter what I do with the services-config.xml >>> >> file, >>> >> > it's not gonna work. >>> >> > >>> >> > So -- the question now is, How do I fix the flex2gateway? >>> >> > >>> >> > L. >>> >> > >>> >> > >>> >> > >>> >> > On Tue, Jun 28, 2011 at 12:31 AM, Laurence MacNeill >>> >> > <[email protected]>wrote: >>> >> > >>> >> >> Ok -- found the log files on Win 2008 / IIS 7... >>> >> >> >>> >> >> Here's the offending line: >>> >> >> 2011-06-28 04:20:58 ##.##.##.## POST /flex2gateway/cfamfsecure - >>> 443 - >>> >> >> ##.##.##.## >>> >> >> >>> Mozilla/5.0+(compatible;+MSIE+9.0;+Windows+NT+6.1;+WOW64;+Trident/5.0) >>> >> 500 0 >>> >> >> 0 405 >>> >> >> >>> >> >> (I've replaced the IP addresses with the '#'s in that line). >>> >> >> >>> >> >> So -- the 500 error is at the end of the line there, but what does >>> the >>> >> "0 0 >>> >> >> 405" mean after the 500? Can that help me diagnose this problem >>> somehow? >>> >> >> And why is there a problem anyway? Shouldn't it be doing exactly >>> that? >>> >> >> Posting data to the /flex2gateway/cfamfsecure channel? I'm really >>> not >>> >> sure >>> >> >> what's up with that... >>> >> >> >>> >> >> L. >>> >> >> >>> >> >> >>> >> >> On Tue, Jun 28, 2011 at 12:16 AM, Laurence MacNeill < >>> >> >> [email protected]> wrote: >>> >> >> >>> >> >>> If I enable 32-bit apps, it breaks everything... Ran into this >>> problem >>> >> >>> before trying to run 32-bit ColdFusion 8 on a 64-bit IIS. That's >>> why we >>> >> >>> actually upgraded our old server to 64-bit ColdFusion 9 many >>> months >>> >> ago... >>> >> >>> As far as errors in the logs are concerned -- any idea where those >>> >> might >>> >> >>> be on Windows 2008 with IIS 7 and CF 9? I've never used Win 2008 >>> or IIS >>> >> 7 >>> >> >>> 'till today... No clue where the logs are... >>> >> >>> >>> >> >>> https certificates: We're using the same cert from the old >>> server... >>> >> Cert >>> >> >>> is working fine -- no browser certificate errors at all. >>> >> >>> >>> >> >>> I will try again to clear out my browser cache(s)... Did it once >>> >> earlier >>> >> >>> when the problem first surfaced, but maybe it needs to be done >>> again... >>> >> >>> >>> >> >>> Thanks, >>> >> >>> L. >>> >> >>> On Tue, Jun 28, 2011 at 12:06 AM, Marty Blood < >>> [email protected] >>> >> >wrote: >>> >> >>> >>> >> >>>> A quick Google search turns up this link: >>> >> >>>> >>> >> >>> http://ppshein.wordpress.com/2010/08/12/internal-500-error-cf9-on-window-2008/ >>> >> >>>> >>> >> >>>> So it might be that you just need to enable 32-bit apps to run in >>> IIS >>> >> and >>> >> >>>> restart it. >>> >> >>>> >>> >> >>>> Barring that, a 500 status usually means it's the app server >>> that's >>> >> >>>> throwing an error. Did you see any errors in the CF9 logs or the >>> IIS >>> >> logs? >>> >> >>>> Also, with https did you generate new certificates or are you >>> using >>> >> the >>> >> >>>> same ones from the old server? Can you verify they were installed >>> >> properly >>> >> >>>> in IIS and CF9? (I personally don't know how but you should be >>> able to >>> >> get >>> >> >>>> your network admins to double check that or just make sure when >>> you >>> >> connect >>> >> >>>> to a basic web resource served up by IIS you don't see any >>> certificate >>> >> >>>> errors). >>> >> >>>> >>> >> >>>> I'm guessing you've run through this but it can't hurt to ask if >>> >> you've >>> >> >>>> cleared out your cache (browser, temp files, flash cookies if >>> you're >>> >> using >>> >> >>>> any Flex) in case something on the client side is caching >>> references >>> >> to >>> >> >>>> keys, certs, hashes, who-knows-what that were generated by the >>> old >>> >> server? >>> >> >>>> >>> >> >>>> Best of luck! >>> >> >>>> >>> >> >>>> -Marty >>> >> >>>> >>> >> >>>> On Mon, Jun 27, 2011 at 11:28 PM, Laurence MacNeill < >>> >> >>>> [email protected]> wrote: >>> >> >>>> >>> >> >>>>> I'm at my wit's end here... >>> >> >>>>> >>> >> >>>>> We migrated everything over to a new server today... Win 2008, >>> IIS 7, >>> >> >>>>> CF9... We were running Win 2003, IIS 6 on the old server (but >>> still >>> >> had CF9 >>> >> >>>>> on the old one, so nothing should've changed there). >>> >> >>>>> >>> >> >>>>> I copied the services-config.xml and the remoting-config.xml >>> files >>> >> from >>> >> >>>>> the old server to the new one, since both the old one and the >>> new one >>> >> have >>> >> >>>>> CF9 on them, and both are configured exactly the same way. >>> >> >>>>> >>> >> >>>>> I copied our crossdomain.xml file as well. Shouldn't be any >>> changes >>> >> >>>>> there, since the new server has the exact same domain-name as >>> the old >>> >> server >>> >> >>>>> (because our domain-name now points to the new server). >>> >> >>>>> >>> >> >>>>> So someone please tell me why I'm getting the following error: >>> >> >>>>> "Channel.Connect.Failed error NetConnection.Call.Failed: HTTP: >>> Status >>> >> >>>>> 500: url: 'https://www.mydomain.net/flex2gateway/cfamfsecure"; >>> >> >>>>> >>> >> >>>>> I've checked everything I know to check... It's always been some >>> kind >>> >> >>>>> of mis-configuration in the services-config or remote-config >>> files >>> >> >>>>> before... But not this time, apparently. I'm totally stumped. >>> Could >>> >> it >>> >> >>>>> somehow be Win 2008 or IIS 7 that are causing the problem? >>> Because >>> >> those >>> >> >>>>> are the only things that are different between the new server >>> and the >>> >> old >>> >> >>>>> one... >>> >> >>>>> >>> >> >>>>> Please help ASAP. >>> >> >>>>> >>> >> >>>>> Thanks. >>> >> >>>>> L. >>> >> >>>>> >>> >> >>>>> >>> >> >>>> >>> >> >>>> >>> >> >>> >>> >> >> >>> >> >>> >> >> >
