Re: Logging problems
The same can be achieved by setting DEBUG to INFO in log4j.logger.org.apache.geronimo.gbean.runtime.GBeanSingleReference=DEBUG. It was nice to be able to just add one line to debug a class, and not hunt down the threshold to change it... Though I agree that for a release the threshold should be set to INFO. Thanks Anita --- Dain Sundstrom [EMAIL PROTECTED] wrote: The log level is set to INFO: http://svn.apache.org/repos/asf/geronimo/server/trunk/assemblies/ geronimo-boilerplate-minimal/src/main/resources/var/log/server- log4j.properties -dain On Nov 10, 2006, at 6:33 PM, anita kulshreshtha wrote: The log file only contains environment info. No other information is being written. Thanks Anita __ __ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com
Re: Logging problems
The log level is set to INFO: http://svn.apache.org/repos/asf/geronimo/server/trunk/assemblies/ geronimo-boilerplate-minimal/src/main/resources/var/log/server- log4j.properties -dain On Nov 10, 2006, at 6:33 PM, anita kulshreshtha wrote: The log file only contains environment info. No other information is being written. Thanks Anita __ __ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com
Logging problems
The log file only contains environment info. No other information is being written. Thanks Anita Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com
Re: Logging problems
On Nov 5, 2004, at 1:29 PM, Dain Sundstrom wrote: Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. It is on of those problems that everyone had control which in effect gives no one control. I propose that we drop all of our gbeans that try to control Log4j and instead go to a single gbean that exposes the operations of LogManager, and a log4j.xml file (as a big string). The big string would be a persisted to somewhere like var/log4.xml. I just committed this. We now have var/log/*-log4j.properties to control the server, client and deployer logs. I'd appreciate any feed back quickly, as we are going to (try to) cut M3 tomorrow afternoon. -dain
Re: Logging problems
On Nov 10, 2004, at 12:29 AM, Dain Sundstrom wrote: On Nov 5, 2004, at 1:29 PM, Dain Sundstrom wrote: Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. It is on of those problems that everyone had control which in effect gives no one control. I propose that we drop all of our gbeans that try to control Log4j and instead go to a single gbean that exposes the operations of LogManager, and a log4j.xml file (as a big string). The big string would be a persisted to somewhere like var/log4.xml. I just committed this. We now have var/log/*-log4j.properties to control the server, client and deployer logs. I'd appreciate any feed back quickly, as we are going to (try to) cut M3 tomorrow afternoon. What are the repercussions for existing users? -dain -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[BULK] Re: Logging problems
Geir Magnusson Jr wrote: What are the repercussions for existing users? Speaking as one (1) existing user, it means I have to rip out things that were working (log4j.xml, system-plan.xml, and daily logs) and figure out how to get back to the state I was in before with the new code. About one day or so of work that I would rather not have to do right now.
Re: Logging problems
Dain Sundstrom wrote: On Nov 5, 2004, at 1:29 PM, Dain Sundstrom wrote: Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. It is on of those problems that everyone had control which in effect gives no one control. I propose that we drop all of our gbeans that try to control Log4j and instead go to a single gbean that exposes the operations of LogManager, and a log4j.xml file (as a big string). The big string would be a persisted to somewhere like var/log4.xml. I just committed this. We now have var/log/*-log4j.properties to control the server, client and deployer logs. I'd appreciate any feed back quickly, as we are going to (try to) cut M3 tomorrow afternoon. Any reason why the Log4J configs are using a properties file rather than XML? Bruce -- perl -e 'print unpack(u30,0G)[EMAIL PROTECTED]5R\F9EG)E=\$\!FFEI+F-O;0\`\`);' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: Logging problems
On Nov 10, 2004, at 10:34 AM, Bruce Snyder wrote:
Any reason why the Log4J configs are using a properties file rather
than XML?
We do use the ${property} replacement stuff in properties version, so
the log file location is relative to geronimo home, but if the xml
version supports that we could also be used. The code that loads the
configuration file supports both log4j xml and properties configs.
If you can get it to work with the xml version, feel free to convert
the files over (don't forget about the openejb ones).
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
Re: Logging problems
Thanks for the response. My comments are inline... On Nov 8, 2004, at 4:56 PM, Bruce Snyder wrote: Dain Sundstrom wrote: Either my email got lost in the flood or people are not too opinionated on logging. Anyway, does anyone have an opinion on point 2 Commons Log? I typed up quite a repsonse to your original message because I'm pretty opinionated about Commons Logging. My guess is that my response didn't make it to the list due to the outstanding network management (couresty of IBM GS) at my client. I'll try to make this brief. On Nov 5, 2004, at 1:29 PM, Dain Sundstrom wrote: After working with geronimo for a while, I am convinced our current logging solution was a bad idea (on my part :). There are several problems, so I'll try to categorize them. Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. It is on of those problems that everyone had control which in effect gives no one control. I propose that we drop all of our gbeans that try to control Log4j and instead go to a single gbean that exposes the operations of LogManager, and a log4j.xml file (as a big string). The big string would be a persisted to somewhere like var/log4.xml. I like the idea of a LogManager far better. It seems like this would protect the configuration better so that the rug won't be yanked out from under the logging framework. I'm not sure what you mean. Are you saying you like the idea of exposing LogManager as I proposed, or would you prefer something else? Commons Log If we make the above changes, we will only be using the org.apache.commons.logging.Log class from commons logging. The problem is to get this class we include a commons-logging jar into geronimo and this jar will carry a specific version number. This means that all applications are restricted to use the version of commons logging that we ship. I can think of two solutions this problem: ship only the org.apache.commons.logging.Log class with geronimo or repackage Log into a geronimo package (say org.apache.geronimo.logging.Log or org.apache.geronimo.logging.GLog). I don't have much of a preference for either of these solutions, but I feel we must address this problem. I'm not a big fan of Commons Logging. I'm not going into the diatribe I did in my lost message, but suffice it to say that it's one more layer I don't feel we need and I'd rather see it go away. Pick a single logging framework and use it. I vote against the use of Commons Logging. I've thought about this, but it would mean that our code is locked to a single log solution. This means that is someone wanted to swipe our transaction manager they would have to use log4j (for example). If we instead follow the example of mx4j and use a single simple log interface anyone would be able to adapt it to their logging system. I'm going to start working on the first proposal above, Log4j, as I think it is the least controversial. If you have any concerns about that one, please respond sooner rather then later. Please use only Log4J for all Geronimo logging. :) I wasn't going to go there. There are many people that think we should use java.util.logging. I personally think we should shoot for an IOC solution where the integrator of the components (the Kernel in our case) gets to choose the logging system. -dain
Re: Logging problems
Dain Sundstrom wrote: Thanks for the response. My comments are inline... On Nov 8, 2004, at 4:56 PM, Bruce Snyder wrote: Dain Sundstrom wrote: Either my email got lost in the flood or people are not too opinionated on logging. Anyway, does anyone have an opinion on point 2 Commons Log? I typed up quite a repsonse to your original message because I'm pretty opinionated about Commons Logging. My guess is that my response didn't make it to the list due to the outstanding network management (couresty of IBM GS) at my client. I'll try to make this brief. On Nov 5, 2004, at 1:29 PM, Dain Sundstrom wrote: After working with geronimo for a while, I am convinced our current logging solution was a bad idea (on my part :). There are several problems, so I'll try to categorize them. Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. It is on of those problems that everyone had control which in effect gives no one control. I propose that we drop all of our gbeans that try to control Log4j and instead go to a single gbean that exposes the operations of LogManager, and a log4j.xml file (as a big string). The big string would be a persisted to somewhere like var/log4.xml. I like the idea of a LogManager far better. It seems like this would protect the configuration better so that the rug won't be yanked out from under the logging framework. I'm not sure what you mean. Are you saying you like the idea of exposing LogManager as I proposed, or would you prefer something else? +1 for the LogManager class. Commons Log If we make the above changes, we will only be using the org.apache.commons.logging.Log class from commons logging. The problem is to get this class we include a commons-logging jar into geronimo and this jar will carry a specific version number. This means that all applications are restricted to use the version of commons logging that we ship. I can think of two solutions this problem: ship only the org.apache.commons.logging.Log class with geronimo or repackage Log into a geronimo package (say org.apache.geronimo.logging.Log or org.apache.geronimo.logging.GLog). I don't have much of a preference for either of these solutions, but I feel we must address this problem. I'm not a big fan of Commons Logging. I'm not going into the diatribe I did in my lost message, but suffice it to say that it's one more layer I don't feel we need and I'd rather see it go away. Pick a single logging framework and use it. I vote against the use of Commons Logging. I've thought about this, but it would mean that our code is locked to a single log solution. This means that is someone wanted to swipe our transaction manager they would have to use log4j (for example). If we instead follow the example of mx4j and use a single simple log interface anyone would be able to adapt it to their logging system. Build only what we need now, don't get hung up on all the possible what-if scenarios. Unless the what-if scenario is a driving factor. I haven't seen or been part of any discussions where architecture was driven by 'someone [who] wanted to swipe our tx mgr'. (Yes, I'm being a smart ass ;-)) I'm going to start working on the first proposal above, Log4j, as I think it is the least controversial. If you have any concerns about that one, please respond sooner rather then later. Please use only Log4J for all Geronimo logging. :) I wasn't going to go there. There are many people that think we should use java.util.logging. I personally think we should shoot for an IOC solution where the integrator of the components (the Kernel in our case) gets to choose the logging system. Tell me more about the IoC solution. I like the sound of it. But I definitely do *not* like the java.util.logging remark. Bruce -- perl -e 'print unpack(u30,0G)[EMAIL PROTECTED]5R\F9EG)E=\$\!FFEI+F-O;0\`\`);' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: Logging problems
Dain Sundstrom wrote:
As of an IoCish solution If we changed our components to declare a
dependency on a Log, the kernel can initialize a log and inject it into
the component. For example, instead of a component using this code to
get a log:
public class MyService {
private static final Log log = LogFactory.getLog(MyService.class);
public MyService() {
log.info(Blah);
}
}
You do this:
public class MyService {
private final Log log;
public MyService(Log log) {
this.log = log;
log.info(Blah);
}
}
The key here is code is not directly accessing a LogFactory. This
allows us to provide a log implementation that connects to any log
framework. It also allows the container add additional information to
the log events under the covers of the interface, such as the object
name of the component.
This seems really cool for GBeans. I have a vague concern the name in
the log file would be long (especially for 77 objects) making it hard to
read in vi but on the other hand it would be good to be able to
differentiate between different GBeans.
We would need to provide a solution though for things that aren't
GBeans. Perhaps a way that a GBean could create a child logger of the
one it had that it could inject into other things and recursively down?
--
Jeremy
[BULK] Re: Logging problems
Jeremy Boynes wrote: We would need to provide a solution though for things that aren't GBeans. Perhaps a way that a GBean could create a child logger of the one it had that it could inject into other things and recursively down? One of the benefits of the current scheme is that each class, whether it is a GBean or not, can have its logging level controlled individually. If all classes used in a GBean are controlled by the same logger, what happens to instances of classes shared by several GBeans? E.g. How do you control logging of o.a.g.security.ContextManager (assuming it had a log and you wanted to control it)? If the GBean controls logging, and only diagnostics from some non-GBean instance is wanted, is the only choice to get diagnostics from everything that GBean uses? For example, how would the logging in o.a.g.network.protocol.SocketProtocol be done? This class creats a new, controllable, log for each instance. And it is NOT a GBean.
Re: Logging problems
Either my email got lost in the flood or people are not too opinionated on logging. Anyway, does anyone have an opinion on point 2 Commons Log? -dain On Nov 5, 2004, at 1:29 PM, Dain Sundstrom wrote: After working with geronimo for a while, I am convinced our current logging solution was a bad idea (on my part :). There are several problems, so I'll try to categorize them. Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. It is on of those problems that everyone had control which in effect gives no one control. I propose that we drop all of our gbeans that try to control Log4j and instead go to a single gbean that exposes the operations of LogManager, and a log4j.xml file (as a big string). The big string would be a persisted to somewhere like var/log4.xml. Commons LogFactory Currently all of our code uses commons logging. The problem is how we obtain org.apache.commons.logging.Log implementation. This is most common code in to obtain a Log: private static Log log = LogFactory.getLog(MyGBean.class); The problem is the static LogFactory. As with log4j above anyone can come along an kick out our log factory. Also, the code we use to setup the LogFactory on geronimo boot is very very ugly and error prone. I propose we make Log log a GBean magic attributes, which means that is automatically available to all gbeans (just like class loader and kernel). If a gbean declares that it wants a log we will create and initialize a log. This will also let the kernel add additional information to log events such as gbean object name. Commons Log If we make the above changes, we will only be using the org.apache.commons.logging.Log class from commons logging. The problem is to get this class we include a commons-logging jar into geronimo and this jar will carry a specific version number. This means that all applications are restricted to use the version of commons logging that we ship. I can think of two solutions this problem: ship only the org.apache.commons.logging.Log class with geronimo or repackage Log into a geronimo package (say org.apache.geronimo.logging.Log or org.apache.geronimo.logging.GLog). I don't have much of a preference for either of these solutions, but I feel we must address this problem. I'm going to start working on the first proposal above, Log4j, as I think it is the least controversial. If you have any concerns about that one, please respond sooner rather then later. Thanks, -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
Re: Logging problems
Yes that is the one. -dain On Nov 8, 2004, at 4:03 PM, Aaron Mulder wrote: If you mean the bit about distribute 1 class or repackage, I vote repackage. Aaron On Mon, 8 Nov 2004, Dain Sundstrom wrote: Either my email got lost in the flood or people are not too opinionated on logging. Anyway, does anyone have an opinion on point 2 Commons Log? -dain On Nov 5, 2004, at 1:29 PM, Dain Sundstrom wrote: After working with geronimo for a while, I am convinced our current logging solution was a bad idea (on my part :). There are several problems, so I'll try to categorize them. Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. It is on of those problems that everyone had control which in effect gives no one control. I propose that we drop all of our gbeans that try to control Log4j and instead go to a single gbean that exposes the operations of LogManager, and a log4j.xml file (as a big string). The big string would be a persisted to somewhere like var/log4.xml. Commons LogFactory Currently all of our code uses commons logging. The problem is how we obtain org.apache.commons.logging.Log implementation. This is most common code in to obtain a Log: private static Log log = LogFactory.getLog(MyGBean.class); The problem is the static LogFactory. As with log4j above anyone can come along an kick out our log factory. Also, the code we use to setup the LogFactory on geronimo boot is very very ugly and error prone. I propose we make Log log a GBean magic attributes, which means that is automatically available to all gbeans (just like class loader and kernel). If a gbean declares that it wants a log we will create and initialize a log. This will also let the kernel add additional information to log events such as gbean object name. Commons Log If we make the above changes, we will only be using the org.apache.commons.logging.Log class from commons logging. The problem is to get this class we include a commons-logging jar into geronimo and this jar will carry a specific version number. This means that all applications are restricted to use the version of commons logging that we ship. I can think of two solutions this problem: ship only the org.apache.commons.logging.Log class with geronimo or repackage Log into a geronimo package (say org.apache.geronimo.logging.Log or org.apache.geronimo.logging.GLog). I don't have much of a preference for either of these solutions, but I feel we must address this problem. I'm going to start working on the first proposal above, Log4j, as I think it is the least controversial. If you have any concerns about that one, please respond sooner rather then later. Thanks, -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
Logging problems
After working with geronimo for a while, I am convinced our current logging solution was a bad idea (on my part :). There are several problems, so I'll try to categorize them. Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. It is on of those problems that everyone had control which in effect gives no one control. I propose that we drop all of our gbeans that try to control Log4j and instead go to a single gbean that exposes the operations of LogManager, and a log4j.xml file (as a big string). The big string would be a persisted to somewhere like var/log4.xml. Commons LogFactory Currently all of our code uses commons logging. The problem is how we obtain org.apache.commons.logging.Log implementation. This is most common code in to obtain a Log: private static Log log = LogFactory.getLog(MyGBean.class); The problem is the static LogFactory. As with log4j above anyone can come along an kick out our log factory. Also, the code we use to setup the LogFactory on geronimo boot is very very ugly and error prone. I propose we make Log log a GBean magic attributes, which means that is automatically available to all gbeans (just like class loader and kernel). If a gbean declares that it wants a log we will create and initialize a log. This will also let the kernel add additional information to log events such as gbean object name. Commons Log If we make the above changes, we will only be using the org.apache.commons.logging.Log class from commons logging. The problem is to get this class we include a commons-logging jar into geronimo and this jar will carry a specific version number. This means that all applications are restricted to use the version of commons logging that we ship. I can think of two solutions this problem: ship only the org.apache.commons.logging.Log class with geronimo or repackage Log into a geronimo package (say org.apache.geronimo.logging.Log or org.apache.geronimo.logging.GLog). I don't have much of a preference for either of these solutions, but I feel we must address this problem. I'm going to start working on the first proposal above, Log4j, as I think it is the least controversial. If you have any concerns about that one, please respond sooner rather then later. Thanks, -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
Re: Logging problems
FYI, In Axis we have our own LogFactory (http://cvs.apache.org/viewcvs.cgi/ws-axis/java/src/org/apache/axis/components/logger/LogFactory.java). -- dims On Fri, 5 Nov 2004 11:29:07 -0800, Dain Sundstrom [EMAIL PROTECTED] wrote: After working with geronimo for a while, I am convinced our current logging solution was a bad idea (on my part :). There are several problems, so I'll try to categorize them. Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. It is on of those problems that everyone had control which in effect gives no one control. I propose that we drop all of our gbeans that try to control Log4j and instead go to a single gbean that exposes the operations of LogManager, and a log4j.xml file (as a big string). The big string would be a persisted to somewhere like var/log4.xml. Commons LogFactory Currently all of our code uses commons logging. The problem is how we obtain org.apache.commons.logging.Log implementation. This is most common code in to obtain a Log: private static Log log = LogFactory.getLog(MyGBean.class); The problem is the static LogFactory. As with log4j above anyone can come along an kick out our log factory. Also, the code we use to setup the LogFactory on geronimo boot is very very ugly and error prone. I propose we make Log log a GBean magic attributes, which means that is automatically available to all gbeans (just like class loader and kernel). If a gbean declares that it wants a log we will create and initialize a log. This will also let the kernel add additional information to log events such as gbean object name. Commons Log If we make the above changes, we will only be using the org.apache.commons.logging.Log class from commons logging. The problem is to get this class we include a commons-logging jar into geronimo and this jar will carry a specific version number. This means that all applications are restricted to use the version of commons logging that we ship. I can think of two solutions this problem: ship only the org.apache.commons.logging.Log class with geronimo or repackage Log into a geronimo package (say org.apache.geronimo.logging.Log or org.apache.geronimo.logging.GLog). I don't have much of a preference for either of these solutions, but I feel we must address this problem. I'm going to start working on the first proposal above, Log4j, as I think it is the least controversial. If you have any concerns about that one, please respond sooner rather then later. Thanks, -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Logging problems
Dain Sundstrom wrote: --- Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. This would probably fix Jira Geronimo issue 287. It appears that log4j is re-initialized several times during Geronimo operations.
Re: Logging problems
Exactly, we are bound to either break the axis one, or have axis break ours. I think the best solution is to simply avoid the static factory pattern all together. -dain On Nov 5, 2004, at 12:00 PM, Davanum Srinivas wrote: FYI, In Axis we have our own LogFactory (http://cvs.apache.org/viewcvs.cgi/ws-axis/java/src/org/apache/axis/ components/logger/LogFactory.java). -- dims On Fri, 5 Nov 2004 11:29:07 -0800, Dain Sundstrom [EMAIL PROTECTED] wrote: After working with geronimo for a while, I am convinced our current logging solution was a bad idea (on my part :). There are several problems, so I'll try to categorize them. Log4j GBeans Our current log4j gbeans attempt to control the creation of log objects, priories... basically the log4j configuration. The problem I have found is any application can come along and reset the current log4j configuration and reinitialize the system. I do not believe there is any way to prevent this. It is on of those problems that everyone had control which in effect gives no one control. I propose that we drop all of our gbeans that try to control Log4j and instead go to a single gbean that exposes the operations of LogManager, and a log4j.xml file (as a big string). The big string would be a persisted to somewhere like var/log4.xml. Commons LogFactory Currently all of our code uses commons logging. The problem is how we obtain org.apache.commons.logging.Log implementation. This is most common code in to obtain a Log: private static Log log = LogFactory.getLog(MyGBean.class); The problem is the static LogFactory. As with log4j above anyone can come along an kick out our log factory. Also, the code we use to setup the LogFactory on geronimo boot is very very ugly and error prone. I propose we make Log log a GBean magic attributes, which means that is automatically available to all gbeans (just like class loader and kernel). If a gbean declares that it wants a log we will create and initialize a log. This will also let the kernel add additional information to log events such as gbean object name. Commons Log If we make the above changes, we will only be using the org.apache.commons.logging.Log class from commons logging. The problem is to get this class we include a commons-logging jar into geronimo and this jar will carry a specific version number. This means that all applications are restricted to use the version of commons logging that we ship. I can think of two solutions this problem: ship only the org.apache.commons.logging.Log class with geronimo or repackage Log into a geronimo package (say org.apache.geronimo.logging.Log or org.apache.geronimo.logging.GLog). I don't have much of a preference for either of these solutions, but I feel we must address this problem. I'm going to start working on the first proposal above, Log4j, as I think it is the least controversial. If you have any concerns about that one, please respond sooner rather then later. Thanks, -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Logging problems
Dain Sundstrom wrote: --- I propose we make Log log a GBean magic attributes, which means that is automatically available to all gbeans (just like class loader and kernel). If a gbean declares that it wants a log we will create and initialize a log. This will also let the kernel add additional information to log events such as gbean object name. What happens to classes that use logging that are NOT GBeans? They currently use the factory pattern.
