Default documents in web.xml not being respected (developer/stand-alone server) - coldfusion

For some reason, when browsing to URL that ends in a folder (ex. //localhost:8500/website/directory/), index.cfm is not loading and instead a 404 error page is returned. I have confirmed that the ...\web-inf\web.xml file is being used by modifying filter-mappings to enable the display of .htm and .txt files. In fact, none of the files in the welcome-file-list section are being used even if they exist which leads me to believe that there is something wrong with this section of the web.xml file.
The web.xml files are as follows:
{install-root}\cfusion\runtime\conf\web.xml
{install-root}\cfusion\wwwroot\web-inf\web.xml
Both files contain the same XML listed below.
<web-app>
...
<welcome-file-list id="WelcomeFileList_1034013110672">
<welcome-file>index.cfm</welcome-file>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.txt</welcome-file>
</welcome-file-list>
...
</web-app>
I have just recently patched to Update 6, but I believe that the problem was always there from the initial install. Please note that this is the development stand-alone server.
Has anyone already solved this or have any ideas on how to proceed other than re-installing CF10 and using IIS?

Late to the party, IMO there are two possible reasons that i can think of for this issue
Either your have additional mapping like "/" in place which is taking over servletcontainer's builtin default servlet who is the one responsible for going to the right root path
your folder name is something which CF already have a mapping for e.g. /flashservices/gateway/, CFFormGateway, cfform-internal, WSRPProducer, JSDebugServlet, flex2gateway
I think sharing your web.xml could have helped pin point the issue here.

I had this issue recently and it was a case-sensitivity issue in Tomcat (despite this being a ColdFusion 10 install on Windows).
My default index.cfm would load when I navigated to http://127.0.0.1 but as soon as I went to http://127.0.0.1/mysite, I got a 404. The folder was named mySite in Windows. As soon as I changed my URL to http://127.0.0.1/mySite it began working.

Related

When navigating to "/elmah.axd" it throws a 'Root Element is missing' error

Posting this to resolve a question I couldn't find an answer to elsewhere.
I'm running "elmah" for error logging in a legacy .NET framework project. It works fine in all of my testing / production environments. However, navigating to it locally produces an XML error:
Root element is missing
within ProcessRequestMain, which seemed to be internal to elmah. Changing configuration didn't help, and I couldn't find a reference to this elsewhere, where it only didn't work locally.
The solution was to navigate to my logPath directory specified in the errorLog section of the web.config. Poking around the generated XML logfiles, I found that for some reason, one or two of them were actually malformed. This meant I couldn't launch the /elmah.axd page at all, without it throwing that error, presumably generated when it tried to parse them to display the page.
Deleting the offending logfiles resolved the issue.

Pentaho DI / Kettle / Spoon Configuration with External Jars

I am deveoloping a custom plugin for Pentaho DI / Kettle 4.4 and use custom Validation and XSLT jars as part of it.
Those jars are referenced in plugin.xml along with the plugin's jar itself and deployed in the same location as the plugin's jar.
When I try to load this plugin in Spoon GUI, I can see and run the plugin fine till I reach the reference to the external jars and after that I get ClassNotFOund Exception.
I have tried following so far but has not worked :
Add the expernal Jars to libext folder and expect those to be picked up automatically. - Failed. Jars not loaded.
Add -cp command line option to Spoon.bat and specify the Jar files - Did not work.
Turned on -verbose option and search everywhere in the output but the Jars are ignored.
Deployed the Jars next to the plugin's Jar file in the plugin's folder. - Jars are not recognized.
From Within the plugin, if I dynamically load (using Reflection and URL Class Loader) I am able to force the loading of the Jars and it works that way but I would like a simpler classpath fix.
Any class that I reference in the Jar through XSL externsion (XALAN-J Java Extension) is still not recognized / loaded and XSL terminates at the beginning of Extension call.
Searched Google and this site for something similar but did not find specific answers on why SPoon behaves so differently and avoids external code and content.
A similar issue is reported here though its too old and has not shown final conclusive fix. I tried all that it said. http://forums.pentaho.com/archive/index.php/t-77190.html
Requesting someone to help me identify whats missing. Thanks in advance,
Thanks to this seemingly obscure website and it fixed all pain.
http://www.arulraj.net/2014/09/how-to-access-external-java-libraries-with-in-pentaho.html
Basically, go to the launcher folder and edit the launcher.properties file to include any path, library etc. and it fixes all the issues I reported above. Wish Kettle documentatation had answers like this.

Why JSTL works when URI defined as /jstl/core_rt but not /jsp/jstl/core in embedded jetty?

I can't seem to get my JSTL library working in my embedded jetty project working.
My taglib line seems to be giving me grief, and it all changes when I use different URIs. Here is the line I would want to use:
<%#taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
I first tried using the normal URI http://java.sun.com/jsp/jstl/core but that throws the error:
org.apache.jasper.JasperException: /bad.jsp(1,61) PWC6188: The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
However when I change the URI to http://java.sun.com/jstl/core_rt. It works!
Another thing I noticed, if I have the old JSTL 1.0 url (http://java.sun.com/jstl/core) I get the following error:
org.apache.jasper.JasperException: /bad-el.jsp(4,0) PWC6236: According to TLD or attribute directive in tag file, attribute value does not accept any expressions
Now another preplexing thing I have noticed, this all works in IntelliJ! Which leads me to believe that there is a classpath problem, but the libraries should be all the same when I embed them inside the war. I think I am missing something.
So, what my question boils down to, what library do I need, or what configuration do I need to have to make this work properly?
Here are the current questions I have tried to follow but did not resolve my issues:
cannot load JSTL taglib within embedded Jetty server
Embedded Jetty fails to load JSP taglibs when classpath specified in jar
Jetty 8 standalone doesn't detect jstl taglib jar
JSTL not parsed in a JSP page running on an embedded Jetty instance
and many others
I have a sample project that one could checkout and try out.
if you want the JSTL uri to work, you should know that jstl is two files.
jstl-1.2.jar
jstl-api-1.2.jar
so look for them in the internet or go to the maven repo and download the jars

Gradle Jetty plugin locking files

Is there a way to fix the file locking issue caused by jetty entirely from gradle?
Some clarification:
When using the Gradle Jetty plugin by running gradle jettyRun, jetty causes the static resource files (html, css, js, etc.) to be locked when using Windows.
You can see a description of the problem in Files locked on Windows.
The same article also describes how you can fix that. Basically you have to either:
Disable the use of file mapped buffer
Not use NIO at all.
Both things require to add some jetty specific configuration files to the project, which I do not want to do - the jetty plugin is used only for convenience, and maintaining configuration for it does not feel right.
I do not need NIO for testing on the local machine, so any solution works.
Edit:
For now, I picked the option at which you set useFileMappedBuffer to false. This is how to do it:
Specify a path to your webdefault.xml like
[jettyRun, jettyRunWar,jettyStop]*.with {
//other configs
webDefaultXml = file("${project.webAppDir}/WEB-INF/jetty-webdefault.xml")
}
Get file from the latest 6.1.x distribution of jetty. The plugin seems to support only jetty 6. You can localte it at jetty-6.1.26\etc\webdefault.xml. Obviously, you have to place it at the path specified at the previous step.
Change the default servlet init parameter useFileMappedBuffer to false
I will research the option of using embeded jetty insted of the plugin.
I found a plugin that seem to be a better alternative:
https://github.com/akhikhl/gretty
Positives
Does not lock your files and support hot deployment (even something Gretty call "fast reload")
Gretty 1.2.0 uses Jetty 9.2.9.v20150224. Jetty plugin provided by Gradle 2.2.1 uses Jetty 6.1.25.
same task is used jettyRun (or more simply run).
"Press any key to stop the server". Jetty plugin required CTRL+C then Y.
From what I can tell, the documentation seem to be awesome (Gradle's not so much)
Negatives
A bit more bloated code to setup the buildscript's classpath dependency or apply plugin directly from URL (see doc)
Gretty crash unless you explicitly apply plugin: 'war' (Jetty plugin extends the War plugin)
Kiril answered his own question, many thanks. You should follow Kiril's instructions and this will help you find the appropriate webdefault.xml.
To find out what version of Jetty is started by Gradle, execute
gradle jettyRun -i
And you'll see something like this:
...
Tmp directory = determined at runtime
Web defaults = org/mortbay/jetty/webapp/webdefault.xml
Web overrides = none
Webapp directory = C:\dev\my-project\src\main\webapp
Starting jetty 6.1.25 ...
jetty-6.1.25
...
It took me a while to find a copy of Jetty 6.1.25 as it is no longer listed on the Jetty download page (not even in the archive section!).
You can then grab the appropriate copy of webdefault.xml from here, adjusting the version number as appropriate for your needs:
http://grepcode.com/file/repo1.maven.org/maven2/org.mortbay.jetty/jetty/6.1.25/org/mortbay/jetty/webapp/webdefault.xml

cfinclude: template not found exception + symbolic link + CF 9.0.1

I had following directory-structure:
/user1/
/user1/bla.cfm
/index.cfm
and created a directory called users:
/users/
/user1/
/user1/bla.cfm
/index.cfm
I set up a symbolic link (under linux with ln -s) from /user1/ to /users/user1/ and tried to <cfinclude> the bla.cfm which worked good. From index.cfm:
<CFINCLUDE template="users/user1/bla.cfm" />
After some testing I removed the symbolic link (/users/user1/) and moved the real directory /user1/ to /users/user1/. Suddenly the bla.cfm did not let me include and threw a template not found exception.
After setting up the symbolic link from /users/user1/ to /user1/ the <cfinclude> worked again. I cannot reproduce this on our development server!? Any hints how to fix this?
Btw all user-directories (user2, user3, etc.) have a bla.cfm inside - and just 2 are having the problem described above. It seems that those users were active and the bla.cfm was included via the symlink. Are those symlinks and their targets cached somewhere?
EDIT:
I tried already clearing the template-cache in CFAdmin.
Further testing:
from index.cfm:
expandpath("/users/user1/bla.cfm") -> correct path
fileexists(expandpath("/users/user1/bla.cfm")) -> saying "YES"
but:
fileexists(expandpath("users/user1/bla.cfm")) -> saying "NO"
Maybe it's some issue with mappings? In the last include you're using absolute path, where in the first one you're using relative path.
Here are some links about mappings:
http://www.coldfusionmuse.com/index.cfm?mode=entry&entry=8E676EBA-A0EF-5BB2-1461BEA3C00CC076
http://forums.adobe.com/thread/442033
Coldfusion mapping error
You don't specify how you setup a 'symbolic link' - do you mean you created a mapping in CF Administrator? If so, check the neo-runtime.xml file in your /cfusion/lib/ folder and see if has been correctly updated.
Restarting coldfusion server instance fixed the problem.