RE: [jira] Commented: (SM-846) Call to default constructor ofJBIContainer changes log4j log level

2007-02-19 Thread Rossmanith, Philipp

Hi Guillaume,

Sorry, I was already out of office when you sent the mail... I saw that
you did a fix, and I'll check if it works for me. Thanks!

The problem first occurred in one of my own test cases, but then I
reproduced it in the SecuredBroker test case by instantiating a Logger
there right before the call to the JBIContainer constructor and
observing the log level of its parent, which switched from ALL to ERROR.

Ciao,
Philipp Rossmanith

 -Mensaje original-
 De: Guillaume Nodet (JIRA) [mailto:[EMAIL PROTECTED]
 Enviado el: viernes, 16 de febrero de 2007 19:48
 Para: servicemix-dev@geronimo.apache.org
 Asunto: [jira] Commented: (SM-846) Call to default constructor
 ofJBIContainer changes log4j log level


 [ https://issues.apache.org/activemq/browse/SM-
 846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
 tabpanel#action_38541 ]

 Guillaume Nodet commented on SM-846:
 

 Philip,
 Is the IdGenerator the only issue ? I still don't understand why / how
 servicemix
 could change the log4j level ...
 What's the way to reproduce the problem ?

  Call to default constructor of JBIContainer changes log4j log level
  ---
 
  Key: SM-846
  URL:
https://issues.apache.org/activemq/browse/SM-846
  Project: ServiceMix
   Issue Type: Bug
 Affects Versions: 3.0
  Environment: Windows XP Professional, java version 1.5.0_09,
 JUnit 4.1
 Reporter: Philipp Rossmanith
 Priority: Minor
 
  A call to the default constructor of
 org.apache.servicemix.jbi.container.JBIContainer sets the log4j log
level
 to ERROR. See
http://www.nabble.com/Default-constructor-for-JBIContainer-
 changes-log-level--tf3235243s12049.html
  Can be observed in
org.apache.servicemix.jbi.security.SecuredBrokerTest,
 line 63:
  jbi = new JBIContainer();
  JBIContainer doesn't seem to use org.apache.log4j, but makes calls
to
 org.apache.commons.logging.Log and
org.apache.commons.logging.LogFactory:
  
  private static final Log log =
LogFactory.getLog(JBIContainer.class);
  
  ... as well as to java.util.logging.Logger:
  
  public Logger getLogger(String suffix, String resourceBundleName)
throws
 MissingResourceException, JBIException
  
  commons-logging is configured in ServiceMix. Which in turns, starts
 log4j if included in the classpath.
  It seems that org.apache.servicemix.id.IdGenerator calls the
 java.util.logging package. This is the only call afaik and it should
be
 removed.

 --
 This message is automatically generated by JIRA.
 -
 You can reply to this email to add a comment to the issue online.


This e-mail may contain confidential or privileged information. Any unauthorised
copying, use or distribution of this information is strictly prohibited.


[jira] Commented: (SM-846) Call to default constructor of JBIContainer changes log4j log level

2007-02-16 Thread Guillaume Nodet (JIRA)

[ 
https://issues.apache.org/activemq/browse/SM-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38541
 ] 

Guillaume Nodet commented on SM-846:


Philip,
Is the IdGenerator the only issue ? I still don't understand why / how 
servicemix
could change the log4j level ...
What's the way to reproduce the problem ?

 Call to default constructor of JBIContainer changes log4j log level
 ---

 Key: SM-846
 URL: https://issues.apache.org/activemq/browse/SM-846
 Project: ServiceMix
  Issue Type: Bug
Affects Versions: 3.0
 Environment: Windows XP Professional, java version 1.5.0_09, JUnit 4.1
Reporter: Philipp Rossmanith
Priority: Minor

 A call to the default constructor of 
 org.apache.servicemix.jbi.container.JBIContainer sets the log4j log level to 
 ERROR. See 
 http://www.nabble.com/Default-constructor-for-JBIContainer-changes-log-level--tf3235243s12049.html
 Can be observed in org.apache.servicemix.jbi.security.SecuredBrokerTest, line 
 63:
 jbi = new JBIContainer();
 JBIContainer doesn't seem to use org.apache.log4j, but makes calls to 
 org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory:
 
 private static final Log log = LogFactory.getLog(JBIContainer.class);
 
 ... as well as to java.util.logging.Logger:
 
 public Logger getLogger(String suffix, String resourceBundleName) throws 
 MissingResourceException, JBIException 
 
 commons-logging is configured in ServiceMix. Which in turns, starts log4j if 
 included in the classpath.
 It seems that org.apache.servicemix.id.IdGenerator calls the 
 java.util.logging package. This is the only call afaik and it should be 
 removed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (SM-846) Call to default constructor of JBIContainer changes log4j log level

2007-02-16 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/activemq/browse/SM-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved SM-846.


   Resolution: Fixed
Fix Version/s: 3.2
   3.1.1
 Assignee: Guillaume Nodet

URL: http://svn.apache.org/viewvc?view=revrev=508541
URL: http://svn.apache.org/viewvc?view=revrev=508544


 Call to default constructor of JBIContainer changes log4j log level
 ---

 Key: SM-846
 URL: https://issues.apache.org/activemq/browse/SM-846
 Project: ServiceMix
  Issue Type: Bug
Affects Versions: 3.0
 Environment: Windows XP Professional, java version 1.5.0_09, JUnit 4.1
Reporter: Philipp Rossmanith
 Assigned To: Guillaume Nodet
Priority: Minor
 Fix For: 3.1.1, 3.2


 A call to the default constructor of 
 org.apache.servicemix.jbi.container.JBIContainer sets the log4j log level to 
 ERROR. See 
 http://www.nabble.com/Default-constructor-for-JBIContainer-changes-log-level--tf3235243s12049.html
 Can be observed in org.apache.servicemix.jbi.security.SecuredBrokerTest, line 
 63:
 jbi = new JBIContainer();
 JBIContainer doesn't seem to use org.apache.log4j, but makes calls to 
 org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory:
 
 private static final Log log = LogFactory.getLog(JBIContainer.class);
 
 ... as well as to java.util.logging.Logger:
 
 public Logger getLogger(String suffix, String resourceBundleName) throws 
 MissingResourceException, JBIException 
 
 commons-logging is configured in ServiceMix. Which in turns, starts log4j if 
 included in the classpath.
 It seems that org.apache.servicemix.id.IdGenerator calls the 
 java.util.logging package. This is the only call afaik and it should be 
 removed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: log4j

2007-01-12 Thread Thomas TERMIN
Hello,

attached the patch for the new logging service. Please have a look at it
if it is ok this way (if it is please let me know I will raise a JIRA
issue then and will attach the patch). If there are any improvements on
it I will change that.

Cheers,
Thomas

Guillaume Nodet wrote:
 Forwarding to the dev list ...
 
 I think you may want to take a look at how the
 JdbcAuditor, DotViewService or StatisticsService
 are implemented.  They all inherit the
 o.a.s.jbi.management.BaseSystemService
 abstract class.  They come in different flavous wrt configuration however.
 I would recommend to look at the StatisticsService, which can be configured
 that way:
 
   sm:container ...
 sm:services
   sm:statistics .. /
 /sm:services
   /sm:container
 
 This way, the service is automatically registered in JMX and has its own
 lifecycle (which is tied to the container), so that you can stop / start
 the
 service from jmx.
 
 On 1/11/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
 What I want to do is to implement a MBean which configure the log4j
 system periodicaly with a scheduler. But before I will look if there is
 a log4j.xml or log4j.properties in the conf directory if there is
 nothing in it then I assume that there is no log4j system and don't
 reconfigure log4j (I will give you a better explanation later ;-) ).

 The Problem what I have is to register a MBean in conf/servicemix.xml.
 How do I have to do this? I tried this with the spring MBeanExporter but
 it doesn't work for me.

 Cheers,
 Thomas

 
  Btw, if you don't mind, i'd rather have such discussion on
  servicemix-dev / servicemix-users ;-)
 No problem at all! If you open the thread...

 
 
  Cheers,
  Thomas
 
  Guillaume Nodet wrote:
   Did you implement something useful ?  Would you
   consider giving it back to ServiceMix ?
  
   On 10/20/06, Thomas TERMIN [EMAIL PROTECTED] wrote:
   Sorry I did not mean a servicemix component. I use allways the word
   component ;-) since I started working with servicemix. What you
  said is
   exactly what I meant. So I will have a look on it!
  
   Thanks,
   Thomas
  
   Guillaume Nodet wrote:
I would rather use a ServiceMix service instead of
a component, as this is more related to management /
configuration than a component if I understand you
correctly.  ... and use a timer to reload the log4j config.
But iirc, log4j already has this feature, we just need to
enable it.
   
On 10/20/06, Thomas TERMIN [EMAIL PROTECTED] wrote:
Hello Guillaume,
   
We would need a log4j Component where you can change the debug
   level at
runtime. I would implement a MBean which initialise the log4j
   system at
startup and also have a scheduler which looks if the
 log4j.xml has
changed and then reinitialise the log4j system.
   
If I would provide you a patch would you accept this in
 servicemix?
   
Cheers,
Thomas Termin
   
   
   
  
  
  
  
 
 
 
 


 
 

Index: core/servicemix-core/src/main/java/org/apache/servicemix/jbi/logging/LogService.java
===
--- core/servicemix-core/src/main/java/org/apache/servicemix/jbi/logging/LogService.java	(Revision 0)
+++ core/servicemix-core/src/main/java/org/apache/servicemix/jbi/logging/LogService.java	(Revision 0)
@@ -0,0 +1,212 @@
+package org.apache.servicemix.jbi.logging;
+
+import org.apache.servicemix.jbi.management.BaseSystemService;
+import org.apache.servicemix.jbi.management.OperationInfoHelper;
+import org.apache.servicemix.jbi.management.AttributeInfoHelper;
+import org.apache.servicemix.jbi.container.JBIContainer;
+import org.apache.log4j.Logger;
+import org.springframework.beans.factory.InitializingBean;
+
+import javax.jbi.JBIException;
+import javax.management.MBeanOperationInfo;
+import javax.management.JMException;
+import javax.management.MBeanAttributeInfo;
+import java.util.Timer;
+import java.net.URL;
+import java.net.MalformedURLException;
+
+/**
+ *
+ *
+ * @org.apache.xbean.XBean element=logService
+ *
+ * TODO add methods to change one or more specific LogLevels at runtime
+ */
+public class LogService extends BaseSystemService implements InitializingBean, LogServiceMBean
+{
+  private boolean autoStart = true;
+  private boolean initialized = false;
+  private int refreshPeriod = 60; // 60sec
+  private URL configFileUrl = null;
+  private String configUrl = file:conf/log4j.xml;
+  private LogTask logTask = null;
+  // timer in daemon mode
+  private Timer timer = null;
+  private static Logger logger = Logger.getLogger(LogService.class);
+
+  public void afterPropertiesSet() throws Exception {
+if (this.container == null) {
+  throw new IllegalArgumentException(container should not be null);
+}
+init(getContainer());
+if (autoStart) {
+  start();
+}
+  }
+
+  public JBIContainer getContainer() {
+return container;
+  }
+
+  public void setContainer(JBIContainer container) {
+   this.container

Re: log4j

2007-01-12 Thread Guillaume Nodet

Yeah, good point.
As was only worried to use a relative URL ...
Let mw try it first.
Could you raise a JIRA and attach the patch please ?

On 1/12/07, Thomas TERMIN [EMAIL PROTECTED] wrote:

Guillaume Nodet wrote:
 Yeah, looks good. I will try it now.
 What about using a spring Resource instead of a String ?
Yes would be nice of course but than I have to learn spring. ;-) I'm not
that experienced with spring.

 I think it would enable using classpath: notation, which is very
 handy ...  Hum, i guess it would not work with JMX ;-)
It should.

 I guess we could simulate that by checking if the url begins
 with classpath:  and use a getClass().getClassLoader().getResource() ?

 What do you think ?
That should of course work. I did this because DOMConfigurator.configure
use the url and because I could check the content type of the config
file. So that we could later (if it is needed) extend this service for a
normal log4j.properties file. If it is application/xml then use
DOMConfigurator and if it is text use PropertyConfigurator.

Cheers,
Thomas


 On 1/12/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
 Hello,

 attached the patch for the new logging service. Please have a look at it
 if it is ok this way (if it is please let me know I will raise a JIRA
 issue then and will attach the patch). If there are any improvements on
 it I will change that.

 Cheers,
 Thomas

 Guillaume Nodet wrote:
  Forwarding to the dev list ...
 
  I think you may want to take a look at how the
  JdbcAuditor, DotViewService or StatisticsService
  are implemented.  They all inherit the
  o.a.s.jbi.management.BaseSystemService
  abstract class.  They come in different flavous wrt configuration
 however.
  I would recommend to look at the StatisticsService, which can be
 configured
  that way:
 
sm:container ...
  sm:services
sm:statistics .. /
  /sm:services
/sm:container
 
  This way, the service is automatically registered in JMX and has its
 own
  lifecycle (which is tied to the container), so that you can stop /
 start
  the
  service from jmx.
 
  On 1/11/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
  What I want to do is to implement a MBean which configure the log4j
  system periodicaly with a scheduler. But before I will look if
 there is
  a log4j.xml or log4j.properties in the conf directory if there is
  nothing in it then I assume that there is no log4j system and don't
  reconfigure log4j (I will give you a better explanation later ;-) ).
 
  The Problem what I have is to register a MBean in conf/servicemix.xml.
  How do I have to do this? I tried this with the spring
 MBeanExporter but
  it doesn't work for me.
 
  Cheers,
  Thomas
 
  
   Btw, if you don't mind, i'd rather have such discussion on
   servicemix-dev / servicemix-users ;-)
  No problem at all! If you open the thread...
 
  
  
   Cheers,
   Thomas
  
   Guillaume Nodet wrote:
Did you implement something useful ?  Would you
consider giving it back to ServiceMix ?
   
On 10/20/06, Thomas TERMIN [EMAIL PROTECTED] wrote:
Sorry I did not mean a servicemix component. I use allways
 the word
component ;-) since I started working with servicemix. What you
   said is
exactly what I meant. So I will have a look on it!
   
Thanks,
Thomas
   
Guillaume Nodet wrote:
 I would rather use a ServiceMix service instead of
 a component, as this is more related to management /
 configuration than a component if I understand you
 correctly.  ... and use a timer to reload the log4j config.
 But iirc, log4j already has this feature, we just need to
 enable it.

 On 10/20/06, Thomas TERMIN [EMAIL PROTECTED]
 wrote:
 Hello Guillaume,

 We would need a log4j Component where you can change the
 debug
level at
 runtime. I would implement a MBean which initialise the log4j
system at
 startup and also have a scheduler which looks if the
  log4j.xml has
 changed and then reinitialise the log4j system.

 If I would provide you a patch would you accept this in
  servicemix?

 Cheers,
 Thomas Termin



   
   
   
   
  
  
  
  
 
 
 
 











--
Cheers,
Guillaume Nodet

Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/


[jira] Created: (SM-817) log4j service for changing log levels at runtime

2007-01-12 Thread Thomas Termin (JIRA)
log4j service for changing log levels at  runtime
-

 Key: SM-817
 URL: https://issues.apache.org/activemq/browse/SM-817
 Project: ServiceMix
  Issue Type: New Feature
  Components: servicemix-core
Reporter: Thomas Termin
 Attachments: logging_service.patch

This patch add a new MBean service to reconfigure the log4j system at runtime. 
The default is a scheduler which looks in a configurable time for changes in 
the log4j.xml file and reconfigures the system if something has changed and of 
course if the file is available. 

The service could be extended to read also a property file and reconfigure the 
system as well as to set one or more specific log levels via JMX console. I 
wouldn't need that...!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: log4j

2007-01-11 Thread Thomas TERMIN
So I implemted it. It works fine until now. I still have to do some
improvements on it but I guess I can provide it to you tomorrow.

Cheers,
Thomas

Thomas TERMIN wrote:
 I found it. ;-)
 
 I'm implementing at the moment the new service.
 
 Guillaume Nodet wrote:
 Forwarding to the dev list ...

 I think you may want to take a look at how the
 JdbcAuditor, DotViewService or StatisticsService
 are implemented.  They all inherit the
 o.a.s.jbi.management.BaseSystemService
 abstract class.  They come in different flavous wrt configuration however.
 I would recommend to look at the StatisticsService, which can be configured
 that way:

   sm:container ...
 sm:services
   sm:statistics .. /
 /sm:services
   /sm:container

 This way, the service is automatically registered in JMX and has its own
 lifecycle (which is tied to the container), so that you can stop / start
 the
 service from jmx.

 On 1/11/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
 What I want to do is to implement a MBean which configure the log4j
 system periodicaly with a scheduler. But before I will look if there is
 a log4j.xml or log4j.properties in the conf directory if there is
 nothing in it then I assume that there is no log4j system and don't
 reconfigure log4j (I will give you a better explanation later ;-) ).

 The Problem what I have is to register a MBean in conf/servicemix.xml.
 How do I have to do this? I tried this with the spring MBeanExporter but
 it doesn't work for me.

 Cheers,
 Thomas

 Btw, if you don't mind, i'd rather have such discussion on
 servicemix-dev / servicemix-users ;-)
 No problem at all! If you open the thread...

 Cheers,
 Thomas

 Guillaume Nodet wrote:
 Did you implement something useful ?  Would you
 consider giving it back to ServiceMix ?

 On 10/20/06, Thomas TERMIN [EMAIL PROTECTED] wrote:
 Sorry I did not mean a servicemix component. I use allways the word
 component ;-) since I started working with servicemix. What you
 said is
 exactly what I meant. So I will have a look on it!

 Thanks,
 Thomas

 Guillaume Nodet wrote:
 I would rather use a ServiceMix service instead of
 a component, as this is more related to management /
 configuration than a component if I understand you
 correctly.  ... and use a timer to reload the log4j config.
 But iirc, log4j already has this feature, we just need to
 enable it.

 On 10/20/06, Thomas TERMIN [EMAIL PROTECTED] wrote:
 Hello Guillaume,

 We would need a log4j Component where you can change the debug
 level at
 runtime. I would implement a MBean which initialise the log4j
 system at
 startup and also have a scheduler which looks if the
 log4j.xml has
 changed and then reinitialise the log4j system.

 If I would provide you a patch would you accept this in
 servicemix?
 Cheers,
 Thomas Termin








 
 



[jira] Resolved: (SM-741) Upgrade commons-logging to 1.1 and log4j to 1.2.13 to support the log4j TRACE level

2006-11-14 Thread Guillaume Nodet (JIRA)
 [ https://issues.apache.org/activemq/browse/SM-741?page=all ]

Guillaume Nodet resolved SM-741.


Resolution: Fixed

Author: gnodet
Date: Thu Nov  9 11:03:19 2006
New Revision: 473028

URL: http://svn.apache.org/viewvc?view=revrev=473028
Log:
SM-741: Upgrade commons-logging to 1.1 and log4j to 1.2.13

Modified:
   incubator/servicemix/trunk/pom.xml


 Upgrade commons-logging to 1.1 and log4j to 1.2.13 to support the log4j TRACE 
 level
 ---

 Key: SM-741
 URL: https://issues.apache.org/activemq/browse/SM-741
 Project: ServiceMix
  Issue Type: Task
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 3.1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira