You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2006/05/04 17:12:10 UTC
Core webapps and clustering
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
Re: Core webapps and clustering
Posted by Remy Maucherat <re...@apache.org>.
Peter Rossbach wrote:
> I think we can merge both cluster and storeconfig modules to new tc 6.
> For current user it is easier.
I will start with storeconfig, that's quite easy.
> 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.
If the new clustering module has benefits, then it should replace the
old one in the new branch. Did you try it ?
> After merge I can start session manager refactoring and later I made a
> tc 5.5 backport.
Ok.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Core webapps and clustering
Posted by Costin Manolache <co...@gmail.com>.
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
> >>
> >>
>
>
>
Re: Core webapps and clustering
Posted by Peter Rossbach <pr...@objektpark.de>.
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
>>
>>
Re: Core webapps and clustering
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> 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.
This is cute, but would serve absolutely no meaningful purpose. Tomcat,
unlike the two products you quote, is not an integration container. If
it is or becomes one, then I suppose some people would find it cool, but
personally I would likely stop using it.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Core webapps and clustering
Posted by Peter Rossbach <pr...@objektpark.de>.
Hi,
Am 05.05.2006 um 05:34 schrieb Filip Hanik - Dev Lists:
> 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.
+1
Currently we can copy the old one to TC6 to help people start
testing. The new
cluster module is pretty cool and after it was complete, we deprecate
the good old horse :-)
You change every day a lot. Duplicate those changes are a nightmare
and do much work.
Better we test the new cluster together and after the first
development is finished, we can copy and maintain it.
> 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.
>
Cool! After my conference week I hope start real testing.
> 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
+1, to intergrate the build at tc 5.5.
>
> 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.
>
I thing JMX is the better option!
> 4. JMX, yes, hit it on the nail, the
> re 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.
Both are good platforms, but you thing we can use it directly?
> 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.
>
Yes! Yes, I think we need a better JMX core that are independent form
implementation. Like a Tomcat JMX API
and people can easier switch implementation and make real dynamic
remote management possible
> 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.
>
Let us add it for eaisier testing.
+1
> have a great Friday folks!
>
Thanks and also have nice day...
Peter
> 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 <co...@gmail.com> wrote:
>>> On 5/4/06, Remy Maucherat <re...@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 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
>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: Core webapps and clustering
Posted by Peter Rossbach <pr...@objektpark.de>.
Am 05.05.2006 um 14:38 schrieb Henri Gomez:
> Well we discuss for Tomcat 6, not Tomcat 5.5
>
+1, exactly
> Did there is some deadlines for Tomcat 6 ?
>
No! We have time, but we need a good plan, design and developer team
that really
implement the stuff. :-)
> 2006/5/5, Peter Rossbach <pr...@objektpark.de>:
>> Am 05.05.2006 um 14:13 schrieb Henri Gomez:
>>
>> > Well being modular, components oriented won't be bad.
>> >
>> > It's not about cloning Geronimo, but allowing tomcat to get more
>> and
>> > more modules and extensions, like does Apache HTTPD
>> >
>> Good topic, small core with a lot of nice features...
>> Tomcat as a plugin container. Sounds good to me!
>>
>> Smaller core with robust implementation are more straightforward
>> embeddable.
>> But how you think we can change tomcat at this direction? What are
>> the timeline?
>>
>>
>> > 2006/5/5, Remy Maucherat <re...@apache.org>:
>> >> Henri Gomez wrote:
>> >> > May be not related, but did there is plan in TC 6.x to make
>> use at
>> >> > some time OSGI framework, like the one used in Eclipse and RCP
>> >> > applications ?
>> >> >
>> >> > I really like this concept and it seems a good candidate to
>> >> provide a
>> >> > modular kernel / micro-architecture.
>> >>
>> >> If we do that, what doesn't make it a Geronimo clone ? The
>> >> services that
>> >> are shipped by default, maybe ? ;)
>> >>
>> >> It also most likely make Tomcat more heavyweight, although I don't
>> >> know
>> >> whether or not it would make it more difficult to integrate.
>> >>
>> >> 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
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Core webapps and clustering
Posted by Henri Gomez <he...@gmail.com>.
Well we discuss for Tomcat 6, not Tomcat 5.5
Did there is some deadlines for Tomcat 6 ?
2006/5/5, Peter Rossbach <pr...@objektpark.de>:
> Am 05.05.2006 um 14:13 schrieb Henri Gomez:
>
> > Well being modular, components oriented won't be bad.
> >
> > It's not about cloning Geronimo, but allowing tomcat to get more and
> > more modules and extensions, like does Apache HTTPD
> >
> Good topic, small core with a lot of nice features...
> Tomcat as a plugin container. Sounds good to me!
>
> Smaller core with robust implementation are more straightforward
> embeddable.
> But how you think we can change tomcat at this direction? What are
> the timeline?
>
>
> > 2006/5/5, Remy Maucherat <re...@apache.org>:
> >> Henri Gomez wrote:
> >> > May be not related, but did there is plan in TC 6.x to make use at
> >> > some time OSGI framework, like the one used in Eclipse and RCP
> >> > applications ?
> >> >
> >> > I really like this concept and it seems a good candidate to
> >> provide a
> >> > modular kernel / micro-architecture.
> >>
> >> If we do that, what doesn't make it a Geronimo clone ? The
> >> services that
> >> are shipped by default, maybe ? ;)
> >>
> >> It also most likely make Tomcat more heavyweight, although I don't
> >> know
> >> whether or not it would make it more difficult to integrate.
> >>
> >> 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
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: Core webapps and clustering
Posted by Peter Rossbach <pr...@objektpark.de>.
Am 05.05.2006 um 14:13 schrieb Henri Gomez:
> Well being modular, components oriented won't be bad.
>
> It's not about cloning Geronimo, but allowing tomcat to get more and
> more modules and extensions, like does Apache HTTPD
>
Good topic, small core with a lot of nice features...
Tomcat as a plugin container. Sounds good to me!
Smaller core with robust implementation are more straightforward
embeddable.
But how you think we can change tomcat at this direction? What are
the timeline?
> 2006/5/5, Remy Maucherat <re...@apache.org>:
>> Henri Gomez wrote:
>> > May be not related, but did there is plan in TC 6.x to make use at
>> > some time OSGI framework, like the one used in Eclipse and RCP
>> > applications ?
>> >
>> > I really like this concept and it seems a good candidate to
>> provide a
>> > modular kernel / micro-architecture.
>>
>> If we do that, what doesn't make it a Geronimo clone ? The
>> services that
>> are shipped by default, maybe ? ;)
>>
>> It also most likely make Tomcat more heavyweight, although I don't
>> know
>> whether or not it would make it more difficult to integrate.
>>
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Core webapps and clustering
Posted by Jess Holle <je...@ptc.com>.
Ah, I think I misread your suggestion...
Having support for clean extension modules where appropriate would be a
fine thing for Tomcat.
[For instance, the ability to easily replace the form-based
authentication mechanism so as to be transparently compatible with basic
authentication while still supporting session-based authentication --
all in the same web app...]
Henri Gomez wrote:
> Well being modular, components oriented won't be bad.
>
> It's not about cloning Geronimo, but allowing tomcat to get more and
> more modules and extensions, like does Apache HTTPD
>
> 2006/5/5, Remy Maucherat <re...@apache.org>:
>> Henri Gomez wrote:
>> > May be not related, but did there is plan in TC 6.x to make use at
>> > some time OSGI framework, like the one used in Eclipse and RCP
>> > applications ?
>> >
>> > I really like this concept and it seems a good candidate to provide a
>> > modular kernel / micro-architecture.
>>
>> If we do that, what doesn't make it a Geronimo clone ? The services that
>> are shipped by default, maybe ? ;)
>>
>> It also most likely make Tomcat more heavyweight, although I don't know
>> whether or not it would make it more difficult to integrate.
>>
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Core webapps and clustering
Posted by Henri Gomez <he...@gmail.com>.
Well being modular, components oriented won't be bad.
It's not about cloning Geronimo, but allowing tomcat to get more and
more modules and extensions, like does Apache HTTPD
2006/5/5, Remy Maucherat <re...@apache.org>:
> Henri Gomez wrote:
> > May be not related, but did there is plan in TC 6.x to make use at
> > some time OSGI framework, like the one used in Eclipse and RCP
> > applications ?
> >
> > I really like this concept and it seems a good candidate to provide a
> > modular kernel / micro-architecture.
>
> If we do that, what doesn't make it a Geronimo clone ? The services that
> are shipped by default, maybe ? ;)
>
> It also most likely make Tomcat more heavyweight, although I don't know
> whether or not it would make it more difficult to integrate.
>
> 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
Re: Core webapps and clustering
Posted by Costin Manolache <co...@gmail.com>.
Yes, I plan to - but if you have nothing else to do :-), or this is a
blocker - please
look into it as well.
By 'optimizations' I mean:
- using dynamic mbeans ( are lighter, I don't think we gain much by
using model mbeans )
- lazy as much as possible
- improve MBeansSource, add saving - to read/write mlet-style config fragments
- check where we use JMX directly, add wrappers in modeler
- ( probably in sandbox ): implement a modeler version that doesn't
actually use JMX, for
lighter containers.
The tomcat code is using mostly Registry, so it should not require a
lot of changes. Obviously, most of the other APIs will be broken - but
we are in a separate package than commons.modeler, so it shouldn't be
a problem.
In any case - this should not block Tomcat6 release in any way, I'll
use a separate package
until it is stable, and it can get in a 6.1 or 6.2 if needed.
Costin
On 5/5/06, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > fix modeler
>
> BTW, do you plan to do the modeler optimizations, or should I plan to
> look into that ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Core webapps and clustering
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> fix modeler
BTW, do you plan to do the modeler optimizations, or should I plan to
look into that ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Core webapps and clustering
Posted by Costin Manolache <co...@gmail.com>.
As someone who used OSGI quite heavily in the past - I hope I'll
never have to touch it again :-), and certainly not in tomcat...
The _concept_ is good - components, dynamic binding, etc - but OSGI is
a framework like all others, it wants the whole world to change to it's model.
Sort of an Avalon :-).
Regarding modularity - we already have a lot of modularity in the code, with
plenty of hooks and components. What we don't have is deployment modularity -
ability to package and deploy modules like cluster, connectors, valves
in a consistent
way.
I also agree with Remy - we shouldn't be a Jboss/Geronimo clone - but
that doesn't
mean we shouldn't try to be more modular and support some of the good things in
osgi/jboss/geronimo.
JMX is currently the only API that I know that allows this without
beeing a 'you have to
do it only my way' framework like osgi or avalon ( and so many more ).
Well, they do
have a bit of that - but so far modeler ( with all its problems ) was
able to shield us from
most of it.
So all I'm proposing is to just make small adjustments - fix modeler,
small packaging changes,
use modeler/jmx more for component configuration ( and less server.xml
/ tomcat-specific formats ).
Costin
On 5/5/06, Jess Holle <je...@ptc.com> wrote:
> Remy Maucherat wrote:
> > Henri Gomez wrote:
> >> May be not related, but did there is plan in TC 6.x to make use at
> >> some time OSGI framework, like the one used in Eclipse and RCP
> >> applications ?
> >>
> >> I really like this concept and it seems a good candidate to provide a
> >> modular kernel / micro-architecture.
> > If we do that, what doesn't make it a Geronimo clone ? The services
> > that are shipped by default, maybe ? ;)
> >
> > It also most likely make Tomcat more heavyweight, although I don't
> > know whether or not it would make it more difficult to integrate.
> As someone who really wants to integrate Tomcat into a larger
> application soon (I had a working prototype for a while), I really don't
> want Eclipse or its RCP -- or anything of the sort -- in Tomcat.
>
> I like the fact that Tomcat is still relatively lightweight and brings
> relatively few extra libraries and version conflicts thereof into the
> picture. As long as I keep a few of the Apache libraries I use
> up-to-date, all is well (and probably would be otherwise -- it's just
> really easy to remove any possible issues by version matching).
>
> Future NetBeans versions may cease to embed Tomcat and embed the whole
> Glassfish thing instead, I don't know, but the embedding of Tomcat in
> current NetBeans releases is a perfect example of why no IDE's faddish
> RCP (Eclipse's, NetBeans', or new-sprocket-fad-xyz) should not make its
> way into Tomcat.
>
> [Sorry for any cynicism, but I've seen a rash of "wouldn't our simple,
> lightweight open source component X be oh so much better if we just
> stuck in an entire IDE framework underneath" knee jerks in open source
> communities ranging as far afield as jManage. Let's K.I.S.S!]
>
> --
> Jess Holle
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Core webapps and clustering
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Henri Gomez wrote:
>> May be not related, but did there is plan in TC 6.x to make use at
>> some time OSGI framework, like the one used in Eclipse and RCP
>> applications ?
>>
>> I really like this concept and it seems a good candidate to provide a
>> modular kernel / micro-architecture.
> If we do that, what doesn't make it a Geronimo clone ? The services
> that are shipped by default, maybe ? ;)
>
> It also most likely make Tomcat more heavyweight, although I don't
> know whether or not it would make it more difficult to integrate.
As someone who really wants to integrate Tomcat into a larger
application soon (I had a working prototype for a while), I really don't
want Eclipse or its RCP -- or anything of the sort -- in Tomcat.
I like the fact that Tomcat is still relatively lightweight and brings
relatively few extra libraries and version conflicts thereof into the
picture. As long as I keep a few of the Apache libraries I use
up-to-date, all is well (and probably would be otherwise -- it's just
really easy to remove any possible issues by version matching).
Future NetBeans versions may cease to embed Tomcat and embed the whole
Glassfish thing instead, I don't know, but the embedding of Tomcat in
current NetBeans releases is a perfect example of why no IDE's faddish
RCP (Eclipse's, NetBeans', or new-sprocket-fad-xyz) should not make its
way into Tomcat.
[Sorry for any cynicism, but I've seen a rash of "wouldn't our simple,
lightweight open source component X be oh so much better if we just
stuck in an entire IDE framework underneath" knee jerks in open source
communities ranging as far afield as jManage. Let's K.I.S.S!]
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Core webapps and clustering
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> May be not related, but did there is plan in TC 6.x to make use at
> some time OSGI framework, like the one used in Eclipse and RCP
> applications ?
>
> I really like this concept and it seems a good candidate to provide a
> modular kernel / micro-architecture.
If we do that, what doesn't make it a Geronimo clone ? The services that
are shipped by default, maybe ? ;)
It also most likely make Tomcat more heavyweight, although I don't know
whether or not it would make it more difficult to integrate.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Core webapps and clustering
Posted by Henri Gomez <he...@gmail.com>.
May be not related, but did there is plan in TC 6.x to make use at
some time OSGI framework, like the one used in Eclipse and RCP
applications ?
I really like this concept and it seems a good candidate to provide a
modular kernel / micro-architecture.
Regards
>2006/5/5, Bill Barker <wb...@wilshire.com>:
>
> "Costin Manolache" <co...@gmail.com> wrote in message
> news:96e4b5230605042307u57cb418n5c978de279535152@mail.gmail.com...
> > On 5/4/06, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
> >>
> >> 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
> >
> > That's what I am afraid - ha geting too 'intimate' with tomcat.
> >
> > "Easy to catch when it breaks" is not an argument - there are other
> > tools for that, like
> > tests and gump, and it doesn't matter where it is.
> >
>
> Of course any other ASF committer can do so as well, but I could set up a
> Gump build for "ha" (and even for "ha-test", if people don't mind the nags
> :).
>
> > 'ha' is a big enough feature to sit on its own, with proper deps and
> > all it needs, maybe
> > even independent release cycle.
> >
> >
> >>
> >> 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.
> >
> > Yes, and I assume you may need some adapters for each of them, etc.
> >
> >
> > Costin
> >
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Core webapps and clustering
Posted by Bill Barker <wb...@wilshire.com>.
"Costin Manolache" <co...@gmail.com> wrote in message
news:96e4b5230605042307u57cb418n5c978de279535152@mail.gmail.com...
> On 5/4/06, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
>>
>> 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
>
> That's what I am afraid - ha geting too 'intimate' with tomcat.
>
> "Easy to catch when it breaks" is not an argument - there are other
> tools for that, like
> tests and gump, and it doesn't matter where it is.
>
Of course any other ASF committer can do so as well, but I could set up a
Gump build for "ha" (and even for "ha-test", if people don't mind the nags
:).
> 'ha' is a big enough feature to sit on its own, with proper deps and
> all it needs, maybe
> even independent release cycle.
>
>
>>
>> 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.
>
> Yes, and I assume you may need some adapters for each of them, etc.
>
>
> Costin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Core webapps and clustering
Posted by Costin Manolache <co...@gmail.com>.
On 5/4/06, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
>
> 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
That's what I am afraid - ha geting too 'intimate' with tomcat.
"Easy to catch when it breaks" is not an argument - there are other
tools for that, like
tests and gump, and it doesn't matter where it is.
'ha' is a big enough feature to sit on its own, with proper deps and
all it needs, maybe
even independent release cycle.
>
> 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.
Yes, and I assume you may need some adapters for each of them, etc.
Costin
Re: Core webapps and clustering
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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 <co...@gmail.com> wrote:
>> On 5/4/06, Remy Maucherat <re...@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
>> 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
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Core webapps and clustering
Posted by Yoav Shapira <yo...@apache.org>.
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 <co...@gmail.com> wrote:
> On 5/4/06, Remy Maucherat <re...@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 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
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
Re: Core webapps and clustering
Posted by Costin Manolache <co...@gmail.com>.
On 5/4/06, Remy Maucherat <re...@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 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
Re: Core webapps and clustering
Posted by Remy Maucherat <re...@apache.org>.
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).
> 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).
> Other opionions ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Core webapps and clustering
Posted by Costin Manolache <co...@gmail.com>.
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.
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.
Other opionions ?
Costin
On 5/4/06, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > 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.
> > 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.
>
> Personally, all core modules are what is shipped in the default
> distribution (AFAIK, they have no dependencies). For example, for 5.5,
> the admin webapp is not a core module, but the old clustering is.
>
> Similarly, it seems server.xml configuration has justifications for
> clustering. I don't see the point of using a mini JBoss architecture.
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Core webapps and clustering
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> 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.
> 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.
Personally, all core modules are what is shipped in the default
distribution (AFAIK, they have no dependencies). For example, for 5.5,
the admin webapp is not a core module, but the old clustering is.
Similarly, it seems server.xml configuration has justifications for
clustering. I don't see the point of using a mini JBoss architecture.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Core webapps and clustering
Posted by Costin Manolache <co...@gmail.com>.
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.
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.
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
>
>
Re: Core webapps and clustering
Posted by Peter Rossbach <pr...@objektpark.de>.
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.
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