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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
