We are migrating a sharepoint farm from a traditional DC to a private cloud.
One of the forms in a site is calling some web services, both the sharepoint site and Web Service application are housed by the same IIS server. Sharepoint site and the Web Services application are having different application pool.
After migrating, one of the forms that is calling some Web Services is throwing an error about: data connection error. Looking at the sharepoint logs, we found that there is http error 500 when hitting the form's URL and that we realized that hitting the WSDL from the browser is throwing the same error too.
The error in WSDL is about: Could not load file or assembly <...> or one of its dependencies. This error is gone if we set the application pool settings to Enable 32 bit = true.
However, the rendering of form is not completed because setting the WSDL application pool to 32 bit is causing to throw a FileNotFoundException with stack trace:
at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite, SPUserToken userToken)
at Microsoft.SharePoint.SPSite..ctor(String requestUrl) at ...
We are sure that the cause of the problem here is the binary "bitness" because we are able to simulate the above exception and able to resolve in the other forms by just setting back the 32bit option to false in application pool.
We would like to seek anyone's idea on how to resolve the issue. Unfortunately, we only have the DLL of the Web Service, it will take for us a while to get some source codes so we are hoping for some solution that requires no re-compilation. Also, the source code that we are to receive is not guaranteed to produce the same DLL that is deployed to production due to the age of this legacy system turned blackbox.
For more information on the versions of softwares used:
IIS, source: IIS 6; destination: IIS 7.5
Sharepoint: 2007 (yes unfortunately due to alot of reasons upgrade cannot be done just yet) - source and destination are of the same version
OS: Windows Server 2008 R2 - source and destination are of the same version
Related
I used the CN1 Webservice Wizard to add a the webservice proxy to my mobile app and to generate all the server side code. I have a local XAMPP installation with a tomcat linked within my Eclipse IDE. Also, I imported the server generated code as a new Java Project and added the "Dynamic Web Module" project facet to it so that I could launch it not as a local Java application but rather on the Tomcat server.
When starting my client, I noted that I get HTTP 404, resource not found errors. I traced the error back to the URL, where the server is hosted to.
I know I have to adapt the urlPatterns parameter in the generated class CN1WebServiceServlet, which I did. Also, I checked the context of my app in the Web project settings and defined the value for context root. So, in my client app, the URL to call the service should be
http://localhost:8080/< context root>/< urlPattern>
However, even when calling that in the browser, I should get the result of the doGet method of the server generated code, showing the message "Webservice access only". Instead, I get 404 errors all the time.
Is there some problem to importing the server generated code as a plain Java project and adding the web parts to it afterwards? How would that be done in the ideal case?
And what other problems might be hindering the URL from properly being published on the server side?
Thanks and best regards
EDIT
I stripped everything from the project to limit the options and I found the cause: when using the web service wizard to dump the source files into a new directory, adding that with the Eclipse import wizard, it will be looked at as a plain java project without any web components. Using the project settings to add the dynamic web piece to it (Eclipse calls those project facets), the CN1 webservice will NOT work.
If instead you create a "Dynamic Web Project" first and then use the CN1 Webservice Wizard to dump the server source files into the "src" folder of that project, it works without any issues.
i am approaching the development of Restful web services for the first time. I tried to follow this guide for Netbeans . I am stuck at the testing of the web service.
When i open the
http://localhost:8080/WebServicesTest/test-resbeans.html
page, none of the root resources appears in the left menu. (there should be entities.customer and entities.discountcode)
I really can't find a solution.
Thanks in advance to anyone who likes to give me a hint.
--------------- Edit
If i click on CustomerDB --> Deploy i get an error
In-place deployment at C:\Users\utente\Documents\NetBeansProjects\CustomerDB\build\web
GlassFish Server 4, deploy, null, false
C:\Users\utente\Documents\NetBeansProjects\CustomerDB\nbproject\build-impl.xml:1071:
The module has not been deployed.
See the server log for details.
The line 1071 of build-impl.xml is
<nbdeploy clientUrlPart="${client.urlPart}" debugmode="false" forceRedeploy="${forceRedeploy}"/>
I checked out the referenced tutorial.
Which exact path did you follow? Did you change anything?
Most likely your CustomerDB application is not deployed correctly (see GlassFish Server output in NetBeans) and thus is not able to expose the web service and thus is not displayed in the test page (nothing visible in the side bar).
I tried the tutorial myself and had that phenomenon when using another database ("test" instead of the sample db, which was not connectable in my installed environment), resulting in a message that "test__pm" resource was not found. I then created a conection pool and a jdbc reosurce for test and then it worked.
After a Windows 7 fresh restart, I open the Visual Studio 2010 as administrator, create a new project of Windows Azure Project with ASP.NET Web Role, then at the WebRole1 project I add a WebService1.asmx and press F5 (run).
The Windows Azure services starts OK and the browser open the http:/127.0.0.1:8080/WebService1.asmx perfectly. But when I click at Invoke button to test the webservice method I always receive a Bad Request - Invalid Hostname, with a http:/127.0.0.1:8081/WebService1.asmx/HelloWorld.
The most likely cause is ASMX's WSDL file doesn't stand by load balanced environment such as Windows Azure. The test feature relies on WSDL. You will see similar issues if you add a web/service reference. It is recommended to upgrade to WCF. In WCF, you can use useRequestHeadersForMetadataAddress (http://msdn.microsoft.com/en-us/library/ee816894.aspx) to fix the issue. If you need to use ASMX, please try to manually provide a correct WSDL file.
OK, the documentation says:
If you configure the folder containing FW/1 as a new web root and
browse to it, you'll see an introductory application.
So I created a new site in Windows Vista and pointed it to the Framework 1 bundle.
I've installed CF10, and am able to navigate to http://localhost:8500/CFIDE/administrator/
so I know that's working.
But when I navigate to http://localhost/, it gives me:
Error Summary
HTTP Error 500.0 - Internal Server Error
The page cannot be displayed because an internal server error has occurred.
Requested URL http://localhost:80/
Physical Path C:\inetpub\seancorfield-fw1-9e69741
And trying localhost:8500 goes to C:\ColdFusion10\cfusion\wwwroot
I wrote up a pretty detailed blog post here:
http://blog.bittersweetryan.com/2012/02/changing-webroot-of-coldfusion-zeus.html
It looks like you may not have updated your mapping to the WEB-INF and CFIDE folders.
If you installed it as the built in server then it will be 8500.
If you integrated into IIS then it will be port 80
You may just need to run the web connector tool, you will find it in the start menu.
If that doesnt work, you likely don't have the necessary bits of IIS installed.
I have the below mentioned problem:
Delphi native Web Service applications not working. IIS 7 seems to be stripping the pathinfo
I did everything outlined in answer 2 (see below or that URL) Didn't help - now I can't run the DLL at all - Firefox wants to download the file, request isn't passed off to ISAPI. I can only launch the WS ISAPI process by permissioning explicitly my webService DLL in the handler mappings for the VD - then the default WS page shows but SOAP and WSDL are never emitted, as explained in above mentioned post.
Delphi native Web Service applications not working. IIS 7 seems to be stripping the pathinfo
"... I can never get to the SOAP. In the same way, the WSDL Importer cannot get to the SOAP either...The problem was that I had created a specific script mapping in the Handling Mappings for the ISAPI dll. This caused IIS to redirect all requests to the specific dll, which was why any request that included an info path part was ignored. The info path was stripped off.
The problem was that I had created a specific script mapping in the Handling Mappings for the ISAPI dll. This caused IIS to redirect all requests to the specific dll, which was why any request that included an info path part was ignored. The info path was stripped off.
What I really needed to do is to simply enable the Execute feature permission of the ISAPI-dll module mapping handler mapping. This module mapping is available for a virtual directory once you have allowed unspecified ISAPI modules (or CGI modules, if that is the kind of Web server extension you have created).
To fix my problem, I needed to
Delete the directory whose handling mappings I has messed up.
Since I already had allowed unspecified ISAPI modules (select Edit Feature Settings from the ISAPI and CGI Restrictions applet from the IIS section of the server), I then needed to add a new virtual directory for the appropriate Web site (here is where I recreated the directory that I deleted in previous step 1.
From the Handling Mappings applet for the virtual directory, you probably have the ISAPI-dll handling mapping disabled. Select it and select the Edit Feature Permissions option on the right-hand side. Enable the Execute checkbox."
I went through .\Windows\System32\inetsrv\config\applicationHost.config and deleted the entries for all of my VDs and DLL's, then uninstalled and reinstalled IIS and made sure to install support for ISAPI extensions and whatever other features it needs.
Then, in the webServer root I set the CGI-ISAPI handlers to allow all unknown ISAPI.dlls, created a new VD and inherited the handlers from parent without permissioning any of my WS module explicitely - now ISAPI process runs and emits WSDL/SOAP.
The problem with this is that you must allow all unknown ISAPI dll's - not particularly secure if you're deploying on a vulnerable public webServer.
MNG