I am using Team Foundation Server (TFS) to check in/out my ColdFusion files (cfm files). We have a .config file in case of .Net projects that contains all system configurations. My question is do we have any such file in ColdFusion. Is it Application.cfm?
Older ColdFusion sites use application.cfm newer ones use application.cfc
Many ColdFusion frameworks use additional xml files for their config.
Last but not least, the ColdFusion administrator stores the information database connections.
I am developing in a similar TFS / Visual Studio environment. Thus far we don't store any the ColdFusion environments files in version control, but I could see that being mandated someday.
These files exist in {cf-root}\lib\neo-*.xml
Related
I just installed ColdFusion 2016 Developer Edition on my Windows 7 laptop and configured it to use the built-in web server. Previously I was using ColdFusion 11.
Now I have a case-sensitivity problem, but only for non-ColdFusion (.cfm) resources. For example, all css and js references are now case-sensitive, whereas they weren't when I was using ColdFusion 11. The same is true for calls to images and plain html files. All cfm files load just fine.
I modified the context.xml file (in the /cfusion/runtime/conf folder) to include <Context AllowLinking="true" caseSensitive="true"> (and yes, I also tried caseSensitive="false") and have restarted several times, but no luck yet.
The 404 error messages specify Apache Tomcat/8.5.11.
Any ideas on how to restore case-insensitivity? Thanks in advance for any help.
I seem to have "fixed" this. I enabled IIS on my laptop and used the Web Server Configuration tool to set it up with ColdFusion. (I also changed the path for the default website in IIS to /cfusion/wwwroot since that's where all my code is.) Everything seems to be working well now, with no case sensitivity for cfm or non-cfm pages. I no longer need to include the port (8500) in the URL for my applications, but do need to include it to reach the CF Administrator.
For a normal JSP web-app that provides web-services, where should the JAX-WS library jar files be placed?
<tomcat-home>/lib
or
<web-app>/WEB-INF/lib
and why?
In general, when are library files considered part of the container infrastructure or part of the web application?
DETAILS
I have implemented various JAX-WS web services following, among others, these guides:
https://jax-ws.java.net/2.2.10/docs
https://jaxenter.com/creating-soap-web-services-using-jax-ws-117689.html
http://www.mkyong.com/webservices/jax-ws/deploy-jax-ws-web-services-on-tomcat/
http://examples.javacodegeeks.com/enterprise-java/jws/jax-ws-web-services-on-tomcat/
http://www.java2blog.com/2013/03/jaxws-webservice-deployement-on-tomcat.html
Whilst the above guides were useful, there are differences in terms of both the required JAX-WS library jar files and where the JAX-WS library jar files should reside.
By trial and error, for JDK 1.8, Tomcat 8.0.30 & JAS-WS 2.2.10, this is the list of JAX-WS library jars that seem to be required:
gmbal-api-only.jar
ha-api.jar
jaxb-core.jar
jaxb-impl.jar
jaxws-api.jar
jaxws-rt.jar
management-api.jar
policy.jar
stax-ex.jar
streambuffer.jar
I am aware that the JDK contains some of the JAX-WS classes but these seem to be meant for standalone Java apps
ie all of the above jar files seem to be needed to avoid a ClassNotFoundException etc.
I have read the Tomcat 8 class-loader how-to
and appreciate that there is a parent-tree, hierarchal class loader and that jar files in:
<web-app>/WEB-INF/lib
are only available to that web app ie are hidden from other web apps
causes the app war file(s) to be bloated as each web app has it’s own copy
and that jar files in:
<tomcat-home>/lib
are available to and shared by all web apps
forces all web apps to use the same version of the library
libraries must be inter web-app shareable ie no statics, thread-safe etc
enables lookup via a JNDI Resource Factory eg JDBC, mail etc
suppresses memory leaks for DriverManager eg JDBC
The web services seem to work when the JAX-WS library jar files are in either location.
Looking at the Metro JAX-WS project,
where the JAX-WS library jars must be downloaded from, for now, I have put these into <tomcat-home>/lib as that is consistent with the ‘install’ option in the ant file.
As a general rule, I try not to pollute the web-container / app-server with unnecessary library jar files where possible as this can lead to conflicts for other web-apps that have to use a specific version of a required library.
Thanks for reading.
Had the same issue trying to deploy a web service to my local tomcat installation. I went the route of adding the jars you listed to get it going, but see the instructions of what's needed from Apache:
https://tomcat.apache.org/tomcat-8.0-doc/extras.html#Web_Services_support_(JSR_109)
...which I think will go a long way to minimizing the amount of jars that end up in your Tomcat's lib folder.
I am trying to setup a internal wiki site for project documentation project. I am using roadkill because I have a IIS server and a .net environment.
So the installation instructions aren't much. Unzip the files onto a site directory. Navigate to http://arwiki
Should be that simple, however, I get an error about directory browsing and it looks like there is no MVC mapping in Global.asax. It points to a internal dll so it is hard to determine what I did wrong?
Has anyone setup Roadkill and know what I did incorrectly?
Also there is no tag for roadkill
You can ask for help on the issues board -
https://bitbucket.org/yetanotherchris/roadkill/issues?status=new&status=open
However I can tell you that the problem is most likely that you don't have MVC installed on IIS (if it's Windows Server 2008). You might also need to enable ISAPI filters, they can be turned off.
The ASP.NET web installer contains the MVC bits you need, although Roadkill does come bundled with these.
No matter what I change in an asmx service in Visual Studio, the WSDL file stays always the same. Deleting methods, changing method signatures don't have any effect when I browse to service definition.
I have had a simular problem.
When removing an enum and replacing it by a string, the enum wouldn't go away from the wsdl. No matter what I tried (clean, rebuild, clear browser cache, other browser), it kept returning the enum as a complex type within the WSDL.
The solution in my case was remove the local folders of the project via windows explorer, then perform a get latest from TFS. After this the problem was solved.
Of course this solution only aplies when using a sourcecontrol system.
After changing your service, you must build it and ensure that the new version is running. One shortcut would be to build it (and make sure there are no errors), then right-click the .ASMX file and choose "View in Browser".
Also, although I'm sure you're aware of it, you should not be using ASMX web services for new development. Microsoft now considers ASMX to be a legacy technology. Use WCF instead.
I have encountered this problem and have a solution.
Cause: When you create a new "Web Service" project in Visual Studio, it automatically adds a "Service1.asmx" file to your project. You rename this file and change the class declaration inside of it, but Studio still thinks it's "Service1" wnd will only ever display the web service definition for "Service1".
Solution:
Delete all "bin" and "obj" folders in your project.
Copy the methods from your existing asmx file to notepad.
Remove the service from your project.
Add a new service to your project, with the name you want.
Paste the code from Notepad into the new service.
Rebuild All
Your asmx should now accurately reflect your web service and update normally on future builds.
I had today the very same issue. It was caused by a GACed version of the assembly that contained the type definitions exposed by the web service. I had to remove the assembly from the Global Assembly Cache first, like:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe" /u YourAssemblyNameWithouthDllExtebsion /f
Be sure to restart the web server hosting the web service to reload the new version of the assembly, for example, in case of IIS Express, you can kill the former process instance by PowerShell:
(Get-Process -Name iisexpress).Kill()
After that, the updated WSDL version was displayed as expected.
I have written a WCF web service in C#. I had originally self-hosted it and then decided to host it on IIS running locally on my PC. While the service is working, there are several aspects of the deployment process that I don't understand:
Firstly, the URL of this service when hosted in IIS does not correspond to what I specified in my web.config. I had specified "http://localhost:8000/MyServices/OrderService" there and this was used when I self-hosted. Now that I've deployed to IIS, the URL has become "http://localhost/MyServices/OrderService". Why is the URL not picked up from my config file?
Secondly, to host the Web Service, I created a new web site within IIS (in addition to the existing 'Default Web Site'). I set the physical path to c:\inetpub\wwwroot (no idea if this is correct) and left the other parameters as default. I then copied my /bin folder, my .svc file and my web.config to this folder. Is this the equivalent of a 'Virtual Directory'?
Finally, the service didn't work until (within IIS) I selected 'Convert to application'. Why is it necessary to select 'Convert to application'?
Can anyone explain what the correct procedure is to publish a simple web service from Visual Studio into IIS, or point me at some good documentation so I can understand the process?
****EDIT TO ORIGINAL*****
Having spent more time looking into this, I have found the following:
When I create a web site in IIS, I give it a physical directory of c:\inetpub\wwwroot....etc
If I then "publish" from within Visual studio, all it's doing is copying all the required filed (like the /bin directory, web.config and .svc file) into the physical directory of the website i.e. - c:\inetpub\wwwroot...
You can perform the copy manually to the same affect.
Lastly, with regard to the URL of my service not corresponding to the baseAddress section of my web.config file, this has been answered on stackoverflow previously.
The answer is that the baseAddress is completely ignored when hosting on IIS.
If using Visual Studio 2010 you can right-click on the project for the service, and select properties. Then select the Web tab. Under the Servers section you can configure the URL. There is also a button to create the virtual directory.