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/
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
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 <[EMAIL PRO
Well we discuss for Tomcat 6, not Tomcat 5.5
Did there is some deadlines for Tomcat 6 ?
2006/5/5, Peter Rossbach <[EMAIL PROTECTED]>:
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
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 c
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 st
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
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 <[EMAIL PROTECTED]>:
Henri Gomez wrote:
> May be not related, but did there is plan in TC 6.x t
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 doe
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
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 <[EMAIL PROT
"Costin Manolache" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 5/4/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> 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 o
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
On 5/4/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> 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'
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
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
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.x
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 distr
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 'defaul
Costin Manolache wrote:
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
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 e
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.getClass
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 co
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
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
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, co
27 matches
Mail list logo
