Allow custom site settings within global mode (Feature request)

[paulklinkenberg]

Hi Bilal, I Hope you are doing well :) For a client of mine, I wanted to migrate 1 out of their 100+ sites to a different Lucee instance. Their setup is IIS+BonCode + 1 Lucee instance, and they used the "global setup mode" for the Boncode Connector.

Afaik, the only way to work with IIS+Boncode to make this happen, is to start using the "site-specific setup". That would mean:

• I first have to set it up (99 sites -> port 8009, 1 site -> port 8010) using your installer.
• Then, I have to edit each BoncodeSettings file, to manually add the "modcfml secret key".
• From then on, the client will need to run the installer again any time they want to add a Lucee site. (Plus add the secret key in the settings file)

As you probably guessed from the issue title already, would it be possible to have a global mode for the BonCode Connector, which also allows to have custom settings for any site? So it would by default use the global settings (secret key!), and if set, uses custom settings for a site.

If those custom settings would be kept outside of the webroot, you could also smash issues #59 and #64 in one go!

Well, I hope you find this a brilliant idea, and also have tons of time to implement it ;-)

Kind regards, Paul

[Bilal-S]

Paul: good to hear from you.

I think I understand the pain. Our problem is that we are working in the Microsoft framework. Specifically handlers and code-behind-pages etc. I am not sure that there is an elegant solution.

The way MS sees this there are only two valid patterns:

• code is shared globally: This is our global install. It puts code into an area called global assembly cache (GAC).
• code is only for one App pool/IIS site: All code is copied and maintained with the site.

Unfortunately, these are mutually exclusive. You select either option in the installer.

However, there are ways to go beyond that. You will most likely have a few scripts to copy and run commands to manage them. Scripts have to modify the web.config and copy the files to the correct places. Then of course, you also have to do the key generation. I have not tried to do either of these:

a) Moving BIN folder

Can be done in limited fashion. You still have to keep the code in the subfolder of website. You add probe attribute to the web-config or you can remoting code assemblies (Dlls) completely. Here are details: https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/specify-assembly-location

b) In .net 45 and above (IIS8+) a new concept was introduced to allow Application pools to share assemblies:

It uses symbolic links and you can move the assembly/code files from the webroot. I have not tried this myself. I am not sure what happens in this circumstance when we try to find the setting file. It still maybe something to try.

See here: https://docs.microsoft.com/en-us/aspnet/whitepapers/whats-new-in-aspnet-45-and-visual-studio-2012#_Toc_perf_3

From the looks of it this could work for you. You can control most of your sites that way and have diverging individual setups only for the site that are different.

Hope this helps,

• Bilal

[paulklinkenberg]

Hi Bilal,

Thanks for the in-depth response 👍 It actually made me dive into your code to see what's going on.

After reading through it, I thought "why not do it the old-fashioned way of reading custom settings from disk?" So I created the following code, to show you what it could look like in my opinion: https://github.com/paulklinkenberg/iis2tomcat/commit/b28955ee42884427f97e5d474585e7a29c363a16 The code was written on my Mac, without access to VS or IIS, and is therefor untested. But it tells the approach I am thinking of: when in "global mode", check if {webroot}/BIN/BonCodeAJP13.settings exists. If so, load it, and use it to override the current settings.

Would this approach be something you can accept? I know the dogma of "work with the framework, not against it", but this hopefully does get the job done...

Hope to hear from you again! Kind regards, Paul

[paulklinkenberg]

By the way, the installer would also need to get updated if this feature is added. It should give 3 choices I think, instead of the current 2 (global vs. site-specific):

1. Global installation for all websites; custom settings can be added later
2. After global install: update specific sites with custom settings
3. Only install for specific sites (first test if no global install has taken place yet)

[Bilal-S]

Paul: I see your approach. I think we would have to do some more work on it. We will have to retool the connector startup processes and connection target determination.

The current process is during init:

1. determine configuration type (global/site)
2. load setting file
3. assign setting values to non-mutable static values and objects (enums)
4. init IIS Handler and create instance of AJP translator per connection
5. run AJP process(es)

The biggest problem in this is the static declaration and caching of values once loaded in program enumerations. This creates great efficiency, but does not allow changes to values once loaded/initialized.

In short we have to refactor all places where any of the enumeration objects have been used, redo static values to be dynamic, etc.. We should still cache the config file as to avoid disk overhead so the config file XML would have to be expanded (as you indicate).

<settings>
     defaults

     <site id="999">
         ... site 999 specific override
     </site>

     <site id="22">
        ...site 22 specific override
     </site>
</settings>

All this is quite a bit of effort to do so I am not sure it will be something I can do quickly.