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)
[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, Please see my comments inline. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org 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: Notifcation of missing extensions
On 4/17/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Comments inline.
Raymond Feng wrote:
Hi,
We might have a few options to make it more elegant:
1) By throwing an exception from the extension point when the key
doesn't hit an entry.
2) The caller will check the null and make a decision on how to proceed.
Option (1) covers critical error cases where it's not possible at all to
proceed with reading the SCA assembly XML document.
I don't like much option (2) as it will leave users and application
developers in the dark...
I'd like to suggest a third option:
- Record problems like we have started to do in CompositeUtil, and
expand on that as discussed in [1].
- After a contribution has been scanned and read, inspect the problems
list and if we find severe problems, throw an exception, report warnings
and benign issues using some form of monitoring and/or logging.
Doing this will allow us to defer the handling of these problems out of
the individual ArtifactProcessors, handle them with more context (as
we'll have the whole list), and overall provide better error reporting
to users and application developers, as we'll be able to present a whole
list instead of throwing up on the first error.
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16554.html
And for the monitoring/logging, we had a monitoring framework (not
completely activated ATM). The basic idea is as follows:
1) The class that supports the monitoring will define an interface for
the monitoring purpose
2) The class use @Monitor annotation to receive an implementation of
the interface by injection
3) A MonitorFactory is responsible to create a Monitor based on the
interface
I found it a bit difficult to follow this pattern as the class itself
have to take care of most of the stuff. Should we explore other
opportunities such as AOP?
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.
Thanks,
Raymond
- Original Message - From: Simon Laws
[EMAIL PROTECTED]
To: tuscany-dev tuscany-dev@ws.apache.org
Sent: Tuesday, April 17, 2007 9:04 AM
Subject: Notifcation of missing extensions
I've been caught out a couple of times now by the runtime silently
failing
to work properly because I haven't put the correct set of extensions
on my
classpath. Locally I have just put a printout in to warn me.
DefaultStAXArtifactProcessorExtensionPoint
public Object read(XMLStreamReader source) throws
ContributionReadException {
// Delegate to the processor associated with the element qname
QName name = source.getName();
StAXArtifactProcessorExtension? processor =
(StAXArtifactProcessorExtension?)this.getProcessor(name);
if (processor == null) {
System.err.print(No extension processor registered for
element
+ name.toString());
return null;
}
return processor.read(source);
}
So that if an element is encountered for which there is no loader I
get to
find out I've made a mistake. So can someone explain how we should be
doing
logging/montoring in the Tuscany runtime as it would be good to
report back
to users that this is happening
Regards
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I agree that getting all of the missing extension problems out in one
pass is preferable. We need to organize the problem list so that it can
collect errors across the the assembly read, resolve and wire phases. Can we
make it a first class citizen of the contribution? I imagine, in the
furture, that as contributions are added/removed from a domain we will want
to collate problems as problems may come and go and have a bearing on how
operable a domain is.
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: snip/ 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)
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: tuscany-dev@ws.apache.org 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: tuscany-dev@ws.apache.org 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: snip/ 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)
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]
Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
On 4/17/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ 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: tuscany-dev@ws.apache.org 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: snip/ 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: snip/ 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: tuscany-dev@ws.apache.org 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: tuscany-dev@ws.apache.org 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: snip/ 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]
Notifcation of missing extensions
I've been caught out a couple of times now by the runtime silently failing
to work properly because I haven't put the correct set of extensions on my
classpath. Locally I have just put a printout in to warn me.
DefaultStAXArtifactProcessorExtensionPoint
public Object read(XMLStreamReader source) throws
ContributionReadException {
// Delegate to the processor associated with the element qname
QName name = source.getName();
StAXArtifactProcessorExtension? processor =
(StAXArtifactProcessorExtension?)this.getProcessor(name);
if (processor == null) {
System.err.print(No extension processor registered for element
+ name.toString());
return null;
}
return processor.read(source);
}
So that if an element is encountered for which there is no loader I get to
find out I've made a mistake. So can someone explain how we should be doing
logging/montoring in the Tuscany runtime as it would be good to report back
to users that this is happening
Regards
Simon
Re: Notifcation of missing extensions
Hi,
We might have a few options to make it more elegant:
1) By throwing an exception from the extension point when the key doesn't
hit an entry.
2) The caller will check the null and make a decision on how to proceed.
And for the monitoring/logging, we had a monitoring framework (not
completely activated ATM). The basic idea is as follows:
1) The class that supports the monitoring will define an interface for the
monitoring purpose
2) The class use @Monitor annotation to receive an implementation of the
interface by injection
3) A MonitorFactory is responsible to create a Monitor based on the
interface
I found it a bit difficult to follow this pattern as the class itself have
to take care of most of the stuff. Should we explore other opportunities
such as AOP?
Thanks,
Raymond
- Original Message -
From: Simon Laws [EMAIL PROTECTED]
To: tuscany-dev tuscany-dev@ws.apache.org
Sent: Tuesday, April 17, 2007 9:04 AM
Subject: Notifcation of missing extensions
I've been caught out a couple of times now by the runtime silently failing
to work properly because I haven't put the correct set of extensions on my
classpath. Locally I have just put a printout in to warn me.
DefaultStAXArtifactProcessorExtensionPoint
public Object read(XMLStreamReader source) throws
ContributionReadException {
// Delegate to the processor associated with the element qname
QName name = source.getName();
StAXArtifactProcessorExtension? processor =
(StAXArtifactProcessorExtension?)this.getProcessor(name);
if (processor == null) {
System.err.print(No extension processor registered for element
+ name.toString());
return null;
}
return processor.read(source);
}
So that if an element is encountered for which there is no loader I get to
find out I've made a mistake. So can someone explain how we should be
doing
logging/montoring in the Tuscany runtime as it would be good to report
back
to users that this is happening
Regards
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
