tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Rossbach ...@objektpark.de>
Subject Re: Core webapps and clustering
Date Thu, 04 May 2006 20:54:18 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message