Mappings directory with corresponding single cfclasses directory

dev support
21 
org.apache.catalina.core.StandardContext.loadOnStartup Servlet [CFMLServlet] in web application [] threw load() exception

Hmm, so output in the logs is always interesting because there can be stuff that looks like an error but it’s more of a warning, or sometimes just an internal issue that was caught and dealt with. I can’t say I recognize either of those messages off the top of my head but they do mention the CFMLServlet.

I would now turn your eye to the standard output-- usually catalina.out or similar. When Lucee boots up for the very first time there’s a bunch of lines that detail each web context that is created, the location of the context, and all the files created. I think that will reveal some information for you. Also, if Lucee is erroring out (perhaps the directory isn’t resolving?) there should be some output there to help. Lucee tends to write only to the standard out and not the error out stream.

FWIW your setup using commandbox, in my limited understanding, is different to mine being a local install directly into windows

Yes and no. The servlet setup is different but the Lucee feature we’re dealing with where by an init param can be used to control the location of the server and web context is still the exact same functionality really regardless of the servlet setup.

Here’s another thing to try-- I vaguely recall once having issues setting the web context path when I didn’t also have a server context path. I can’t find a ticket to corroborate my memory, but it might be worth a test where you set both the server and web context paths in web.xml at the same time. CommandBox sets both for instance. Setting them both should look something like this:

<servlet>
	<servlet-name>CFMLServlet</servlet-name>
	<servlet-class>lucee.loader.servlet.CFMLServlet</servlet-class>
	<load-on-startup>2</load-on-startup>
	<init-param>
		<param-name>lucee-server-directory</param-name>
		<param-value>C:/path/to/luceeServerContext/</param-value>
	</init-param>
	<init-param>
		<param-name>lucee-web-directory</param-name>
		<param-value>C:/path/to/luceewebContext/</param-value>
	</init-param>
</servlet>
22

Unfortunately this changes very little. It put a couple of files in the global server context folder but all the same WEB-INF directory in each site.

Also as I mentioned previously a couple of times, this setting does not seem to be valid without a placeholder

<init-param>
		<param-name>lucee-web-directory</param-name>
		<param-value>C:/path/to/luceewebContext/</param-value>
	</init-param>

As this seems to generate this error below

20-Sep-2018 14:48:06.338 SEVERE [w3svc3-startStop-1] org.apache.catalina.core.StandardContext.loadOnStartup Servlet [RestServlet] in web application [] threw load() exception
javax.servlet.ServletException: static path [C:/lucee/web-contexts-global] for servlet init param [lucee-web-directory] is not allowed, path must use a web-context specific placeholder.

I am not sure that what I’m trying to achieve is possible.

I know there are ISP’s out there with shared lucee hosting so not sure how they are scaling short of just throwing more and more resources at their server cluster to handle the massive amount of file duplication a basic lucee install creates.

23

Ah, so that is very helpful. That specific error message is what I needed to track down the exact code inside Lucee that we’re up against.

I’m afraid it’s a bit of bad news though. As you can see in the link above, Lucee will allow a static path IF there’s only a single context. This is the scenario I’ve done a lot where I have more than one server instance all using the same static context. But as soon as you add a second web context to the mix, then it stops you. Since all your contexts are in the same server that finally explains why it didn’t work for you!

So, there is still hope for you but we’ll have to change our tactic. I can think of two different approaches to try. The first one is this-- I noticed in that code above that Lucee simply detects that a { character must exist in the path which indicates a placeholder, however Lucee does not check to see what placeholder is present. This means you could probably trick Lucee by using another static placeholder such as {home-directory}/luceewebContext or {system:JAVA_PROP_CONTAINING_PATH}/luceewebContext. Again, I’m not sure if there are any side effect of this, but it would probably trick Lucee into letting you use it. That second example would likely be coupled with a JVM arg like so:

-DJAVA_PROP_CONTAINING_PATH=C:/lucee

Now, the second way out of this is to actually force Lucee to only have one context in the first place. I’ve never done this setup but I’ve talk to some who have. It would involve using a single web host and rewriting different domains to separate folders in the web root but since I’m not super familiar I’m afraid to try and describe it. Let me ping the person who told me about this setup (they had around 200 websites I think) and see if they can chime in.

And lastly, can you confirm if you actually have 300+ separate web roots of code or is it the same code 300+ times?

24

Thank you for the follow up, just as an answer to your question. Our scenario is 300+ separate web roots that access a good amount of shared code stored in “Mapped” directory. So the core functionality of each site is pulled from the mapped files but they also have their own (additional) local unique files.