Best way to clone a project

Hi:

I have a multi-tenant application that wasn’t designed that way to begin with. My brute-force solution has been to extract the application to a “base” project which goes into a local maven repository. I then create a shell project that loads the base application as a dependency. The only change in the shell project is to modify the database connection username/password to point to the new tenant.

Is there an easy way to clone the shell project? There doesn’t seem to be a function in Studio to copy/clone a project.

hi,

if you really just change the the connection settings, why don’t you just use parameters of the war file? You can just externalize this configuration.

See here for more information: Deploying a base container image to multiple instances with unique database connection - CUBA.Platform

If you really need to stick to you approach since you want to add more code in the shell, you have to do a little bit of programming. One example would be to create a lazybones template and use it.

Bye
Mario

Not sure how that would work for me, as I have one tomcat app with multiple webapps deployed. Maybe that is a bad idea?

This means that each webapp has its own URL. That means each Cuba app has its own modules-prefix as well as deployment settings, like this (for a webapp named “rade-ntc”):

[‘cuba.automaticDatabaseUpdate’ : true,
‘cuba.webHostName’:‘www.paslists.com’,
‘cuba.webAppUrl’:‘https://www.paslists.com/rade-ntc’,
‘cuba.connectionUrlList’:‘https://www.paslists.com/rade-ntc-core
]

I will have to read up on lazybones.

I really wish this stuff was configurable at the deployment level! It would be great if one application could have multiple deployment configurations, with the various deployment-specific settings available. At deploy time, you pick the configuration you want to use.

Im not sure why you think this is not suitable for you. As I see it, you use-case matches exactly with the idea behind external configuration files in general and the context.xml file in particular.

The context.xml is a file that can live within the war containing the configuration option, or is sits outside of the war file in the conf directory of the tomcat and configures the datasource from the outside.

Take this example here:
In this app i have a context.xml within the war file, that defines a HSQL DB:

Then, outside of the war file I create a docker container. Within this container, I want to change the datasource with another user password (and even another DMBS like Postgres in this case):

The outer context.xml will override the properties of the file within the war file.

This technique works exactly the same way with the app.properties files. See the docs.

The question if a tomcat with mutiple wars running simultaneously is pretty much orthogonal to the above. Let’s say it has a lot of downsides and some upsides. But in fact it is not super common anymore to put all wars in one tomcat. But this is up to you, how you want to handle it.

E.g. when you use something like the Uber-jar then this decision is already made for you because the tomcat sits inside the war / jar file.

Bye
Mario

I guess my confusion stems from not knowing anything about Docker. I will do some research.

As for the Tomcat/multiple apps issue, do you have anyplace you can recommend I can read up on a way to distribute traffic to individual tomcat instances based on the URL? This is kind of the inverse of clustering. If each app is on its own Tomcat instance and I don’t want to have to give port numbers to each customer, then something has to know how to separate the traffic. Any hints?