[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openejb-development
Subject:    Re: Logging strategy -- help!!
From:       "Mohammad Nour El-Din" <nour.mohammad () gmail ! com>
Date:       2007-06-24 11:54:44
Message-ID: f321b69f0706240454s3c7b86f5vb0b76329a8eb8a3b () mail ! gmail ! com
[Download RAW message or body]


Done, the manual is in ur personal gmail

On 6/24/07, Mohammad Nour El-Din <nour.mohammad@gmail.com> wrote:
>
> What ever u decide man I only give alternatives so we can make a good
> decision :-)
>
> On 6/24/07, Karan Malhi <karan.malhi@gmail.com > wrote:
> >
> > "but if you redefine an entity it will be deleted from the current
> > configuration and
> > then the new one is added"
> >
> > Thats cool, we keep the control :).
> >
> > Please do send the log4j manual, however, I am also tilting towards
> > java.util.logging so that we can remove the dep on log4j .
> >
> > On 6/24/07, Mohammad Nour El-Din <nour.mohammad@gmail.com> wrote:
> > > Well I may not following you guys here well, but we still can use
> > log4j to
> > > load configuration files, which is called reloading or
> > reconfiguration, and
> > > it works incrementally, I am as long as you defined new log4j
> > entities,
> > > these new entities will be added to the current log4j configuration,
> > but if
> > > you redefine an entity it will be deleted from the current
> > configuration and
> > > then the new one is added, and we can make sure that we define our own
> > > entities without affecting any other entities by prefixing our
> > entities with
> > > our package name org.apache.openejb for example. And BTW log4j now
> > supports
> > > xml configuration files which has more features than the normal
> > properties
> > > configuration files. Karan I will send you the log4j complete manual
> > so you
> > > can get a better idea how we can make our logging better.
> > >
> > > On 6/22/07, Karan Malhi <karan.malhi@gmail.com> wrote:
> > > >
> > > > Lovely!!
> > > >
> > > > This is definitely going to the wiki tomorrow. I will start one on
> > > > logging so that we build up stuff like this and then can extract a
> > > > nice documentation on logging.
> > > >
> > > > > As far as the caching in Logger.getInstance, I'm not sure we
> > really
> > > > > need it.  Presumably, log4j or java.util.Logging would do that
> > sort
> > > > > of thing -- but that's a hopeful guess.
> > > >
> > > > Yes, if we ask log4j or java.util.logging for a named logger, its
> > > > gonna gives us the same one if we had asked for it previously
> > > >
> > > >
> > > > > I created the ConfUtils.getConfResource utility to do that pattern
> > > > This one should defintely be used. We just need to ask it for a
> > > > resource and it does the magic, I saw how it was used for groups and
> > > > users.properties files. Nice!!
> > > >
> > > > >the "default" part in our file names and the
> > > > > lingering usage of the "conf" file extension is something that
> > needs
> > > > > to go bye-bye -- we should use properties for properties files and
> > > > > xml for xml files, etc.
> > > > Agree. There should be a pattern and it should be intuitive
> > > >
> > > > >It's fine to have such a thing, but I think it's
> > > > > being used in situations where a logging file *should* be
> > available.
> > > > This is where I think surefire broke it. Surefire was setting the
> > > > log4j.configuration property and I dont think it was setting it to
> > the
> > > > correct url.
> > > >
> > > > > -David
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Karan Malhi
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks
> > > - Mohammad Nour
> > >
> >
> >
> > --
> > Karan Malhi
> >
>
>
>
> --
> Thanks
> - Mohammad Nour




-- 
Thanks
- Mohammad Nour


[prev in list] [next in list] [prev in thread] [next in thread]