Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
On 9/6/07, David Blevins [EMAIL PROTECTED] wrote: Cool. I've updated the Geronimo side as follows: ...and I've created a page about how the OpenEJB-Geronimo integration works in Geronimo Wiki [1] where I expect to find information on openejb.logger.external as well (I purposely wrote 'I expect' as I'm not sure when I find some spare time to approach it ;-)). I'll try to collect as much information there as I can as I see a great need to improve it and my knowledge about it. [1] http://cwiki.apache.org/confluence/display/GMOxKB/How+OpenEJB+integration+works p.s. I know I shouldn't use Confluence URLs, but rather their html version, but it's not been autogenerated yet and I didn't mean to wait announcing it. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
Can we ask the Geronimo team to set it in the
org.apache.geronimo.openejb.OpenEjbSystemGBean class.
This is because Geronimo also uses the same classes as we use in
embedded mode. So it will not be possible to set the SystemProperty
there. For example, OpenEjbSystemGBean also uses SystemInstance, but
our code also uses SystemInstance heavily. So setting it in
SystemInstance will not lead to the desired behaviour.
We can however try the following options:
1. Ask Geronimo team to set this property in
org.apache.geronimo.openejb.OpenEjbSystemGBean
2. Geronimo also sets a System property named duct tape, we just
check for that
3. Geronimo also adds the GeronimoThreadContextListener to
org.apache.openejb.core.ThreadContext, we could check for that also
In case of 2 and 3 above , we do not have to ask the Geronimo team to
make any changes to their code base.
So below could be a possible logic in org.apache.openejb.util.Logger
For option 2 and 3 above we could add a method :
private void setLoggingMode(){
if(System.getProperty(duct tape) != null){
System.setProperty(openejb.logging.external,true);
}else if(/*check if GeronimoThreadContextListener is a registered
listener*/){
/*
For this we would need to add a ThreadContext.getListeners() method
and then from here we can check if there is any listener whose class
name is GeronimoThreadContextListener
*/
System.setProperty(openejb.logging.external,true);
}else{
System.setProperty(openejb.logging.external,false);
}
}
The first thing the Logger would do (one time only) is set the logging
mode, and then the logging strategy could revolve around this
property.
This would be a kind of Geronimo only solution, but atleast we can fix
this thing right now and worry about other app servers later.
Do you know of any other way we could safely add the system property
openejb.logging.external in our code base which could apply to all
external clients and not only Geronimo?
On 8/30/07, David Blevins [EMAIL PROTECTED] wrote:
On Aug 29, 2007, at 6:12 PM, Karan Malhi wrote:
Or maybe in one of the very first OpenEJB methods called by Geronimo
to start openejb in embedded mode we could add some code like
System.setProperty(openejb.logging,external);
the first time the Logger class is loaded, we check for this property
and if it has a value of external, then we do not use
embedded.logging.properties otherwise we assume our default strategy.
Sounds like that's the way to go. Just check for don't configure
logging and follow those orders if it's set. Let's make the
property be true/false. Maybe openejb.logging.external=true or
something similar.
-David
--
Karan Singh Malhi
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
On Sep 6, 2007, at 9:04 AM, Karan Malhi wrote: This is because Geronimo also uses the same classes as we use in embedded mode. So it will not be possible to set the SystemProperty there. For example, OpenEjbSystemGBean also uses SystemInstance, but our code also uses SystemInstance heavily. So setting it in SystemInstance will not lead to the desired behaviour. We can however try the following options: 1. Ask Geronimo team to set this property in org.apache.geronimo.openejb.OpenEjbSystemGBean Not sure I followed the explanation above. Ideally we'd be able to use option 1 here as that's what we do for other properties. Setting openejb.logging.external=true as a plain system property in OpenEjbSystemGBean should work right? -David
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
Yes it should work. On 9/6/07, David Blevins [EMAIL PROTECTED] wrote: On Sep 6, 2007, at 9:04 AM, Karan Malhi wrote: This is because Geronimo also uses the same classes as we use in embedded mode. So it will not be possible to set the SystemProperty there. For example, OpenEjbSystemGBean also uses SystemInstance, but our code also uses SystemInstance heavily. So setting it in SystemInstance will not lead to the desired behaviour. We can however try the following options: 1. Ask Geronimo team to set this property in org.apache.geronimo.openejb.OpenEjbSystemGBean Not sure I followed the explanation above. Ideally we'd be able to use option 1 here as that's what we do for other properties. Setting openejb.logging.external=true as a plain system property in OpenEjbSystemGBean should work right? -David -- Karan Singh Malhi
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
Cool. I've updated the Geronimo side as follows:
Index: src/main/java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java
===
--- src/main/java/org/apache/geronimo/openejb/
OpenEjbSystemGBean.java (revision 570242)
+++ src/main/java/org/apache/geronimo/openejb/
OpenEjbSystemGBean.java (working copy)
@@ -104,7 +104,8 @@
}
System.setProperty(duct tape,);
System.setProperty(admin.disabled, true);
-
+System.setProperty(openejb.logger.external, true);
+
setDefaultProperty(openejb.deploymentId.format,
{moduleId}/{ejbName});
setDefaultProperty(openejb.jndiname.strategy.class,
org.apache.openejb.assembler.classic.JndiBuilder$TemplatedStrategy);
setDefaultProperty(openejb.jndiname.format,
{deploymentId}/{interfaceClass});
On Sep 6, 2007, at 1:52 PM, Karan Malhi wrote:
Yes it should work.
On 9/6/07, David Blevins [EMAIL PROTECTED] wrote:
On Sep 6, 2007, at 9:04 AM, Karan Malhi wrote:
This is because Geronimo also uses the same classes as we use in
embedded mode. So it will not be possible to set the SystemProperty
there. For example, OpenEjbSystemGBean also uses SystemInstance, but
our code also uses SystemInstance heavily. So setting it in
SystemInstance will not lead to the desired behaviour.
We can however try the following options:
1. Ask Geronimo team to set this property in
org.apache.geronimo.openejb.OpenEjbSystemGBean
Not sure I followed the explanation above. Ideally we'd be able to
use option 1 here as that's what we do for other properties.
Setting openejb.logging.external=true as a plain system property in
OpenEjbSystemGBean should work right?
-David
--
Karan Singh Malhi
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
On Aug 29, 2007, at 6:12 PM, Karan Malhi wrote: Or maybe in one of the very first OpenEJB methods called by Geronimo to start openejb in embedded mode we could add some code like System.setProperty(openejb.logging,external); the first time the Logger class is loaded, we check for this property and if it has a value of external, then we do not use embedded.logging.properties otherwise we assume our default strategy. Sounds like that's the way to go. Just check for don't configure logging and follow those orders if it's set. Let's make the property be true/false. Maybe openejb.logging.external=true or something similar. -David
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
Okay, Will implement it with openejb.logging.external=true/false. On 8/30/07, David Blevins [EMAIL PROTECTED] wrote: On Aug 29, 2007, at 6:12 PM, Karan Malhi wrote: Or maybe in one of the very first OpenEJB methods called by Geronimo to start openejb in embedded mode we could add some code like System.setProperty(openejb.logging,external); the first time the Logger class is loaded, we check for this property and if it has a value of external, then we do not use embedded.logging.properties otherwise we assume our default strategy. Sounds like that's the way to go. Just check for don't configure logging and follow those orders if it's set. Let's make the property be true/false. Maybe openejb.logging.external=true or something similar. -David -- Karan Singh Malhi
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
On Aug 28, 2007, at 7:35 PM, Karan Malhi wrote: I dont even think they can change log levels. We used the logic that - if conf is present - use logging.properties - if conf is present - logging.properties is absent- install logging.properties and use it - if conf is absent, assume embedded and use embedded.logging.properties which is available in the openejb-core.jar . - if embedded.logging.properties is not found in openejb-core.jar then rely on the log4j.configuration system property So, if openejb is embedded within GERONIMO, no matter what log levels they set in the var/logs directory, those settings should never take effect. I think what we can do though is that Geronimo can set the log4j.configuration system property in the o.a.g.openejb.OpenEjbSystemGBean and we can then do the following: - if conf is absent, assume embedded, look for log4j.configuration system property. if log4j.configuration property is set, then use it, if it is absent then use embedded.logging.properties Do you think I am on the right track and does the above makes any sense? Do you know if there is a way to check to see if the OpenEJB log4j category has been explicitly configured? If so we could skip the whole business and assume whatever embedded environment we're in has taken responsibility for logging. -David
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
The only way I know of is to do something like Logger openejb = Logger.getInstance(LogCategory.OPENEJB, Foo.class); boolean configured = openejb.getAllAppenders().hasMoreElements(); If there is an appender for OPENEJB then configured will be true and we will know that OPENEJB was configured explicitly. Okay, now here are some of the major flaws with this approach, 1. If rootLogger is configured by the user and has an appender, then OPENEJB will inherit the appender. So even if OPENEJB is not explicitly configured, it will still have an appender. 2. Lets say we first check and find that rootLogger does not have an appender, in that case if OPENEJB has an appender, then we are sure that OPENEJB is configured explicitly. 3. If rootLogger and OPENEJB do not have an appender, then we can guess that OPENEJB is not configured, but we can still have a case where OPENEJB was configured explicitly, but somebody forgot to add an appender to it. We will have to mention that if OPENEJB is not configured explicitly with an appender, then logging will not work. On 8/29/07, David Blevins [EMAIL PROTECTED] wrote: On Aug 28, 2007, at 7:35 PM, Karan Malhi wrote: I dont even think they can change log levels. We used the logic that - if conf is present - use logging.properties - if conf is present - logging.properties is absent- install logging.properties and use it - if conf is absent, assume embedded and use embedded.logging.properties which is available in the openejb-core.jar . - if embedded.logging.properties is not found in openejb-core.jar then rely on the log4j.configuration system property So, if openejb is embedded within GERONIMO, no matter what log levels they set in the var/logs directory, those settings should never take effect. I think what we can do though is that Geronimo can set the log4j.configuration system property in the o.a.g.openejb.OpenEjbSystemGBean and we can then do the following: - if conf is absent, assume embedded, look for log4j.configuration system property. if log4j.configuration property is set, then use it, if it is absent then use embedded.logging.properties Do you think I am on the right track and does the above makes any sense? Do you know if there is a way to check to see if the OpenEJB log4j category has been explicitly configured? If so we could skip the whole business and assume whatever embedded environment we're in has taken responsibility for logging. -David -- Karan Singh Malhi
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
Just thinking, could we do something with a Thread Context, i.e. if it is an App Server Thread Context, then we do not use embedded.logging.properties file, if it is an OpenEJB thread context which is trying to access the Logger, then if we go with our existing strategy. I dont even know what I am saying here and dont have a clue how it could be done, but just thinking maybe this could lead to something ;) On 8/29/07, Karan Malhi [EMAIL PROTECTED] wrote: The only way I know of is to do something like Logger openejb = Logger.getInstance(LogCategory.OPENEJB, Foo.class); boolean configured = openejb.getAllAppenders().hasMoreElements(); If there is an appender for OPENEJB then configured will be true and we will know that OPENEJB was configured explicitly. Okay, now here are some of the major flaws with this approach, 1. If rootLogger is configured by the user and has an appender, then OPENEJB will inherit the appender. So even if OPENEJB is not explicitly configured, it will still have an appender. 2. Lets say we first check and find that rootLogger does not have an appender, in that case if OPENEJB has an appender, then we are sure that OPENEJB is configured explicitly. 3. If rootLogger and OPENEJB do not have an appender, then we can guess that OPENEJB is not configured, but we can still have a case where OPENEJB was configured explicitly, but somebody forgot to add an appender to it. We will have to mention that if OPENEJB is not configured explicitly with an appender, then logging will not work. On 8/29/07, David Blevins [EMAIL PROTECTED] wrote: On Aug 28, 2007, at 7:35 PM, Karan Malhi wrote: I dont even think they can change log levels. We used the logic that - if conf is present - use logging.properties - if conf is present - logging.properties is absent- install logging.properties and use it - if conf is absent, assume embedded and use embedded.logging.properties which is available in the openejb-core.jar . - if embedded.logging.properties is not found in openejb-core.jar then rely on the log4j.configuration system property So, if openejb is embedded within GERONIMO, no matter what log levels they set in the var/logs directory, those settings should never take effect. I think what we can do though is that Geronimo can set the log4j.configuration system property in the o.a.g.openejb.OpenEjbSystemGBean and we can then do the following: - if conf is absent, assume embedded, look for log4j.configuration system property. if log4j.configuration property is set, then use it, if it is absent then use embedded.logging.properties Do you think I am on the right track and does the above makes any sense? Do you know if there is a way to check to see if the OpenEJB log4j category has been explicitly configured? If so we could skip the whole business and assume whatever embedded environment we're in has taken responsibility for logging. -David -- Karan Singh Malhi -- Karan Singh Malhi
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
Or maybe in one of the very first OpenEJB methods called by Geronimo to start openejb in embedded mode we could add some code like System.setProperty(openejb.logging,external); the first time the Logger class is loaded, we check for this property and if it has a value of external, then we do not use embedded.logging.properties otherwise we assume our default strategy. On 8/29/07, Karan Malhi [EMAIL PROTECTED] wrote: Just thinking, could we do something with a Thread Context, i.e. if it is an App Server Thread Context, then we do not use embedded.logging.properties file, if it is an OpenEJB thread context which is trying to access the Logger, then if we go with our existing strategy. I dont even know what I am saying here and dont have a clue how it could be done, but just thinking maybe this could lead to something ;) On 8/29/07, Karan Malhi [EMAIL PROTECTED] wrote: The only way I know of is to do something like Logger openejb = Logger.getInstance(LogCategory.OPENEJB, Foo.class); boolean configured = openejb.getAllAppenders().hasMoreElements(); If there is an appender for OPENEJB then configured will be true and we will know that OPENEJB was configured explicitly. Okay, now here are some of the major flaws with this approach, 1. If rootLogger is configured by the user and has an appender, then OPENEJB will inherit the appender. So even if OPENEJB is not explicitly configured, it will still have an appender. 2. Lets say we first check and find that rootLogger does not have an appender, in that case if OPENEJB has an appender, then we are sure that OPENEJB is configured explicitly. 3. If rootLogger and OPENEJB do not have an appender, then we can guess that OPENEJB is not configured, but we can still have a case where OPENEJB was configured explicitly, but somebody forgot to add an appender to it. We will have to mention that if OPENEJB is not configured explicitly with an appender, then logging will not work. On 8/29/07, David Blevins [EMAIL PROTECTED] wrote: On Aug 28, 2007, at 7:35 PM, Karan Malhi wrote: I dont even think they can change log levels. We used the logic that - if conf is present - use logging.properties - if conf is present - logging.properties is absent- install logging.properties and use it - if conf is absent, assume embedded and use embedded.logging.properties which is available in the openejb-core.jar . - if embedded.logging.properties is not found in openejb-core.jar then rely on the log4j.configuration system property So, if openejb is embedded within GERONIMO, no matter what log levels they set in the var/logs directory, those settings should never take effect. I think what we can do though is that Geronimo can set the log4j.configuration system property in the o.a.g.openejb.OpenEjbSystemGBean and we can then do the following: - if conf is absent, assume embedded, look for log4j.configuration system property. if log4j.configuration property is set, then use it, if it is absent then use embedded.logging.properties Do you think I am on the right track and does the above makes any sense? Do you know if there is a way to check to see if the OpenEJB log4j category has been explicitly configured? If so we could skip the whole business and assume whatever embedded environment we're in has taken responsibility for logging. -David -- Karan Singh Malhi -- Karan Singh Malhi -- Karan Singh Malhi
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
On Aug 27, 2007, at 4:25 PM, Karan Malhi wrote: How do the users of geronimo set log levels? Should be through the log4 files in the /var/log directory of the install. -David On 8/27/07, David Blevins (JIRA) [EMAIL PROTECTED] wrote: Verify log levels can be changed for openejb related log categories --- Key: GERONIMO-3445 URL: https://issues.apache.org/jira/browse/ GERONIMO-3445 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0 Reporter: David Blevins Some users have reported inability to change log levels for log categories pertaining to OpenEJB. This needs to be investigated, verified and fixed if found to be an issue or better documented if found not to be an issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Karan Singh Malhi
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
I dont even think they can change log levels. We used the logic that - if conf is present - use logging.properties - if conf is present - logging.properties is absent- install logging.properties and use it - if conf is absent, assume embedded and use embedded.logging.properties which is available in the openejb-core.jar . - if embedded.logging.properties is not found in openejb-core.jar then rely on the log4j.configuration system property So, if openejb is embedded within GERONIMO, no matter what log levels they set in the var/logs directory, those settings should never take effect. I think what we can do though is that Geronimo can set the log4j.configuration system property in the o.a.g.openejb.OpenEjbSystemGBean and we can then do the following: - if conf is absent, assume embedded, look for log4j.configuration system property. if log4j.configuration property is set, then use it, if it is absent then use embedded.logging.properties Do you think I am on the right track and does the above makes any sense? On 8/28/07, David Blevins [EMAIL PROTECTED] wrote: On Aug 27, 2007, at 4:25 PM, Karan Malhi wrote: How do the users of geronimo set log levels? Should be through the log4 files in the /var/log directory of the install. -David On 8/27/07, David Blevins (JIRA) [EMAIL PROTECTED] wrote: Verify log levels can be changed for openejb related log categories --- Key: GERONIMO-3445 URL: https://issues.apache.org/jira/browse/ GERONIMO-3445 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0 Reporter: David Blevins Some users have reported inability to change log levels for log categories pertaining to OpenEJB. This needs to be investigated, verified and fixed if found to be an issue or better documented if found not to be an issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Karan Singh Malhi -- Karan Singh Malhi
[jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
Verify log levels can be changed for openejb related log categories --- Key: GERONIMO-3445 URL: https://issues.apache.org/jira/browse/GERONIMO-3445 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0 Reporter: David Blevins Some users have reported inability to change log levels for log categories pertaining to OpenEJB. This needs to be investigated, verified and fixed if found to be an issue or better documented if found not to be an issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
How do the users of geronimo set log levels? On 8/27/07, David Blevins (JIRA) [EMAIL PROTECTED] wrote: Verify log levels can be changed for openejb related log categories --- Key: GERONIMO-3445 URL: https://issues.apache.org/jira/browse/GERONIMO-3445 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0 Reporter: David Blevins Some users have reported inability to change log levels for log categories pertaining to OpenEJB. This needs to be investigated, verified and fixed if found to be an issue or better documented if found not to be an issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Karan Singh Malhi
