Copy link to clipboard
Copied
We started testing the migration of one of our main websites from CF9 to CF10 and everything seemed to be going well. When we started testing our web services though things got a little weird. All of our web services were throwing error messages. Both installations co-exist on the same Windows 2008 R2 server running inside of the same instance of IIS.
wsVersion = 1
AXIS error
Sorry, something seems to have gone wrong... here are the details:
Fault - Error attempting to create Java skeleton for CFC web service.; nested exception is: coldfusion.xml.rpc.CFCInvocationException: [java.lang.NullPointerException : null]
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
faultSubcode:
faultString: Error attempting to create Java skeleton for CFC web service.; nested exception is: coldfusion.xml.rpc.CFCInvocationException: [java.lang.NullPointerException : null]
faultActor:
faultNode:
faultDetail: {http://xml.apache.org/axis/}hostname:Dev
wsVersion = 2
HTTP Status 500 - The web service operation caused an invocation exception.
type Status report
message The web service operation caused an invocation exception.
description The server encountered an internal error (The web service operation caused an invocation exception.) that prevented it from fulfilling this request.
Apache Tomcat/7.0.23
Long story short of the hours I spent debugging I discovered that if the web service files were located within an IIS virtual folder this happens. If I move them to the root of the website or a folder inside of the website they begin to work again. This behavior is inconsistent with CF8 & CF9 as our websites in development and production under those are running their web services from an IIS virtual folder.
Anyone have an explanation, fix, or work around relating to this?
Copy link to clipboard
Copied
I've filed a bug relating to this as I've now reproduced this on 3 systems.
Copy link to clipboard
Copied
Leith, while you say in the bug report that these 3 servers are “fully patched”, it’s important to confirm something that many overlook: can you confirm that you have rerun the CF web server configuration tool, to remove and re-add your IIS sites (whether “all sites” or some individual ones)? If you don’t, that can be the root cause for all kinds of problems.
To confirm it, look at the C:\ColdFusion10\config\wsconfig\1\ isapi_redirect.dll file to confirm that it’s dated Nov 8 2012. If it’s earlier, then you have not rerun the tool as needed. Note also that if you have created more than one connector, then you will have more than just a \1\ folder in that wsconfig folder, and you need to check each of those.
Let us know whether this is helpful or not.
/charlie
Copy link to clipboard
Copied
I have 2 connectors and both show as 11/8/2012 1:18 PM as their modified date. I did not rebuild the connectors after CF10 P8 because it said if you had done it back during patch 6 there was no reason to do it again. However connector #2 was built after P8 anyways and it's the same date as connector #1.
Copy link to clipboard
Copied
That’s fine (that you did not do it “again”). I did not mean to imply you should. I just meant you should make sure it was done at all, which you have. So that at least confirms that the problem is not related to that. And I do know that someone else replied on the thread saying they are getting the same problem. I just want to make sure all possible user errors/mistakes/misunderstandings are ruled out before concluding that there is indeed a clear bug in CF.
That said, I will note one other possibility worth considering: perhaps the problem is in the configuration of IIS (done by the connector). Here’s another area where some have problems: when you ran the CF web server config tool, did you use the “run as administrator” option (by right-clicking the shortcut to the tool as you ran it from the start menu or desktop, or starting the command prompt as admin if you ran the tool from there)? It can be necessary, especially on Windows 2008/2012, Vista/Windows 7.
Now, some people don’t do that, either because they don’t even know it’s an option, or others assume they don’t need to because they are “already an administrator”. I’ll just say that I’ve seen times when folks have NOT done it, and therefore their IIS configuration was NOT correct. There is documentation from Adobe (in the docs and in blog entries) about what the correct configuration should be (with respect to the CFIDE and Jakarta virtual directories created, the ISAPI filters created, the handler mappings if any, etc.)
One other thing: is this a machine on which you had previously had CF9 installed and configured with IIS? It could be that some vestiges of CF9 settings remain (in IIS, whether at the folder, site, or server level), which can impact things if not removed (and they may not be removed because of the problem of the web server config tool not having been “run as administrator”).
Just some thoughts. If you remain stuck, and don’t want to wait for Adobe to confirm/resolve your bug report, and think that having another pair of eyes could help, I offer a list of folks who can provide CF server troubleshooting services (myself included), at www.cf411.com/cfconsult.
One last thing: you may want to put together some code that demonstrates the issue (a page offering a web service, a page calling it, and clarifications on what people should do and see and what you’re seeing), and others may try it. (I do know, of course, what’s needed to do that myself. I just am not free right now to give it a try. And yes, perhaps if I’d tried it rather than taking the time to write the above I might have experienced it. Didn’t think of it until too late.)
HTH
/charlie
Copy link to clipboard
Copied
Charlie Arehart wrote:
That’s fine (that you did not do it “again”). I did not mean to imply you should. I just meant you should make sure it was done at all, which you have. So that at least confirms that the problem is not related to that. And I do know that someone else replied on the thread saying they are getting the same problem. I just want to make sure all possible user errors/mistakes/misunderstandings are ruled out before concluding that there is indeed a clear bug in CF.
That said, I will note one other possibility worth considering: perhaps the problem is in the configuration of IIS (done by the connector). Here’s another area where some have problems: when you ran the CF web server config tool, did you use the “run as administrator” option (by right-clicking the shortcut to the tool as you ran it from the start menu or desktop, or starting the command prompt as admin if you ran the tool from there)? It can be necessary, especially on Windows 2008/2012, Vista/Windows 7.
The "run as administrator" option was used in all cases. I've actually changed the compatability mode of the exe to require the admin uplevel request be triggered every time it us run.
Now, some people don’t do that, either because they don’t even know it’s an option, or others assume they don’t need to because they are “already an administrator”. I’ll just say that I’ve seen times when folks have NOT done it, and therefore their IIS configuration was NOT correct. There is documentation from Adobe (in the docs and in blog entries) about what the correct configuration should be (with respect to the CFIDE and Jakarta virtual directories created, the ISAPI filters created, the handler mappings if any, etc.)
I verified against the documentation the existance and configruation of all the items you mentioned (CFIDE, Jakarta, ISAPI, handler mappings). Everything else in a good number of complex websites function as expected, this is the only item having an issue.
One other thing: is this a machine on which you had previously had CF9 installed and configured with IIS? It could be that some vestiges of CF9 settings remain (in IIS, whether at the folder, site, or server level), which can impact things if not removed (and they may not be removed because of the problem of the web server config tool not having been “run as administrator”).
Two of the machines have CF9 co-existing with CF10 so to eliminate that as the issue I installed a fresh Win2008R2 VM and did a default installation of CF10 into it. Applied the mandatory update and then applied update 8. I then attempted to run a web service wsdl from a normal folder and that worked so I then created an IIS virtual folder and that fails. After that I ran the connector tool an upgraded the IIS connector, rebooted, and the issue still continues.
Just some thoughts. If you remain stuck, and don’t want to wait for Adobe to confirm/resolve your bug report, and think that having another pair of eyes could help, I offer a list of folks who can provide CF server troubleshooting services (myself included), at www.cf411.com/cfconsult.
I really believe this is a bug in CF itself and not my configuration after going through all the normal steps and then the ones you mentioned above as well as a default installation of CF10 having the same issues. Now it may not be directly related to CF but in the connector process or IIS configuration but a fix/workaround/KB needs to be created relating to it.
One last thing: you may want to put together some code that demonstrates the issue (a page offering a web service, a page calling it, and clarifications on what people should do and see and what you’re seeing), and others may try it. (I do know, of course, what’s needed to do that myself. I just am not free right now to give it a try. And yes, perhaps if I’d tried it rather than taking the time to write the above I might have experienced it. Didn’t think of it until too late.)
HTH
/charlie
I can not expose one of our websites for testing as they are all internal but it is easy enough to replicate.
Copy link to clipboard
Copied
Leith, fair enough on all your responses to my suggestions.
As for your last point though, I wasn’t proposing that you expose your site. I was proposing that you offer some code that folks could easily test. I do appreciate that you have instead given the clear steps to take, and that’s fine. I’m just asserting that for some people, if you leave them to create the code for a test, they won’t bother. Even if it’s only several lines. Your call. It was just a suggestion. If I have time today, I will try to do a test to see if I can confirm the problem. Can’t commit to it, though.
/charlie
Copy link to clipboard
Copied
This is a very basic webservice that can be saved as a .cfc and then called as filename.cfc?wsdl to visually output the information to the screen. Using the steps from my previous post you can use this file to test the virtual folders.
<cfcomponent wsversion="2" style="Document" >
<cffunction name="echoString" access="remote" returnType="string">
<cfargument name="argString" type="string">
<cfreturn argString>
</cffunction>
</cfcomponent>
Copy link to clipboard
Copied
I am also getting this exact same problem. Does not work from a virtual directory, but will work fine from the root.
Copy link to clipboard
Copied
I also have the same problem, I got workaround the problem by setting a ColdFusion mapping as same as IIS virtual Directory (and Restart ColdFusion service).
Copy link to clipboard
Copied
I'll give that a try and see if it works for our system too.
Copy link to clipboard
Copied
I can confirm this workaround does work.
However... The problem with this workaround is that it only works once. If you use the same virtual folder name for other websites that point to different physical folders this will still continue to be an issue. The only way this would work for multiple websites is if they all pointed to a central location however you're then destroying the point of making it more secure outside the web root by placing code for other websites into one location.
Copy link to clipboard
Copied
For those who have replicated the issue can you please go to my bug I've posted regarding this and Vote it up? Without votes the bug will go unnoticed by Adobe staff. The vote option is in the bottom right hand of the bug page.
Copy link to clipboard
Copied
Adobe has verified the bug and marked it as ToFix so we should hopefully see a fix coming.