Greg
Maybe I do not understand fully what you want to do.
When you store all application specific stuff and that file service dies
your systems dies. Would that be a problem for you?
Anyway if you store all settings in one place you can make those files
available in many places by using NFS or SMB. A sort of
write-once-read-many.
The advantage of using http://www.host.com/client as an entry is that the user
specifies where he wants to go.
FE
On Thursday, March 22, 2001 11:54 PM, Greg Matthews [SMTP:[EMAIL PROTECTED]] wrote:
>
> that's fine except if you need to run 2 or more boxes to
> handle the load.
>
> i want a single copy of the application specific config files
> shared by each clustered orion box.
>
> i also want to be able to programmatically determine where
> the config files are.
>
> if each orion box in the cluster knows that the root config
> directory is \\configmachine\configs\ then i can append
> say, the application name, to this to get a config directory.
>
> e.g. \\configmachine\configs\client1\config.xml for client 1
> \\configmachine\configs\client2\config.xml for client 2
>
> i can then change the application specific config details in a
> single place for client 1, and all of client 1's clustered application
> copies running across various boxes get the new information.
>
> the question is, where do i get "client1" or "client2" when building
> the path?
>
> the best i've been able to do is follow a previous post and get
> the application.xml defined <display-name> value, which doesn't
> really solve the problem because that's included in the .ear file.
>
> i was hoping to be able to programmatically determine the
> server.xml defined application name and use that to build
> the path.
>
> greg.
>
> ----- Original Message -----
> From: "Frank Eggink" <[EMAIL PROTECTED]>
> To: "Orion-Interest" <[EMAIL PROTECTED]>
> Sent: Thursday, March 22, 2001 7:03 PM
> Subject: RE: ASP config + clustering
>
>
> > Greg,
> >
> > Why run an instance of orion per client you are serving? I'm looking to
> > host an applications for a number of clients too, but I'm looking into
> > another route.
> >
> > We plan to 'copy' the applications and run them from one server-instance.
> > Guess for resource usage we are better off, just copying the applications
> > and have your clients served by one orion instance. Clients would connect
> > like //www.host.com/clientname/ or something like that.
> >
> > Additionally you can (on UNIX/LINUX) soft-link the original
> application.ear
> > instead of copying it.
> >
> > As long as you write the apps for the server, things should be secure in
> > this setup.
> >
> > FE
> >
> > On Thursday, March 22, 2001 1:45 AM, Greg Matthews
> > [SMTP:[EMAIL PROTECTED]] wrote:
> > > dear all,
> > >
> > > is there a way to get the server.xml defined <application> "name"
> > attribute?
> > >
> > > after following a previous post, i can get the application.xml
> > <display-name>
> > > value but this is not quite what i need.
> > >
> > > the plan is to be able to deploy multiple copies of the same application
> > > for different clients, and have an initServlet read in the application
> > name
> > > to determine where the config files live.
> > >
> > > e.g. client1 => read in \\someMachine\config\client1\config.xml
> > > client2 => read in \\someMachine\config\client2\config.xml
> > >
> > > this way, if i have to cluster client1, then there's only ever a single
> > > copy of their config information on the network and i don't have to
> > > duplicate it per orion installation.
> > >
> > > i'm also thinking of putting the web-site.xml files for each client
> > > in their own config directory to further reduce duplication of
> > > config details that would appear if you do clustering.
> > >
> > > i'd also like to avoid having to alter servlet initialisation parameters
> > > or anything in application.xml when deploying the app for a new
> > > client, but would consider these as a last resort.
> > >
> > > thanks,
> > > greg.
> > > << File: ATT00005.html >>
> >
>
>
