tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: Core webapps and clustering
Date Thu, 04 May 2006 21:04:45 GMT
IMHO no module should insert new rules in the server.xml reader.
It is already complex enough.

All modules should use a single syntax, based on JMX - where you specify the
mbean name, and then attributes you want to set. If you need more
structure - define
additional mbeans. There are plenty of example - I'm sure someone more
familiar with jboss can explain why it's better and more flexible this
way :-)

As for 'use the same jar name' and system property - a strong -1 if
it's not too late :-)
Why ? Looking for trouble ? Is confusing the user a goal ? Just use a
different name, leave both of them around - you can treat them as
separate modules.

Costin

On 5/4/06, Peter Rossbach <pr@objektpark.de> wrote:
> Hey Costin,
>
> look at o.a.c.starter.ClusterRuleSetFactory
>
>
>  > Snip ----
>          //OLD CLUSTER 1
>          //first try the same classloader as this class server/lib
>          try {
>              return loadRuleSet
> (prefix,"org.apache.catalina.cluster.ClusterRuleSet",ClusterRuleSetFacto
> ry.class.getClassLoader());
>          } catch ( Exception x ) {
>              //display warning
>              if ( log.isDebugEnabled() ) log.debug("Unable to load
> ClusterRuleSet (org.apache.catalina.cluster.ClusterRuleSet), falling
> back on context classloader");
>          }
>          //try to load it from the context class loader
>          try {
>              return loadRuleSet
> (prefix,"org.apache.catalina.cluster.ClusterRuleSet",Thread.currentThrea
> d().getContextClassLoader());
>          } catch ( Exception x ) {
>              //display warning
>              if ( log.isDebugEnabled() ) log.debug("Unable to load
> ClusterRuleSet (org.apache.catalina.cluster.ClusterRuleSet), will try
> to load the HA cluster");
>          }
>
>          //NEW CLUSTER 2
>          //first try the same classloader as this class server/lib
>          try {
>              return loadRuleSet
> (prefix,"org.apache.catalina.ha.ClusterRuleSet",ClusterRuleSetFactory.cl
> ass.getClassLoader());
>
>
> < Snap -----
>
> and ha currently build same jar name as the current cluster module.
> Current and new cluster has not the same configuration dialect. :-)
>
> My idea is, that we set instead a system.properties at
> catalina.properties like:
> digester.cluster.ruleset.classname=org.apache.catalina.cluster.ClusterRu
> leSet
> digester.cluster.ruleset.classname=org.apache.catalina.ha.ClusterRuleSet
>
>
> Then we can integrate new ha at normal build and user can easliy
> switch implementation.
>
> What you thing about this idea Filip and Costin?
>
> Peter
>
> Am 04.05.2006 um 20:23 schrieb Costin Manolache:
>
> > On 5/4/06, Peter Rossbach <pr@objektpark.de> wrote:
> >> I think we can merge both cluster and storeconfig modules to new tc
> >> 6. For current user it is easier.
> >>
> >> Only change is that new ha cluster module are packaged as seperate
> >> jar (name change a build.xml) and we must change the bootstrap logic
> >> at config parsing. I think user better switch cluster implementation
> >> with system.properties as autodetect a class. Then testing
> >> current and new cluster module are a lot easier.
> >
> > Could you explain a bit ?
> >
> > My understanding is that ha is an optional feature, that users can
> > turn on - i.e.
> > sort of a separate module, with no dependency between tomcat and ha.
> >
> > For modules - I assumed that each of them is a JMX component, that can
> > be configured using only JMX calls. I.e. no system.properties or
> > other change
> > to bootstrap logic.
> >
> > If this is not the case - why and can we fix it ?
> >
> > Re: moving the code to the src/ tree - I'm not very sure. I think it
> > was a clear benefit to
> > have all core tomcat components in the same tree - i.e. connectors,
> > jasper, catalina.
> >
> +1
> > But I think it would also be good to have a separate 'modules' and
> > 'webapps' area, and
> > keep them separate, at least for things that are not required for a
> > basic tomcat. Or at least for things that have external deps, or are
> > big.
> >
> +1
> > Costin
> >
> >>
> >> After merge I can start session manager refactoring and later I made
> >> a tc 5.5 backport.
> >>
> >> Regards
> >> Peter
> >>
> >>
> >>
> >> Am 04.05.2006 um 17:12 schrieb Remy Maucherat:
> >>
> >> > Hi,
> >> >
> >> > I was wondering if I should merge the code for the core manager
> >> > webapp in the main source tree, or if I should keep them in the
> >> > webapps subfolders. There is one dependency for the manager webapp
> >> > on commons-fileupload 1.0 (so if the code for the webapp is merged
> >> > in the main source tree, commons-fileupload will get the package
> >> > renaming treatment).
> >> >
> >> > Similarly, the clustering module (the new ones, most likely) as
> >> > well as the storeconfig should most likely be merged in the main
> >> > source tree.
> >> >
> >> > Rémy
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
>
>
>
Mime
View raw message