ROOT.xml overwritten on Tomcat restart (and a mod_cfml.core logging problem)

[kev]

Hello

I have installed Lucee+Tomcat including mod_cfml, using the installer lucee-5.3.4.080-pl0-linux-x64-installer.run

Installed on Centos 8, running in a vmware VM.

The installation went well, and both Lucee and mod_cfml are working. I very much like the automatic configuration provided by mod_cfml.

I have encountered one problem which I hope someone can help me overcome. 

In attempting to investigate this problem I tried to turn on logging for mod_cfml.core so that I could see what the module was doing when it created the configuration files, but I get no debugging output in either catalina.out, or the system log. 

I do get plenty of output in catalina.out, just notheing from mod_cfml.  In server.xml I have changed loggingEnabled="false" to loggingEnabled="true" and restarted Tomcat - in fact the VM has been restarted a number of times - but no logging output from mod_cfml.core.  If anyone can help with this problem as well it would be useful. Thanks.

The problem I have found is that after a Tomcat restart, the ROOT.xml file in the automatically created directory for the Apache host is overwritten on the first request. 

To be clear, the automic configuration for this host completed in a previous session of Tomcat, the first request triggered the configuration and subsequent requests did not trigger mod_cfml.core - all as expected.

Then Tomcat is restarted. The first request for this host again triggers mod_cfml.core - I suspect this is deliberate but I am not sure. But, this new configuration overwrites the ROOT.xml created previously. When I look at the code for  mod_cfml-valve (core.java) it seems to check for the existence of the file and if found it would not overwrite it - but it is in fact being overwritten. I may have misunderstood the code. (This is where debugging output would be really useful!).

In most cases this would of course not matter. But, I want to add a line to the ROOT.xml file to turn on the rewrite valve org.apache.catalina.valves.rewrite.RewriteValve - the valve needs to be added to the context element in ROOT.xml so that it applies only to this webapp, rather than all requests for the host (it can be added to server.xml, but I don't want the same rewrite rules for all virtual hosts).

I sucessfully added the valve, and a watch for the rewrite.config file in WEB-INF, and the rewrite was working fine, with changes to the rules file being automatically configured as desired thanks to the watch.

Everything working well.. Until... Tomcat was restarted.  Then I lost my changes to ROOT.xml because of automatic configuration running again on the first request.

So... 

1. Why does mod_cfml.core run again after a Tomcat restart? The configuration files are now created, so it isn't needed. (I noticed in some documentation on mod_cfml somewhere that to re-create the configurations for the dynamic hosts, you can restart Tomcat - so that is why I think this might be deliberate. But.. you could just remove the conf/Catalina/<host> directory to get the same effect). (Much less of a sledge-hammer approach too).
2. Should mod_cfml.core be overwriting the ROOT.xml file if it already exists? Is there a bug?  If it is intentional, could there be a configuration setting to prevent it?  

Thanks for reading. 

[Jordan Michaels]

The logging portion of mod_cfml just uses a "system.out.println()" method, which should get caught by the default logger dropped into the Tomcat catalina.out. If it's not getting placed, then the valve either isn't getting hit or the output is being diverted some other way. Did you modify the loggers at all? Logging using a standard Ubuntu install works for me using 1.1.11. You should at least see the mod_cfml version number on Tomcat boot.

There is no code currently that prevents an existing directory from being overwritten on a new request (that's a nice feature request though). However, you should be able to add your context rewrite config to the server.xml file just within the <Host> tags for your site and have it work like it should without affecting the other contexts. Have you tried it and it didn't work?

--
Kind regards,
Jordan Michaels
Vivio Technologies

1. Why does mod_cfml.core run again after a Tomcat restart? The

configuration files are now created, so it isn't needed. (I noticed in some
documentation on mod_cfml somewhere that to re-create the configurations
for the dynamic hosts, you can restart Tomcat - so that is why I think this
might be deliberate. But.. you could just remove the conf/Catalina/<host>
directory to get the same effect). (Much less of a sledge-hammer approach
too).

2. Should mod_cfml.core be overwriting the ROOT.xml file if it already

exists? Is there a bug? If it is intentional, could there be a
configuration setting to prevent it?


Thanks for reading.

--
You received this message because you are subscribed to the Google Groups "mod_cfml" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mod_cfml+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mod_cfml/33ecff6d-5746-46e9-813f-fef78940000d%40googlegroups.com.

[kev]

Thanks for your reply :) 

...

I have now created a new VM and installed Tomcat 9 manually after downloading from the Apache Tomcat website.

After putting  mod_cfml-valve_v1.1.11.jar into <catalina_home>/lib, and modifying server.xml accordingly, I can now see the cfml-valve output in catalina.out. Prevously I used the lucee/tomcat installer, but then I did some modifications to the config so that I could access the 'manager' and 'host-manager' webapps which that install seems to exclude. Maybe that did something that stopped the cfml-valve debug output from reaching catalina.out. I may look deeper into that at a later date. 

I think I will proceed with this build where I have installed Tomcat myself. I have yet to install Lucee, but at least now I can see what cfml-valve is doing. 

I now have a better understanding of what cfml-valve does when it receives a request, and I have worked out why it runs again for each virtual host after a tomcat restart. The reason is that the changes it makes are volatile, because they are not saved to server.xml. So, after a restart Tomcat has no configuration for the Apache virtual host, and so directs the request to the default host - which is then handled by cfml-valve and the host is re-created.

So, I have a suggestion. 

In Tomcat 9 there is a new feature within the host-manager which allows the configuration to be made 'persistent' . This effectively gets Tomcat to re-write server.xml to match the in-memory configuration in use by Tomcat. Since cfml-valve uses the same API as host-manager it is able to do the same (Tomcat 9 is required for this however). When cfml-valve creates a new host, it could then have Tomcat save the new host to server.xml. (Make persistent can specify a single host to 'make peristent). Maybe there should be also an additional configuration parameter in cfml-valve to turn this feature on, so as to maintain current 'non-persistent' processing for existing installations.If this feature were implemented then cfml-valve will only run if the host does not exist within Tomcat, and won't run after a restart because hosts it creates will be 'persistent'. My preference would be for cfml-valve to create the host config automatically, but once created the host config would be untouched by cfml-valve. It's a fairly simple matter to remove the config if for some reason you wanted it to be re-created automatically. 

As far as my use of rewrite.config is concerned, yes I could create a host entry in server.xml - but then that rather defeats the point of mod_cfml !!  Ideally new Apache virtual hosts will be automatically configured without having to restart Tomcat, but any changes to server.xml require a restart. If I add the necessary <valve> for rewrite to the context file the rewrite is automatically configured without a restart.. But of course this change should survive a restart otherwise I'm back to manual configuation, and restarting Tomcat to incorporate changes.

Thanks for taking the time to review.

[Paul Klinkenberg]

Hi Kev,

Thanks for the suggestion of using the persistent config option in Tomcat. I really appreciate new enthusiasts on the mailing list :)

When I started with Lucee (then Railo), I was amazed that Tomcat (then Resin) was not automatically configured, just like with ColdFusion. So I started to ask around, and mostly got the reply “any developer should know how to configure tomcat/resin/etc”.

To me, this was bs. I was used to the convenience of the ColdFusion “magic connector”, and couldn’t imagine others were not missing it.

After a few failed attempts by me to create something like the “magic connector”, I found out Jordan Michaels was creating mod_cfml. Which was great! Finally, a more or less ColdFusion-compatible server setup.

Without the requirement “any developer should know how to configure tomcat/resin/etc”.

If we would now implement a static configuration on the tomcat side, the developer again needs to be able to configure tomcat him-/herself, if the config later changes in Apache/nginx/iis.

Therefor, I am a strong advocate to keep it simple, and not use static Tomcat configuration. Mod_cfml is not a setup tool, but a connector.

I do understand the http redirect after modcfml started a new site can be a bit of a nuisance; I guess that’s why you would want a static config? 

If you have any more time, you could investigate if we can hook the tomcat connector earlier in the catalina lifecycle, at a place where a Host is not yet assigned to the request. If we have such a hook available, we could check based on the disk config (or reading available Hosts?) to see if we need to add the requested config. 

Just a random idea to maybe fix the need to do a redirect ;)

Please keep the ideas coming!

Kind regards,

Paul Klinkenberg

------------

Op 5 mei 2020 om 19:51 heeft kev <ke...@bluestreak-hosting.co.uk> het volgende geschreven:



--
You received this message because you are subscribed to the Google Groups "mod_cfml" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mod_cfml+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mod_cfml/46684598-5623-41a8-ac52-81d800fcc6db%40googlegroups.com.