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.