On Oct 17, 2008, at 7:02 AM, randersen wrote:




djencks wrote:


On Oct 16, 2008, at 11:56 AM, randersen wrote:

The structure would be more like:

GERONIMO_HOME
  customers
      customer1
          customer1-repo
          instance1
              var
          instance2
              var
      customer2
          customer2-repo
          instance1
            var

This would allow the deployment of multiple customers on 1 machine
that use
different databases to use the same database pool without having to
deploy a
second repository in each instance for the database pool.  Is there
a system
property for the repository directory like there is for the var
directory?

I'd like to know more about what you are trying to do.  If each
customer is using the same applications and the only difference
between them is which database their copy of the app needs to connect
to then you only need one repo.  The only reason I can think of to
have one repo for each customer is if you have apps for one customer
that you need to prevent being started on other customer's servers.

In the unlikely event you are using derby or another db that stores
data inside geronimo's var dir then each customer will already get a
new copy of derby simply because they have their own var dir.

In the more likely event you are using an external db and each
customer has their own copy you have at least these two options:

1. use a config.xml snippet with a config-substitutions variable for
the db name or url (and user/pw presumably) and set these in each
server's var/config/config-substitutions.properties

2. deploy a fully configured db pool on each customer's server
pointing to the appropriate db and use artifact-aliases to have it
replace a standard or dummy db pool.

still trying to understand what you are trying to do....
thanks
david jencks

The only difference is the database to which they are connecting to and it is an external one. We will be running multiple customers (each customer having a different database connection) with multiple instances for that customer on the same host and using the same version of the application. The only thing that needs to change is the db connection information for
the database pool.

1. Would that be this line:
   <module name="console.dbpool/CustomerDBPool/1.0/rar"/>

  how do you specify the attributes for it?

2. I don't understand this part, are you saying that for each customer we have a separate installation of geronimo? So if I have 3 customers on one
host I'll have 3 installed versions of the software with the instance
config under each one?

I like the sound of #1, that would mean that we could have 1 installation
of geronimo and have all the instances underneath and just change
config.xml for the ones that would use a different db connection.



Both solutions involve only one installation of geronimo. Both involve deploying the datasource as a geronimo plugin and using some plugin features. If you have any maven familiarity at all it's easiest to generate the plugins using maven and the car-maven-plugin, although it's not essential. In either case I'd generate the initial plan for the datasource using the admin console.

There are some general instructions on setting up maven plugin projects here: http://cwiki.apache.org/GMOxDOC22/constructing-a-special-purpose-server-using-maven.html

in either case you'd create the multiple geronimo instances with something like

mkdir -p customer1/instance1
cp -r var customer1/instance1
... repeat for all customers, instances

for (1) you probably want to do this after deploying the app and datasource plugin and for (2) before deploying the app and datasource plugin.

(1). You'll need the full abstract name of the JCAManagedConnectionFactoryWrapper that represents the datasource. I think you can determine it by turning logging to debug and starting the server after the datasource is installed. Look at the log..... it may take some searching.

in the car-maven-plugin configuration in the pom.xml set up a config.xml snippet like....

                    <instance>
                        <plugin-artifact>
                            <config-xml-content>
<gbean name="---(name of JCAManagedConnectionFactoryWrapper)---"> <attribute name="Database">$ {DBName}</attribute>
                                </gbean>
                           </config-xml-content>
<config-substitution key="DBName">Customer1DB</config-substitution>
                        </plugin-artifact>
                    </instance>

The actual attribute(s) you use will depend on which tranql wrapper you are using: any config-property name can be used as an attribute. What this does is expose these attributes as properties in var/config/ config-substitutions.properties. After you copy the var directory into the multiple locations you can edit each customer${x}/instance$ [y}/var/config/config-substitutions.properties to have the correct value for that instance.

(2) Create a datasource plugin for each customer db, set up to connect to that db. Instead of modifying the config-xml-content and using a substitution variable you'll have each plugin replace a default one. For the non-default datasources include something like
                    <instance>
                        <plugin-artifact>
<artifact-alias key="org.myco/ defaultDatasource//car">org.myco/datasourceX/${version}/car</artifact- alias> <artifact-alias key="org.myco/ defaultDatasource/${version}/car">oorg.myco/datasourceX/${version}/ car</artifact-alias>
                        </plugin-artifact>
                    </instance>

set up all the instances and deploy the appropriate datasource and the app on each of them. The code will only get installed once into the single repository but each installation will be using the datasource you deployed on it. It might seem a bit mysterious but the individual var/config/config.xml files control which plugins are started on each server instance so by deploying the appropriate datasource plugin on each server instance only that datasource will be started.

Hope this helps.... seems like a good topic for a help page, perhaps I'll be able to scrape together more time to set up an example.

thanks
david jencks



--
View this message in context: 
http://www.nabble.com/Multiple-Instances-With-One-Repository-tp20001882s134p20033920.html
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.


Reply via email to