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 b
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 ot
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
I have been experiencing some problems with the geronimo.log file losing
data.
I tracked it down to be a combination of me customising
server-log4j.properties so that log4j.appender.FILE.append=false was
specified, and an EJB application that uses log4j. I have included my
observations belo
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
On Nov 10, 2004, at 3:49 AM, David Farb wrote:
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 w
On Nov 10, 2004, at 9:13 AM, Geir Magnusson Jr wrote:
What are the repercussions for existing users?
In the system plan you remove any references to appenders. In the
Log4jSerivce gbean you remove the root level attribute.
That't it.
-dain
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 c
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 o
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 an
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 reini
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 cl
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 fina
On Nov 8, 2004, at 10:49 PM, Bruce Snyder wrote:
Dain Sundstrom wrote:
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 follo
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 typ
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
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 r
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. Anywa
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"?
>
> -da
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 b
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
> in
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.
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 c
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 curre
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
25 matches
Mail list logo
