This is driving me crazy. I cannot for the life of me work out how to
configure 'default' logging for a simple test.
Let's pick an example - simple-singleton.
How to I override console logging for that? I just want to debug from
'org.apache.openejb' and up. How do I do it?
No matter what I try
did you try logging.level.OpenEJB=FINE?
- Romain
2012/7/5 AndyG andy.gumbre...@orprovision.com
This is driving me crazy. I cannot for the life of me work out how to
configure 'default' logging for a simple test.
Let's pick an example - simple-singleton.
How to I override console logging
than info? What do I need to change, create or modify to get it do this
without adding log4j?
Please, an idiots guide would be nice.
--
View this message in context:
http://openejb.979440.n4.nabble.com/Logging-documentation-tp4656042p4656045.html
Sent from the OpenEJB Dev mailing list archive
this
without adding log4j?
Please, an idiots guide would be nice.
--
View this message in context:
http://openejb.979440.n4.nabble.com/Logging-documentation-tp4656042p4656045.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Thanks dude! That does the trick :-)
--
View this message in context:
http://openejb.979440.n4.nabble.com/Logging-documentation-tp4656042p4656047.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Isnt it the case on trunk?
-- Message transféré --
De : David Blevins (Created) (JIRA) j...@apache.org
Date : 31 janv. 2012 01:19
Objet : [jira] [Created] (TOMEE-133) TomEE logs/openejb.log should be
merged with the rest of Tomcat logging
À : comm...@openejb.apache.org
TomEE logs
folks, we face a very similar problem in DeltaSpike, OWB and MyFaces (OpenJPA
has it's own logging as well).
I'm not sure if this doesn't qualify to build a commons-logging-3.0 or so :)
LieGrue,
strub
- Original Message -
From: David Blevins david.blev...@gmail.com
To: dev
, we face a very similar problem in DeltaSpike, OWB and MyFaces
(OpenJPA has it's own logging as well).
I'm not sure if this doesn't qualify to build a commons-logging-3.0 or so :)
LieGrue,
strub
- Original Message -
From: David Blevins david.blev...@gmail.com
To: d...@openejb.ap...
I will find time for a
descriptive
article on how I am successfully using OpenEJB in a real world high volume
AOI scenario!!!
Andy.
--
View this message in context:
http://openejb.979440.n4.nabble.com/Logging-tp4318587p4332775.html
Sent from the OpenEJB Dev mailing list archive
there'd still be a step for
adding it. Two possible solutions there:
1) Find some way to easily add log4j either via another server binary or via
network install at startup.
2) Find a way to easily get the log output of JULI to match the existing
logging so you could switch.
I am curious
normally the default logging should simply be a JUL logging.
the only modification is if you don't override OpenEJB root loggers
(OpenEJB, Transaction...) the handler (=appender) is changed to look like
the old noe in embedded mode (=not standalone tomee).
As David said he restored the old log4j
On Jan 26, 2012, at 10:08 AM, Romain Manni-Bucau wrote:
normally the default logging should simply be a JUL logging.
the only modification is if you don't override OpenEJB root loggers
(OpenEJB, Transaction...) the handler (=appender) is changed to look like
the old noe in embedded mode
On Jan 26, 2012, at 12:47 PM, David Blevins wrote:
On Jan 26, 2012, at 10:08 AM, Romain Manni-Bucau wrote:
normally the default logging should simply be a JUL logging.
the only modification is if you don't override OpenEJB root loggers
(OpenEJB, Transaction...) the handler (=appender
in a real world high volume
AOI scenario!!!
Andy.
--
View this message in context:
http://openejb.979440.n4.nabble.com/Logging-tp4318587p4332775.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
So how about some info about how to configure the 'new' logging - I don't
really care what logging is used as long as when it changes there is a
little info for those using the 'old' logging.
I just built and dropped in the jars onto my standalone test server (which I
do at least once a week
Thanks for the gentle but firm email :) Just the right balance.
On Jan 25, 2012, at 2:36 AM, AndyG wrote:
So how about some info about how to configure the 'new' logging - I don't
really care what logging is used as long as when it changes there is a
little info for those using the 'old
and removing our default configs (jul
+
lo4j)? These confs sucks since it is never what the user wants and it
hides
a big part of the whole logging.
Ill have a try tonight, shout if you see any issue with it.
So how does one re enable the old logging if they happened to like it?
Looks
Hi,
What about using jul by default and removing our default configs (jul +
lo4j)? These confs sucks since it is never what the user wants and it hides
a big part of the whole logging.
Ill have a try tonight, shout if you see any issue with it.
- Romain
On Jan 22, 2012, at 8:35 AM, Romain Manni-Bucau wrote:
Hi,
What about using jul by default and removing our default configs (jul +
lo4j)? These confs sucks since it is never what the user wants and it hides
a big part of the whole logging.
Ill have a try tonight, shout if you see any
logging.
Ill have a try tonight, shout if you see any issue with it.
So how does one re enable the old logging if they happened to like it?
Looks like it's been removed.
I'm happy to see change and getting some ability to better work with JULI is
great. I really would like to maintain some
the user wants and it hides
a big part of the whole logging.
Ill have a try tonight, shout if you see any issue with it.
So how does one re enable the old logging if they happened to like it?
Looks like it's been removed.
I'm happy to see change and getting some ability to better work
(jul +
lo4j)? These confs sucks since it is never what the user wants and it hides
a big part of the whole logging.
Ill have a try tonight, shout if you see any issue with it.
So how does one re enable the old logging if they happened to like it?
Looks like it's been removed.
I'm happy
Does anyone know what has changed on the logging front to break logging -
Using standalone server. Does not even create the 'openejb.log' anymore?
--
View this message in context:
http://openejb.979440.n4.nabble.com/Logging-broken-tp4164685p4164685.html
Sent from the OpenEJB Dev mailing list
. Check for slf4j and use,
5. Else use either log4j or JUL.
--
View this message in context:
http://openejb.979440.n4.nabble.com/Logging-broken-tp4164685p4165079.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
if not overridden,
3. Else, check for JUL and configure if not overridden,
4. Check for slf4j and use,
5. Else use either log4j or JUL.
--
View this message in context:
http://openejb.979440.n4.nabble.com/Logging-broken-tp4164685p4165079.html
Sent from the OpenEJB Dev mailing list archive
Hi.
While trying to delegate logging to our internal logger while using OpenEJB
the embedded way I saw 2 issues in the code of 3.1.4
1. Issue:
At ReadDescriptors.java
there is a System out that should be replaced by normal logging:
System.out.println(FOO moduleName = + moduleName);
2. Issue
...@markuslutum.de
Hi.
While trying to delegate logging to our internal logger while using OpenEJB
the embedded way I saw 2 issues in the code of 3.1.4
1. Issue:
At ReadDescriptors.java
there is a System out that should be replaced by normal logging:
System.out.println(FOO moduleName = + moduleName);
2
1) isn't it fixed on the repo? (trunk + 3.2 branch)
2) i'm not opposed to it ;)
- Romain
2011/7/6 mclu m...@markuslutum.de
Hi.
While trying to delegate logging to our internal logger while using OpenEJB
the embedded way I saw 2 issues in the code of 3.1.4
1. Issue
to changes made as part of OPENEJB-918
which changed how logging is made. I reopened the bug and provided
some more details. I also attached a patch to the bug that fixes these
problems. I was hoping somebody could apply the patch and publish a
new snapshot of OpenEJB.
Thanks,
Jarek
:53)
at org.apache.openejb.util.Logger.formatMessage(Logger.java:
185)
at org.apache.openejb.util.Logger.error(Logger.java:276)
I tracked down the problem to changes made as part of OPENEJB-918
which changed how logging is made. I reopened the bug and provided
some more details. I
Hi,
I was investigating GERONIMO-3354. Found that the exception
getting thrown was due to an XAResource getting passed to the the
geronimo transaction manager instead of a NamedXAResource .So I made
this change. Since I am a novice in this area, I had a chat with Dain.
The main points of
On 8/21/07, Karan Malhi [EMAIL PROTECTED] wrote:
Is there a way where I can get rid of my previous patch from the issue?
Yes, there is. Let us know what the patch you're at and it will be wiped out.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
https://issues.apache.org/jira/browse/OPENEJB-667
Thanks !!
On 8/21/07, Jacek Laskowski [EMAIL PROTECTED] wrote:
On 8/21/07, Karan Malhi [EMAIL PROTECTED] wrote:
Is there a way where I can get rid of my previous patch from the issue?
Yes, there is. Let us know what the patch you're at and
Yes,
I remember posting multiple patches for a couple of issues when I
joined this project ;).
On 8/21/07, Jacek Laskowski [EMAIL PROTECTED] wrote:
On 8/21/07, Karan Malhi [EMAIL PROTECTED] wrote:
https://issues.apache.org/jira/browse/OPENEJB-667
Done (I was worried there might've been more
Here is what could be added to the getLogger(String child)
method
public Logger getLogger(String child){
Logger child = // create child logger here;
this.debug(Created Logger + child.logCategory.getName(),
this.baseName);
}
Oops!! the code should be:
public Logger
and the
DirectoryMonitor you wrote for that). I could not find that code
depicting this behaviour in OpenEJB for Logging.
Sorry, your option 3 is what i meant -- on startup when we read the
config files.
I'm attempting to document some of these behaviors here:
http://svn.apache.org/repos/asf
be useful in
troubleshooting any logging issues. So where would we put this diff
feature? I was thinking , it could be a part of WebAdmin.
What do you guys think about the above?
--
Karan Singh Malhi
not all Logger Categories need to be
defined in log4j configuration because the level and appenders can be
inherited from parent Loggers, the diff tool could be useful in
troubleshooting any logging issues. So where would we put this diff
feature? I was thinking , it could be a part of WebAdmin.
We
We should just go with logging.properties for the one that will be
squirted into conf/ directory for the standalone server. For
anything embedded (could be more than just tests) we could just go
simple and call it embedded.logging.properties.
I'll make the changes
For the embedded one, we'd
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
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
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
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);
This is a nice idea !! .
--
Karan Singh Malhi
, it is looked up in the parent package and so on.
On 7/27/07, David Jencks [EMAIL PROTECTED] wrote:
On Jul 27, 2007, at 4:20 PM, Karan Malhi wrote:
So I have re-written logging using java.util.Logging.
Is there general agreement this is a good idea? I have yet to talk
in person to anyone who
So I have re-written logging using java.util.Logging. There are some issues
which are blockers right now
1. The logging levels are different between log4j and java.util.logging. Can
anybody suggest how these should be mapped
2. Most of the logging being done right now is not using
On Jul 27, 2007, at 4:20 PM, Karan Malhi wrote:
So I have re-written logging using java.util.Logging.
Is there general agreement this is a good idea? I have yet to talk
in person to anyone who likes java.util.Logging.
There are some issues
which are blockers right now
1. The logging
file of a
sub-package, it is looked up in the parent package and so on.
On 7/27/07, David Jencks [EMAIL PROTECTED] wrote:
On Jul 27, 2007, at 4:20 PM, Karan Malhi wrote:
So I have re-written logging using java.util.Logging.
Is there general agreement this is a good idea? I have yet to talk
of finding a property and
just caching that property. This will make sure we dont hit the same
properties file twice.
On 6/21/07, David Blevins [EMAIL PROTECTED] wrote:
There have been a couple things I thought would be neat additions for
the i18n side of our logging code. Basically
. This is when we call the
Logger.initialize() method which then uses Log4jConfigUtils, which in
turn tries to configure logging based on the default.logging.conf.
There are two instances in our code where we make use of
Logger.initialize() before we get to the Logger instance (through
Logger.getInstance
logger instances on our own. There are two
instances where we might be using the configuration defined in
default.logging.conf files. This is when we call the
Logger.initialize() method which then uses Log4jConfigUtils, which in
turn tries to configure logging based on the default.logging.conf
50 matches
Mail list logo
