Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
Hi, As a user and a consumer of Tuscany that has had to debug problems, I have a couple of comments. Raymond Feng wrote: It seems to me that we could use the EventManagement in the core to handle these in the event/listener pattern. If possible, I would like to see Tuscany focus on the higher level event model for component management, on enhancing the exception formatter framework for diagnostics, and improving the wiring, contribution, and assembly validation in a way that would surface errors and an error context to extensions that could be implemented by a consumer. I was referring to the fact that the apsectj-based tracing can be enabled or disabled simply by turning on/off the JVM agent. The annotation-based aspect doesn't require a compiler for the aspectj and it's not invasive. On using aspects for trace, I'm not a huge fan of performing any weaving at runtime during class loading nor in requiring consumers to install an instrumentation agent to turn on trace emission. Not only does dynamic instrumentation lengthen the class load time and effect the benefits of class sharing (in JVM's that support the technology), it assumes that the user has installed the agent because a problem is expected. If aspect weaving is used, I believe it should be an optional part of the build environment and not force fit into the instrumentation agent infrastructure. Thanks. -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
Hi, Please see my comments inline. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Monday, April 23, 2007 10:48 AM Subject: Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions) [snip] Raymond Feng wrote: Hi, Simon. [snip] On the positive side this seems like an approach we could use that separates logging/tracing from the application code. However you still need the aspectj runtime to weave the annotation based aspects into the application classfiles right. I am attracted by doing tracing with aspectj. So that we can turn it off completely when we are done. However I support using a more standard approach for logging more highlevel and persistent events which we might want to plug into other monitoring tools. The aspectj now supports load-time weaving in a standard way supported by Java 5. It would be nice to support tracing on demand with this capability. I agree with you that we need to support high-level monitoring as well. For example, I'm interested in seeing the component interactions. One way we can achieve that is to add a monitoring interceptor. Raymond, I agree that we need high-level monitoring, but it shouldn't be limited to interactions handled by interceptors. For example, we should be able to monitor when the runtime starts, stops, when .composite files are loaded, component instances get created and recycled, wires are matched etc... It seems to me that we could use the EventManagement in the core to handle these in the event/listener pattern. I tried the aspectj sample from your sandbox and I have a few questions: Is it possible to trace the value of the parameters? Yes, we can access the method as well as the input/output. Is it possible to trace when an exception is thrown? Yes. The AfterThrowing will do. Would it be possible to use slf4j from the tracing aspect? Yes, the aspect implementation can be any java code. What did you mean by supporting tracing on demand using the load time weaver? Doesn't load time weaving going to happen at the beginning when classes are loaded?? I was referring to the fact that the apsectj-based tracing can be enabled or disabled simply by turning on/off the JVM agent. The annotation-based aspect doesn't require a compiler for the aspectj and it's not invasive. Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
[snip] Raymond Feng wrote: Hi, Simon. [snip] On the positive side this seems like an approach we could use that separates logging/tracing from the application code. However you still need the aspectj runtime to weave the annotation based aspects into the application classfiles right. I am attracted by doing tracing with aspectj. So that we can turn it off completely when we are done. However I support using a more standard approach for logging more highlevel and persistent events which we might want to plug into other monitoring tools. The aspectj now supports load-time weaving in a standard way supported by Java 5. It would be nice to support tracing on demand with this capability. I agree with you that we need to support high-level monitoring as well. For example, I'm interested in seeing the component interactions. One way we can achieve that is to add a monitoring interceptor. Raymond, I agree that we need high-level monitoring, but it shouldn't be limited to interactions handled by interceptors. For example, we should be able to monitor when the runtime starts, stops, when .composite files are loaded, component instances get created and recycled, wires are matched etc... I tried the aspectj sample from your sandbox and I have a few questions: Is it possible to trace the value of the parameters? Is it possible to trace when an exception is thrown? Would it be possible to use slf4j from the tracing aspect? What did you mean by supporting tracing on demand using the load time weaver? Doesn't load time weaving going to happen at the beginning when classes are loaded?? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
Hi, Simon. [snip] On the positive side this seems like an approach we could use that separates logging/tracing from the application code. However you still need the aspectj runtime to weave the annotation based aspects into the application classfiles right. I am attracted by doing tracing with aspectj. So that we can turn it off completely when we are done. However I support using a more standard approach for logging more highlevel and persistent events which we might want to plug into other monitoring tools. The aspectj now supports load-time weaving in a standard way supported by Java 5. It would be nice to support tracing on demand with this capability. I agree with you that we need to support high-level monitoring as well. For example, I'm interested in seeing the component interactions. One way we can achieve that is to add a monitoring interceptor. Regards Simon Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
On 4/19/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, I created a prototype to play with aop-based logging and tracing. The annotation-style aspect development seems to be simpler as it doesn't require the aspectj compiler. You can see the code at: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/rfeng/aop-logging You can download aspectj 1.5.3 from http://www.eclipse.org/downloads/download.php?file=/tools/aspectj/aspectj-1.5.3.jar and then run the prototype using "test.bat" in the root of the project. Thanks, Raymond - Original Message - From: "Raymond Feng" <[EMAIL PROTECTED]> To: Sent: Wednesday, April 18, 2007 10:49 AM Subject: Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions) > Hi, > > Please see my comments below. > > Thanks, > Raymond > > - Original Message - > From: "ant elder" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, April 18, 2007 3:51 AM > Subject: Monitoring, logging, and exceptions (was: Re: Notifcation of > missing extensions) > > >> On 4/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: >> >> >> >> I found our current Monitor stuff difficult to follow as well. I suggest >>> that we start a new discussion thread to discuss monitoring in general, >>> and try to come up with something that will be more usable and easier to >>> adopt through our whole runtime. >> >> >> Starting the new thread for you... >> >> I agree we should improve monitoring and logging in the runtime. >> >> I've used AOP before for this type of thing, its cool, but it does add >> yet >> another new thing to know about which could be off putting for new >> developers. How about just using one of the existing logging packages >> that >> most people are already completely familiar with? Commons Logging looks >> like >> its coming to its end, no one really likes java.util.logging, so how >> about >> SLF4J, its really easy and nice to use? >> > > I personally don't like the Commons Logging approach very much due to the > fact that conflicting versions are used by many 3rd party artifacts. > > With regard to AOP, do we really need to have all the developers learn how > to use it? I assume we can put together some logging aspects in a separate > module to take care of most of the logging/monitoring concerns. Other > modules are not even aware of the existence of the AOP. Isn't it the > objective of AOP to address the cross-cutting concerns without poluting > the code? > >> I also think exception handling could be improved, I don't find the >> current >> exception formatter design easy to use, and most times stack traces end >> up >> missing the important bit of information you need. How about just using >> the >> traditional way of putting everything in the exception message and >> using >> properties files to allow for I18N? >> > > I think we might be able to improve the ExceptionFormatter by providing a > default formatter which could dump out all the information in the > exception object. We already have a similar function in > "org.apache.tuscany.assembly.util.PrintUtil" and we could further enhance > it. > > To support I18N, we could adopt a pattern for the exception so that a > getter or a field can be recoginzed as the message id. > >> One thing I've wondered about was having a release specifically targeting >> these RAS type features. So once we've worked out the strategy for >> logging, >> exceptions, internationalization etc we have a release where a big focus >> is >> on implementing/fixing/testing all these RAS things. >> > > +1. Enabling RAS is a big effort. > >> ...ant >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] On the positive side this seems like an approach we could use that separates logging/tracing from the application code. However you still need the aspectj runtime to weave the annotation based aspects into the application classfiles right. I am attracted by doing tracing with aspectj. So that we can turn it off completely when we are done. However I support using a more standard approach for logging more highlevel and persistent events which we might want to plug into other monitoring tools. Regards Simon
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
I was referring to this mail [1] when I mentioned commons logging and SLF4J. I don't know if its worth converting if you've already used LOG4J. SLF4J does have some nice features though, particularly parameterized log messages. You can read all about it at: http://www.slf4j.org. ...ant On 4/18/07, Kevin Williams <[EMAIL PROTECTED]> wrote: Is SLF4J a better route than Log4j? If so, I wonder if we should convert over the RDB DAS. On 4/18/07, ant elder <[EMAIL PROTECTED]> wrote: > > On 4/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > I found our current Monitor stuff difficult to follow as well. I suggest > > that we start a new discussion thread to discuss monitoring in general, > > and try to come up with something that will be more usable and easier to > > adopt through our whole runtime. > > > Starting the new thread for you... > > I agree we should improve monitoring and logging in the runtime. > > I've used AOP before for this type of thing, its cool, but it does add yet > another new thing to know about which could be off putting for new > developers. How about just using one of the existing logging packages that > most people are already completely familiar with? Commons Logging looks > like > its coming to its end, no one really likes java.util.logging, so how about > SLF4J, its really easy and nice to use? > > I also think exception handling could be improved, I don't find the > current > exception formatter design easy to use, and most times stack traces end up > missing the important bit of information you need. How about just using > the > traditional way of putting everything in the exception message and using > properties files to allow for I18N? > > One thing I've wondered about was having a release specifically targeting > these RAS type features. So once we've worked out the strategy for > logging, > exceptions, internationalization etc we have a release where a big focus > is > on implementing/fixing/testing all these RAS things. > >...ant >
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
Hi, I created a prototype to play with aop-based logging and tracing. The annotation-style aspect development seems to be simpler as it doesn't require the aspectj compiler. You can see the code at: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/rfeng/aop-logging You can download aspectj 1.5.3 from http://www.eclipse.org/downloads/download.php?file=/tools/aspectj/aspectj-1.5.3.jar and then run the prototype using "test.bat" in the root of the project. Thanks, Raymond - Original Message - From: "Raymond Feng" <[EMAIL PROTECTED]> To: Sent: Wednesday, April 18, 2007 10:49 AM Subject: Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions) Hi, Please see my comments below. Thanks, Raymond - Original Message - From: "ant elder" <[EMAIL PROTECTED]> To: Sent: Wednesday, April 18, 2007 3:51 AM Subject: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions) On 4/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I found our current Monitor stuff difficult to follow as well. I suggest that we start a new discussion thread to discuss monitoring in general, and try to come up with something that will be more usable and easier to adopt through our whole runtime. Starting the new thread for you... I agree we should improve monitoring and logging in the runtime. I've used AOP before for this type of thing, its cool, but it does add yet another new thing to know about which could be off putting for new developers. How about just using one of the existing logging packages that most people are already completely familiar with? Commons Logging looks like its coming to its end, no one really likes java.util.logging, so how about SLF4J, its really easy and nice to use? I personally don't like the Commons Logging approach very much due to the fact that conflicting versions are used by many 3rd party artifacts. With regard to AOP, do we really need to have all the developers learn how to use it? I assume we can put together some logging aspects in a separate module to take care of most of the logging/monitoring concerns. Other modules are not even aware of the existence of the AOP. Isn't it the objective of AOP to address the cross-cutting concerns without poluting the code? I also think exception handling could be improved, I don't find the current exception formatter design easy to use, and most times stack traces end up missing the important bit of information you need. How about just using the traditional way of putting everything in the exception message and using properties files to allow for I18N? I think we might be able to improve the ExceptionFormatter by providing a default formatter which could dump out all the information in the exception object. We already have a similar function in "org.apache.tuscany.assembly.util.PrintUtil" and we could further enhance it. To support I18N, we could adopt a pattern for the exception so that a getter or a field can be recoginzed as the message id. One thing I've wondered about was having a release specifically targeting these RAS type features. So once we've worked out the strategy for logging, exceptions, internationalization etc we have a release where a big focus is on implementing/fixing/testing all these RAS things. +1. Enabling RAS is a big effort. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
Is SLF4J a better route than Log4j? If so, I wonder if we should convert over the RDB DAS. On 4/18/07, ant elder <[EMAIL PROTECTED]> wrote: On 4/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I found our current Monitor stuff difficult to follow as well. I suggest > that we start a new discussion thread to discuss monitoring in general, > and try to come up with something that will be more usable and easier to > adopt through our whole runtime. Starting the new thread for you... I agree we should improve monitoring and logging in the runtime. I've used AOP before for this type of thing, its cool, but it does add yet another new thing to know about which could be off putting for new developers. How about just using one of the existing logging packages that most people are already completely familiar with? Commons Logging looks like its coming to its end, no one really likes java.util.logging, so how about SLF4J, its really easy and nice to use? I also think exception handling could be improved, I don't find the current exception formatter design easy to use, and most times stack traces end up missing the important bit of information you need. How about just using the traditional way of putting everything in the exception message and using properties files to allow for I18N? One thing I've wondered about was having a release specifically targeting these RAS type features. So once we've worked out the strategy for logging, exceptions, internationalization etc we have a release where a big focus is on implementing/fixing/testing all these RAS things. ...ant
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
Hi, Please see my comments below. Thanks, Raymond - Original Message - From: "ant elder" <[EMAIL PROTECTED]> To: Sent: Wednesday, April 18, 2007 3:51 AM Subject: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions) On 4/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I found our current Monitor stuff difficult to follow as well. I suggest that we start a new discussion thread to discuss monitoring in general, and try to come up with something that will be more usable and easier to adopt through our whole runtime. Starting the new thread for you... I agree we should improve monitoring and logging in the runtime. I've used AOP before for this type of thing, its cool, but it does add yet another new thing to know about which could be off putting for new developers. How about just using one of the existing logging packages that most people are already completely familiar with? Commons Logging looks like its coming to its end, no one really likes java.util.logging, so how about SLF4J, its really easy and nice to use? I personally don't like the Commons Logging approach very much due to the fact that conflicting versions are used by many 3rd party artifacts. With regard to AOP, do we really need to have all the developers learn how to use it? I assume we can put together some logging aspects in a separate module to take care of most of the logging/monitoring concerns. Other modules are not even aware of the existence of the AOP. Isn't it the objective of AOP to address the cross-cutting concerns without poluting the code? I also think exception handling could be improved, I don't find the current exception formatter design easy to use, and most times stack traces end up missing the important bit of information you need. How about just using the traditional way of putting everything in the exception message and using properties files to allow for I18N? I think we might be able to improve the ExceptionFormatter by providing a default formatter which could dump out all the information in the exception object. We already have a similar function in "org.apache.tuscany.assembly.util.PrintUtil" and we could further enhance it. To support I18N, we could adopt a pattern for the exception so that a getter or a field can be recoginzed as the message id. One thing I've wondered about was having a release specifically targeting these RAS type features. So once we've worked out the strategy for logging, exceptions, internationalization etc we have a release where a big focus is on implementing/fixing/testing all these RAS things. +1. Enabling RAS is a big effort. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
Ant Replies in line On 4/18/07, ant elder <[EMAIL PROTECTED]> wrote: On 4/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I found our current Monitor stuff difficult to follow as well. I suggest > that we start a new discussion thread to discuss monitoring in general, > and try to come up with something that will be more usable and easier to > adopt through our whole runtime. Starting the new thread for you... I agree we should improve monitoring and logging in the runtime. I've used AOP before for this type of thing, its cool, but it does add yet another new thing to know about which could be off putting for new developers. How about just using one of the existing logging packages that most people are already completely familiar with? Commons Logging looks like its coming to its end, no one really likes java.util.logging, so how about SLF4J, its really easy and nice to use? Simple is good. I've not done much with Aspects but we could really do with keeping down the complexity quotient I think. I'm keen that whatever information we put out can be transported to whatever management solution is used in the future so having a facade for accepting logged information sounds good. We can start off with a simple console logger and migrate to more complex distributed managment/logging solutions if required in the future. I also think exception handling could be improved, I don't find the current exception formatter design easy to use, and most times stack traces end up missing the important bit of information you need. How about just using the traditional way of putting everything in the exception message and using properties files to allow for I18N? I agree that I find the current exception messages lacking but I have to admit to not having studied how they are implemented so I'll go take a look and come back on this one. One thing I've wondered about was having a release specifically targeting these RAS type features. So once we've worked out the strategy for logging, exceptions, internationalization etc we have a release where a big focus is on implementing/fixing/testing all these RAS things. +1 I'm stringly in favour of this and would very much like to help out. Even if it's not all of the community if a few of us can take a sweep through the code and get the level of error reporting/logging up a notch then that's going to improve our usability no end. People don't expect the software to be perfect but if it fails and doesn't give any clues in lots of cases that that gives a bad impression. This is particulalry the case when the failure is down to user input. So we need to be really careful about loading the assembly model and loading extensions to report any detected inconsistencies in a easy to understand manner. ...ant Simon
Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
On 4/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I found our current Monitor stuff difficult to follow as well. I suggest that we start a new discussion thread to discuss monitoring in general, and try to come up with something that will be more usable and easier to adopt through our whole runtime. Starting the new thread for you... I agree we should improve monitoring and logging in the runtime. I've used AOP before for this type of thing, its cool, but it does add yet another new thing to know about which could be off putting for new developers. How about just using one of the existing logging packages that most people are already completely familiar with? Commons Logging looks like its coming to its end, no one really likes java.util.logging, so how about SLF4J, its really easy and nice to use? I also think exception handling could be improved, I don't find the current exception formatter design easy to use, and most times stack traces end up missing the important bit of information you need. How about just using the traditional way of putting everything in the exception message and using properties files to allow for I18N? One thing I've wondered about was having a release specifically targeting these RAS type features. So once we've worked out the strategy for logging, exceptions, internationalization etc we have a release where a big focus is on implementing/fixing/testing all these RAS things. ...ant
