Why is Lucee redirecting to the wrong location?

What could cause a link to redirect to an unexpected directory instead of the one intended?

I’m getting a file not found error from a link that points to a CFM file in a particular directory. Oddly, when I turn error reportingfrom PUBLIC to NEO, the link points to a totally different folder.

This is on a server with multiple virtual hosts. Been at it for two days now and I just can’t find the problem.

Could it have to do with the ports?

Lucee root is:

The root for the file in questions is:

The intended target file is in:

The error says the file is not in:

There is no reference to oldheritage anywhere in this chain of links or configuration files.

I could really use a few suggestions here.

Is it possible to get Paid support for this issue then?

Did you already check if wrong redirection is caused by the webserver, like urlrewrite?

each web context should have it’s own unique directory, it seems nesting them all under /opt/lucee/tomcat/webapps/ROOT? that might be why things are getting confused

Hi Andreas,
Thank you for the reply.
There are no re-write directives for this or any of the web-context on the server.
I’m fairly certain that’s not the issue in this case.
It could be an apache2 configuration issue. But I havn’t found it yet.
Thank you again for your time.

Hi Zac,
If I understand you correctly, then yes, each web context is in it’s own separate directory.
However, they are all under the ROOT directory. If they are not all supposed to be under the ROOT, then where should they be?
Thanks for your time.

Does anyone know how I could determine if this is a Lucee issue or a Tomcat issue?

It’s not a Lucee issue, it’s how you have setup your server.

ask google for your linux distro about where to put multiple virtual apache hosts for different domains, don’t nest them

are you using mod_cfml? if you are, you can enable the debug logging in your apache config and you can see how the requests are being handled

This. What you’re doing is called “nesting contexts” and it has been known to cause all kinds of strange behaviors that only makes sense once you get deep into the Tomcat internals of how it resolves contexts. Like Zac, I highly recommend against nesting contexts. Instead, create a unique directory for each site you have on your server so that one context is not located within another.

So, instead of:




or, if you’re on windows:


… had a little fun with the names there. :wink:


I think (not sure) there is a misunderstanding here, possibly because of how I worded it?
in the above example, /realized/ is not a directory of it’s own, it is a subdirectory of /dreams/
Meaning, it contains support files for the main folder above it. Just a a main folder might have index.hrml, then a subfolder below it holding images etc

All of my virtual domains are in their own directory. And all of those directories are under the ROOT

So on Linux I have …
/Opt/Lucee/tomcat/webapps/ROOT/(then all vitrual host directories here, each in their own folder or directory.

No directories are nested under one another they way you show above.

If that’s not the way it’s supposed to be please tell me. I’ve been doing this for about 2 decades and never had a problem.

Technically, nesting contexts in the ROOT directory is still nesting contexts, but it might not affect you much if you have no actual functional site in your ROOT directory or don’t use it much. Or… maybe you just got lucky and haven’t hit any issues yet? Either way, it’s still best to have all your sites in their own unique directories.

Going back to your issue, in order to verify if this is a Lucee config problem, when you log in to the Lucee Server administrator, hit the “Overview” link in the top left, and scroll to the bottom of that page under the heading “Web Contexts”, do you see the web context for the site in question? Is it pointing to the right location? What happens when you restart Lucee (using the lucee_ctl script), still there? This will help you identify if the incorrect config is coming from something hard-coded or something that is dynamically loaded.