----------------------------------------------------------------
BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
WHEN YOU POST, include all relevant version numbers, log files,
and configuration files. Don't make us guess your problem!!!
----------------------------------------------------------------
At 9:18 AM +0100 12/8/99, Jean-Luc Rochat wrote:
>
>Laurie Harper wrote:
> >
> > Jean-Luc Rochat wrote:
> > > Disable authentication on both sides (jserv.conf & jserv.properties), or
> > > enable it on both sides.
> >
> > Ouch, an ugly and entirely predictable failure resulting from
> > duplication
> > of information... Is there any particular reason there can't be a
> > shared
> > config file that would be read by both sides? (Apart from the different
> > formats of jserv.conf and jserv.properties, which is a trivial issue.)
> > The shared file could then specify things like the authentication mode,
> > which AJPV to use and any other 'shared' configuration.
> >
> > Laurie
>
>I'm totally against this idea. It sucks. Why ?
>
>
>So, you can now (described in :
>http://java.apache.org/jserv/howto.load-balancing.html) have N Apache
>using M JServ.
>As every JServ doesn't have to be on the same machine as Apache, and
>that JServ doesn't have to be dedicated to one Apache,
>it is not possible to share one configuration file, is it ?
>
>
>Hope this convinces.
>
>Jean-Luc
I agree with Jean-Luc that we are unable to have a shared
configuration file, but I also agree with Laurie that it would be
very convenient if we did have one. Maybe we should think a little
about how we could do this.
In the load-balancing code, we got around the shared-configuration
file by passing the host indicator tag from Apache to Java through
ajp. This is how it was possible to have that configuration set up in
only the apache side. This also means that we're sending data from
apache to java that wouldn't be necessary if we had a shared
configuration file; a small inefficiency. A while ago I had proposed
the ability to configure the name of the jserv cookie from
JServSessionID to something else like "MyCompanyID". I began writing
this code into the system when I noticed that this would be another
case that we'd need to pass that information through every request or
have another duplicate configuration option on the apache and the
jserv sides. I abandoned this effort when I realized that it was
going to be a very FAQ from the start and it wasn't worth that
difficulty.
I'd like to propose a compromose. This would be simply a
configuration file that is compatible between the apache and the
jserv sides. It doesn't need to be "shared" by both sides since they
could be on different machines, but they would be able to be shared
if they happened to be on the same machine. We would probably want
this to be a separate file for each instance of jserv rather than
sharing a single configuration amongst all jserv instances.
I'm thinking this through for the first time now, so bear with me if
this is totally crazy.
In jserv.conf (apache side) we currently define parameters global to
the apache side (like logging, etc), but most of that file is related
to the communication between apache and jserv. It looks like it was
initially designed to communicate with only a single instance of
jserv, and we've messed around with it to make it work with multiple
zones and multiple instances of jserv.
What if we had a configuration file for each instance of jserv that
can be read by the module, but can be duplicated verbatim to the
jserv side for use there?
The file would need to be more like jserv.properties, since that is
more jserv-specific, but also it needs to be able to give that jserv
context within the apache world which may have multiple instances of
jserv.
One simple way to do this is to have some line prefix that gets a
line ignored by apache and another that gets ignored by jserv.
Let's say the ignore characters are '$' and '%' (I have no idea what
we would actually use, but '#' may make sense for apache so that we
can use the standard apache config parsers)
Then a file might look like this:
In jserv.conf, we'd have:
----
#
# Set up my zones
#
ApJServMount azone ajpv12://myset/myzone
#
# Read configuration from each jserv
#
Include jserv/machine1.conf
Include jserv/machine2.conf
Include jserv/machine3.conf
----
Then each of these files we'd have something like this (machine1.conf):
----
#
# Set up security (apache-side)
#
$ApJServSecretKey conf/jserv.secret.key
#
# Set up security (jserv-side)
#
%security.maxConnections=100
%security.allowedAddresses=127.0.0.1,1.2.3.4
%security.authentication=true
%security.secretKey=/path/to/my/jserv.secret.key
%security.challengeSize=5
#
# Set up balance (apache-side) for this jsev instance
#
$ApJServBalance myset machine1
$ApJServHost machine1 ajpv12://mymachine.mycompany.com/myzone
$ApJServRoute A machine1
#
# Set up balance (jserv-side) for this jsev instance
#
%zones=myzone
%myzone.properties=/path/to/this/zones/zone.properties
----
What do you think? Of course this would mean rewriting the parser for
the config files. Probably the simplest would be to only change the
jserv config parser and let it treat any line that doesn't start with
some prefix be a comment. Maybe that prefix should be "#%" so that it
automatically gets commented out from the apache side.
Then the config would look like:
#This is a comment for everyone
#%zones=myzone # This is a comment for apache, but read by jserv
ApJServBlah stuff # this is a comment for jserv, but read by apache
Comments?
Bernie Bernstein
Talk City Inc.
voice: 408-871-5320 Join the Conversation.
email: [EMAIL PROTECTED] http://www.talkcity.com/
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
