I'd thought I'd chip in my 2 cents,
1. I don't think we should keep maintaining two clustering modules in TC6,
the old one has too many limitations, I would leave it as a module
since its stable,
but I don't have any plans of trying to beat the dead horse and try
to make it do
something it wasn't built to do.
The new "ha" module, which is far from complete is trying to address
most of these
limitations, but also extend to features like context attribute
replication,
probably a second attempt at farming, delta versioning and many other
features.
2. I would integrate the new "ha" module into the main tree
as Remy suggested, easier to catch when it breaks,
and session,context and other data management is something that
is pretty intimate with Tomcat's code base
3. I was gonna make the "comm" layer, default to tribes
but be pluggable, if someone prefers to use something else, like
Appia, Spread, jgroups etc.
To avoid more server.xml clutter,
I was simply thinking of binding the comm layer into the
JNDI tree as a regular resource so that resources simply
can look it up and take advantage of it. That way, when tomcat is
embedded,
that container would probably want to share this comm resource, and
they are
able to through JNDI.
4. JMX, yes, hit it on the nail, there is nothing pluggable about
tomcat's JMX right now,
For example, MBeanUtils.createObjectName(String,Connector), if the
connector does not
contain the string "CoyoteConnector" it simply throws a
MalformedObjectNameException
So this area would need to be revisited in large before it would be
something like
Rickard Oberg created for JBoss that made it so pluggable through JMX
and MBeans,
geronimo has something similar through their GBeans/XBeans.
On a personal note, I think JMX should do monitoring and I think
injection can be done in
many more ways. but that is a philosophical point.
I do see the benefit of adding the new cluster module "ha" to the main
tree, and I would support that effort.
I would keep the old "cluster" module as a module, eventually sunsetting
it. I would keep "groupcom" as a module
as this is not really a core tomcat feature, but providing the
context/session management is.
have a great Friday folks!
Filip
Yoav Shapira wrote:
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 <[EMAIL PROTECTED]> wrote:
On 5/4/06, Remy Maucherat <[EMAIL PROTECTED]> 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
changes',
but it'll take some time, I get less than 1h per day to work on open
source.
I would say jboss style config is not _that_ more complex, and even
3.3 style
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
[EMAIL PROTECTED] / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
