You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by co...@covalent.net on 2002/07/30 04:06:44 UTC
[5.0] mbean-names
My comments on mbean-names.html, and possible improvements for
5.0:
The biggest problem is the representation of load-balanced tomcats.
This is not covered in the current model, and it should ( even
if in most cases the attribute will no be used :-)
In JSR77 terms, we need to add 'node' attributes ( and remove
the comment that tomcat supports a single node, which is not
true ).
As mentioned in a previous thread, the User stuff will be
separated, and tomcat should just have a reference to the
mbean implementing UserDatabase.
Same should happen for Log, assuming we get the commons-logging
to support JMX and add a wrapper for JDK1.4 ( for log4j
we should just use their mbean ). I assume we all agree on
moving to commons-logging as API, and keeping the old Logging
interface only for backward compat.
The 'sequence' is a great idea - but it should be optional
and maybe a simple attribute, not part of the name. Some modules
are position-independent, and some only need apache-hook hints
( 'first', at-begin, at-end, last, etc ).
Another issue is the ordering of the attributes - either
left-to-right or reverse, but consistent ( i.e.
service=, host=, path=, type=, sequence= - the name
should be similar with a JNDI name, especially if we plan
to support directory-based config ).
I do have a big problem with the concept of 'service', even
if it may be usefull in some cases I thing the 'default' should
be easier. So I would propose to combine the concept of lb-group
and that of service.
In other words the service name will match the jk 'group' attribute.
One tomcat node can be part of multiple groups, and one group
may have multiple nodes. Each webapp is deployed on exactly one
group. That supports ( AFAIK ) all possible use cases for lb
deployment.
Also related with lb, the 'node id' is very important and should
be included in each name ( after 'service' ).
>From 3.3 point of view ( i.e. support of 3.3 interceptors in 5.0 ) -
the Listener is very close in concept and it can use the same type,
while Valve and 3.3/jk Handlers are also similar. The only problem
is that in 3.3 and jk we can have multiple 'chains' ( in 4.0 there is
only one request-processing chain ). This will probably have to be
part of the name for the other chains.
Finally - I think we should try to avoid making a too strong connection
between internal implementation names and JMX names. And maybe
use 'tomcatType' or 'tcType' instead of 'type' - even JSR77 is
avoiding type.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] mbean-names [logging]
Posted by Patrick Luby <pa...@sun.com>.
Bob,
Bob Herrmann wrote:
>
> Just so I get an idea of the scale of changes.. Tomcat has a lot of code
> that uses a pattern like this;
>
> private void log(String message) {
> Logger logger = null;
> if (container != null)
> logger = container.getLogger();
> if (logger != null) {
> logger.log(getName() + "[" + container.getName() + "]: "
> + message);
> } else {
> String containerName = null;
> if (container != null)
> containerName = container.getName();
>
> System.out.println(getName() + "[" + containerName
> + "]: " + message);
> }
> }
>
> Would the 5.0 logging look more like this ?? ( I am just changing the
> System.out calls to instead defer to a commons-logging logger. )
>
> private void log(String message) {
> Logger logger = null;
>
> if (container != null)
> logger = container.getLogger();
>
> if (logger != null) {
> logger.log(getName() + "[" + container.getName() + "]: "
> + message);
> } else {
> String containerName = null;
> if (container != null)
> containerName = container.getName();
>
> //import org.apache.commons.logging.Log;
> //import org.apache.commons.logging.LogFactory;
>
> Log log = LogFactory.getLog( containerName );
>
> log.info( getName() + "[" + containerName
> + "]: " + message);
> }
> }
>
> (Note that commons-logging is going to record the log method (and not
> the caller's) method in the logging output)
>
+1 for this type of change. Even though commons-logging will record the
log method, IMHO this is an incremental improvement over using
System.out directly.
Patrick
--
________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] mbean-names [logging]
Posted by Bob Herrmann <bo...@jadn.com>.
On Mon, 2002-07-29 at 23:04, costinm@covalent.net wrote:
> On 29 Jul 2002, Bob Herrmann wrote:
>
> >
> > > Same should happen for Log, assuming we get the commons-logging
> > > to support JMX and add a wrapper for JDK1.4 ( for log4j
> > > we should just use their mbean ). I assume we all agree on
> > > moving to commons-logging as API, and keeping the old Logging
> > > interface only for backward compat.
> >
> > I just reviewed the tomcat 5.0 proposal, and I didn't notice anything
> > about logging changing in 5.0
> >
> > Just so I understand this, the current use of <Logger .../> element
> > "will/should/encouraged to" disappear in 5.0 and instead modules will
> > directly call the commons-logging interface? So if I want to log a
> > particular context/webapp or Host or Engine, I will have to figure out
> > what "domain" it logged to and get the underlying logging system (log4j,
> > JDK1.4, logkit) to filter out the webapp/Host/Engine I am interested in?
>
> This has been discussed separately, and AFAIK nobody objected to the
> idea of using commons-logging in 5.0. It was proposed and accepted
> officially for jk and coyote, and even if no formal vote was made
> for 5.0 and jasper2 I assume it'll get a majority.
>
> The <Logger> element and interfaces will not disapear - it'll remain
> for backward compat, just like the realm stuff. I assume the attributes
> will be passed to the commons-logging impl.
Just so I get an idea of the scale of changes.. Tomcat has a lot of code
that uses a pattern like this;
private void log(String message) {
Logger logger = null;
if (container != null)
logger = container.getLogger();
if (logger != null) {
logger.log(getName() + "[" + container.getName() + "]: "
+ message);
} else {
String containerName = null;
if (container != null)
containerName = container.getName();
System.out.println(getName() + "[" + containerName
+ "]: " + message);
}
}
Would the 5.0 logging look more like this ?? ( I am just changing the
System.out calls to instead defer to a commons-logging logger. )
private void log(String message) {
Logger logger = null;
if (container != null)
logger = container.getLogger();
if (logger != null) {
logger.log(getName() + "[" + container.getName() + "]: "
+ message);
} else {
String containerName = null;
if (container != null)
containerName = container.getName();
//import org.apache.commons.logging.Log;
//import org.apache.commons.logging.LogFactory;
Log log = LogFactory.getLog( containerName );
log.info( getName() + "[" + containerName
+ "]: " + message);
}
}
(Note that commons-logging is going to record the log method (and not
the caller's) method in the logging output)
>
> My understanding is that we'll gradually start using commons-logging
> inside tomcat/jasper. So all components will use commons-logging,
> and we'll have a mechanism to configure it per/webapplication ( or
> host, engine ). Ceki already has some support in log4j to support
> this, and we can try to do something similar in the jdk1.4 wrapper.
>
> The details for configuration are not yet clear - it depends a lot
> on the overal scheme and I assume on what we do for users, since the
> problem is very similar.
ok.
>
> I like Craig's proposal for separate Users - and the Log can work the
> same. If you have ideas/sugestions about how to manage the loggers -
> please post them. 5.0 is still at an early stage, but those things
> should be discussed sooner rather than later.
>
> Of course, that's my understanding - I may be wrong.
>
>
> Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] mbean-names
Posted by co...@covalent.net.
On 29 Jul 2002, Bob Herrmann wrote:
>
> > Same should happen for Log, assuming we get the commons-logging
> > to support JMX and add a wrapper for JDK1.4 ( for log4j
> > we should just use their mbean ). I assume we all agree on
> > moving to commons-logging as API, and keeping the old Logging
> > interface only for backward compat.
>
> I just reviewed the tomcat 5.0 proposal, and I didn't notice anything
> about logging changing in 5.0
>
> Just so I understand this, the current use of <Logger .../> element
> "will/should/encouraged to" disappear in 5.0 and instead modules will
> directly call the commons-logging interface? So if I want to log a
> particular context/webapp or Host or Engine, I will have to figure out
> what "domain" it logged to and get the underlying logging system (log4j,
> JDK1.4, logkit) to filter out the webapp/Host/Engine I am interested in?
This has been discussed separately, and AFAIK nobody objected to the
idea of using commons-logging in 5.0. It was proposed and accepted
officially for jk and coyote, and even if no formal vote was made
for 5.0 and jasper2 I assume it'll get a majority.
The <Logger> element and interfaces will not disapear - it'll remain
for backward compat, just like the realm stuff. I assume the attributes
will be passed to the commons-logging impl.
My understanding is that we'll gradually start using commons-logging
inside tomcat/jasper. So all components will use commons-logging,
and we'll have a mechanism to configure it per/webapplication ( or
host, engine ). Ceki already has some support in log4j to support
this, and we can try to do something similar in the jdk1.4 wrapper.
The details for configuration are not yet clear - it depends a lot
on the overal scheme and I assume on what we do for users, since the
problem is very similar.
I like Craig's proposal for separate Users - and the Log can work the
same. If you have ideas/sugestions about how to manage the loggers -
please post them. 5.0 is still at an early stage, but those things
should be discussed sooner rather than later.
Of course, that's my understanding - I may be wrong.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] mbean-names
Posted by Bob Herrmann <bo...@jadn.com>.
> Same should happen for Log, assuming we get the commons-logging
> to support JMX and add a wrapper for JDK1.4 ( for log4j
> we should just use their mbean ). I assume we all agree on
> moving to commons-logging as API, and keeping the old Logging
> interface only for backward compat.
I just reviewed the tomcat 5.0 proposal, and I didn't notice anything
about logging changing in 5.0
Just so I understand this, the current use of <Logger .../> element
"will/should/encouraged to" disappear in 5.0 and instead modules will
directly call the commons-logging interface? So if I want to log a
particular context/webapp or Host or Engine, I will have to figure out
what "domain" it logged to and get the underlying logging system (log4j,
JDK1.4, logkit) to filter out the webapp/Host/Engine I am interested in?
Cheers,
-bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] mbean-names
Posted by Bob Herrmann <bo...@jadn.com>.
> Same should happen for Log, assuming we get the commons-logging
> to support JMX and add a wrapper for JDK1.4 ( for log4j
> we should just use their mbean ). I assume we all agree on
> moving to commons-logging as API, and keeping the old Logging
> interface only for backward compat.
I just reviewed the tomcat 5.0 proposal, and I didn't notice anything
about logging changing in 5.0
Just so I understand this, the current use of <Logger .../> element
"will/should/encouraged to" disappear in 5.0 and instead modules will
directly call the commons-logging interface? So if I want to log a
particular context/webapp or Host or Engine, I will have to figure out
what "domain" it logged to and get the underlying logging system (log4j,
JDK1.4, logkit) to filter out the webapp/Host/Engine I am interested in?
Cheers,
-bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>