Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of yoavshapira@gmail.com designates
 64.233.162.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=Ha9FkHxlAAtZh4i+RSu4LK0GNeeo8MlsykHXSR5IPYXm7PExHFMl6ccECp+46EwxS6PfF1Pvk29PezIvkTvhTdAtiCHPaXHjuWGMJNAxYNZUnaav9Vx1HI+YjlT7Dso1K+PFIcAlhqZBgQfQo4udCwj2ITO2cFdAC+xy1MuVtMg=
Message-ID: <db94f1a0605041715k498b16b6v591c43400f235637@mail.gmail.com>
Date: Thu, 4 May 2006 20:15:28 -0400
From: "Yoav Shapira" <yoavs@apache.org>
Sender: yoavshapira@gmail.com
To: "Tomcat Developers List" <dev@tomcat.apache.org>
Subject: Re: Core webapps and clustering
In-Reply-To: <96e4b5230605041542v16b631eep5b7800f5cbcc0201@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <445A19CA.5090104@apache.org>
	 <6C194C99-CCF3-48BA-8A84-AA061F992C81@objektpark.de>
	 <96e4b5230605041123l6d6859bcv3b43433cef639e2f@mail.gmail.com>
	 <445A7762.1040208@apache.org>
	 <96e4b5230605041456k3496e94bi9203595b44439af7@mail.gmail.com>
	 <445A7BDB.6080508@apache.org>
	 <96e4b5230605041542v16b631eep5b7800f5cbcc0201@mail.gmail.com>

Hola,
Since you asked for opinions, personally I'm:

- In favor of having one clustering implementation, but I think
everyone is, no whoop there
- Would prefer that clustering, like admin, stay a little module
that's easily added to the core (and in general would like to keep the
core as small as possible)
- Agnostic on JMX versus server.xml (can see equal justification for both)

A lot of this is just style preference.  As long as we have a working
clustering module, I'm sure it will be fairly easy to have a distro
with it and a distro without it.  That's why I haven't chimed in much
on this, I don't have a strong preference either way.

Yoav

On 5/4/06, Costin Manolache <costin@gmail.com> wrote:
> On 5/4/06, Remy Maucherat <remm@apache.org> wrote:
> > Costin Manolache wrote:
> > > It's not about using a mini-jboss architecture, but about a more
> > > consistent and simpler
> > > configuration.
> > >
> > > IMO JMX should be used for configuration when possible, instead of
> > > adding more weird
> > > syntax to server.xml.
> >
> > I tried it quite hard at some point (it's the embedded distribution),
> > and it didn't work out that well. It's actually more complex.
> >
> > The first task is to optimize modeler (you'll do it, right ?), and then
> > maybe to use modeler exclusively in Tomcat (avoiding all direct JMX
> > dependencies).
>
> I'm actually trying to optimize it and finally implement the 'persist cha=
nges',
> but it'll take some time, I get less than 1h per day to work on open sour=
ce.
>
> I would say jboss style config is not _that_ more complex, and even 3.3 s=
tyle
> config was acceptable for many modules ( well, people might not agree
> with that,
> bit at least it was simple enough ).
>
>
>
> > > What is 'core module' and not is a complex issue - obviously what
> > > ships in the 'default' distro will
> > > change with each release. But clustering seems like a big enough and
> > > separate enough component to me, if this is not a good candidate for
> > > 'separate module' - I don't know what would be. It's clearly not used
> > > by all users, it has 2 implementations, etc.
> >
> > And it needs to get back to 1 implementation in a hurry :) I am
> > conceptually ok with it being a module, though, although I would be
> > happier if it was in the main tree (this way it's harder to ignore when
> > the build is broken).
>
> :-)
>
> Costin
>


--
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org