I hope I have understood what you meant by a monitor approach instead
of direct logging. If I am on the wrong track here, please correct me.
My understanding of a monitor approach is that each component in the
application is given a Monitor Impl, using Dependency Injection
mechanism. The component uses the monitor internally, and we could
plugin a Logging implementation or some other implementation, lets
say, notifying some listeners etc. etc.
If the above is correct, then LogCategory might still be useful. So
for example, if i had
public interface OpenEJBStartupMonitor{
public void onContainerCreate();
.....
}
public class LoggingOpenEJBStartupMonitor implements OpenEJBStartupMonitor{
public static final String NAME="OpenEJB.startup";
public void onContainerCreate(){
o.a.o.util.Logger.getInstance(NAME,"baseName").info("some info");
}
}
================================================
If we went with the LogCategory thing above, then the Monitor could be
implemented as:
public class LoggingOpenEJBStartupMonitor implements OpenEJBStartupMonitor{
public static final String NAME=LogCategory.OPENEJB_STARTUP;
public void onContainerCreate(){
o.a.o.util.Logger.getInstance(NAME,"baseName").info("some info");
}
}
================================================
On 8/4/07, David Jencks <[EMAIL PROTECTED]> wrote:
>
> On Aug 1, 2007, at 3:50 PM, David Blevins wrote:
>
> >
> > On Jul 31, 2007, at 7:23 PM, Karan Malhi wrote:
> >
> >>> I'm sorry if I scared you away from working on this.
> >> Not at all. I learnt a lot from this discussion and the link which
> >> you
> >> sent on the "LockFree HashMap" was invaluable. It was just that I
> >> wasn't sure on what needs to be done because of different types of
> >> logging frameworks and that I do not know enough to tell which
> >> logging
> >> framework is better. I was just waiting for a concrete decision on
> >> this topic and wanted to get this issue resolved so that I could
> >> start work on some documentation stuff.
> >
> > Well, we'll need to support log4j for Geronimo anyway, so we could
> > keep going with that for now. As long as we keep it hidden under
> > the Logger class we can always abstract it out later and support
> > both java.util.logging and log4j. But one change at a time, no
> > need to make this too big to solve now. The it'll be great to get
> > the hierarchical logging stuff in regardless of who is doing the
> > actual logging.
> >
> > On the note about making the logging code always do the i18n stuff
> > and assume you're passing in a message key and array of details,
> > that could work. There are a few places in the code where we need
> > to log something and throw an exception and have been doing stuff
> > like this:
> >
> > String msg = messages.format("config.noContainerFound",
> > d.getContainerId(), d.getEjbName());
> > logger.fatal(msg);
> > throw new OpenEJBException(msg);
> >
> > But I suppose if we had each logger return the formatted message it
> > could still be fine, such as:
> >
> > String msg = logger.fatal("config.noContainerFound",
> > d.getContainerId(), d.getEjbName());
> > throw new OpenEJBException(msg);
> >
> > Maybe even throw a method on the Logger to get the Messages
> > instance out so people could still use it to construct error
> > messages that aren't logged.
>
> Just in case you ever want to move to monitors instead of direct
> logging you might want to think about if and how this approach would
> work with monitors. I haven't thought about it yet myself, it might
> work great.
>
> thanks
> david jencks
>
> >
> > -David
> >
>
>
--
Karan Singh Malhi
