RE: Monitoring, logging and exceptions (again)
I believe we would still need spring, AOP, and dynamic interface introduction is something best left out of the scope of Tuscany, I would rather see Tuscany focus on different binding containers, transactional support, and other implementations of the SCA specification. Jeff From: shaoguang geng [mailto:[EMAIL PROTECTED] Sent: Wed 2007-08-15 22:37 To: tuscany-user@ws.apache.org Subject: Re: Monitoring, logging and exceptions (again) Me too, read this as a very valuable. Something else, I want to say here: Tuscany is doing things no more than Spring infact, It's nothing but standard. To boost Tuscany, we have a lot of works to do, one of the most is TRANSACTION support. Bind Tuscnay with Spring together is not something smart to me, if Tuscany has transaction support, I think Anderson would not need Spring any more. Nice day. Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Anderson, Jeff T (CA - Toronto) wrote: > Shore, > I am currently leading a team working for a large Canadian financial services > institution to develop what is going to be there standardized SOA platform > going forward. Currently we are supporting a number of international banking > initiatives, with domestic and other channels coming aboard within this in > the next fiscal year. We plan to go in production with Tuscany within the > next couple of months. We have done fairly rigorous performance testing > > When shopping around for the right technology to help support this > initiative, we were careful to look at anything that would help us to support > a "business centric/POJO" programming model. In other words, we didn't want > infrastructure/plumbing code intermingled with our business logic, even on > the inheritance level. > > The two technologies that seem to best serve our purposes was > 1) Tuscany/SCA with its ability to inject services as well as various binding > technologies, > 2) Spring for its IOC/AOP support. > > We've done some fairly rigorous performance testing on the Tuscany/Spring > mix, and are getting very good results. (Tomcat/Windows and > websphere/Solaris) > Once finished we would be happy to publish. > > One of the major things currently impacting our ability to deliver a truly > integrated service assembly model is that we are running into limitations in > terms of spring binding support from Tuscany. We are currently just using a > pogo binding that calls a spring adapter, simply just a Java class that > implements the service interface, invokes the application context and then > delegates to the actual service implementation which is a Spring bean. > > Once the spring binding improves, we will probably be the first to jump on > it, we are also considering contributing to the current spring binding > implementation, but our development cycles are fairly packed with > implementing service platform features which we have mostly done using Spring > aspects. These features include service caching, service logging, service > validation , and service error handling. We use Spring AOP to declaratively > inject these lifecycle features, and use Spring introductions to dynamically > introduce common interfaces to service requests and service response objects > currently being generated by Tuscany SDO. > > In the coming months we will try to put a bit of a case study together, and > submit it up to the Tuscany wiki. > Regards > Jeff > > Hi Jeff, Good input. Thanks! Would you mind opening JIRAs to report the technical limitations you've run into with the current Spring implementation extension? We are about to put the next release together and if you do this soon we may be able to address some of them before we release. Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. - ** Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank you. Information confidentielle: Le présent message, ainsi que
Re: Monitoring, logging and exceptions (again)
Me too, read this as a very valuable. Something else, I want to say here: Tuscany is doing things no more than Spring infact, It's nothing but standard. To boost Tuscany, we have a lot of works to do, one of the most is TRANSACTION support. Bind Tuscnay with Spring together is not something smart to me, if Tuscany has transaction support, I think Anderson would not need Spring any more. Nice day. Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Anderson, Jeff T (CA - Toronto) wrote: > Shore, > I am currently leading a team working for a large Canadian financial services > institution to develop what is going to be there standardized SOA platform > going forward. Currently we are supporting a number of international banking > initiatives, with domestic and other channels coming aboard within this in > the next fiscal year. We plan to go in production with Tuscany within the > next couple of months. We have done fairly rigorous performance testing > > When shopping around for the right technology to help support this > initiative, we were careful to look at anything that would help us to support > a "business centric/POJO" programming model. In other words, we didn't want > infrastructure/plumbing code intermingled with our business logic, even on > the inheritance level. > > The two technologies that seem to best serve our purposes was > 1) Tuscany/SCA with its ability to inject services as well as various binding > technologies, > 2) Spring for its IOC/AOP support. > > We've done some fairly rigorous performance testing on the Tuscany/Spring > mix, and are getting very good results. (Tomcat/Windows and > websphere/Solaris) > Once finished we would be happy to publish. > > One of the major things currently impacting our ability to deliver a truly > integrated service assembly model is that we are running into limitations in > terms of spring binding support from Tuscany. We are currently just using a > pogo binding that calls a spring adapter, simply just a Java class that > implements the service interface, invokes the application context and then > delegates to the actual service implementation which is a Spring bean. > > Once the spring binding improves, we will probably be the first to jump on > it, we are also considering contributing to the current spring binding > implementation, but our development cycles are fairly packed with > implementing service platform features which we have mostly done using Spring > aspects. These features include service caching, service logging, service > validation , and service error handling. We use Spring AOP to declaratively > inject these lifecycle features, and use Spring introductions to dynamically > introduce common interfaces to service requests and service response objects > currently being generated by Tuscany SDO. > > In the coming months we will try to put a bit of a case study together, and > submit it up to the Tuscany wiki. > Regards > Jeff > > Hi Jeff, Good input. Thanks! Would you mind opening JIRAs to report the technical limitations you've run into with the current Spring implementation extension? We are about to put the next release together and if you do this soon we may be able to address some of them before we release. Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.
RE: Monitoring, logging and exceptions (again)
absolutely , I will forward this to our lead developer, so that he may input into the jira, as she is more aware of the exact limitations we are running into with the current spring binding. Regards Jeff From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: Wed 2007-08-15 01:19 To: tuscany-user@ws.apache.org Subject: Re: Monitoring, logging and exceptions (again) Anderson, Jeff T (CA - Toronto) wrote: > Shore, > I am currently leading a team working for a large Canadian financial services > institution to develop what is going to be there standardized SOA platform > going forward. Currently we are supporting a number of international banking > initiatives, with domestic and other channels coming aboard within this in > the next fiscal year. We plan to go in production with Tuscany within the > next couple of months. We have done fairly rigorous performance testing > > When shopping around for the right technology to help support this > initiative, we were careful to look at anything that would help us to support > a "business centric/POJO" programming model. In other words, we didn't want > infrastructure/plumbing code intermingled with our business logic, even on > the inheritance level. > > The two technologies that seem to best serve our purposes was > 1) Tuscany/SCA with its ability to inject services as well as various binding > technologies, > 2) Spring for its IOC/AOP support. > > We've done some fairly rigorous performance testing on the Tuscany/Spring > mix, and are getting very good results. (Tomcat/Windows and > websphere/Solaris) > Once finished we would be happy to publish. > > One of the major things currently impacting our ability to deliver a truly > integrated service assembly model is that we are running into limitations in > terms of spring binding support from Tuscany. We are currently just using a > pogo binding that calls a spring adapter, simply just a Java class that > implements the service interface, invokes the application context and then > delegates to the actual service implementation which is a Spring bean. > > Once the spring binding improves, we will probably be the first to jump on > it, we are also considering contributing to the current spring binding > implementation, but our development cycles are fairly packed with > implementing service platform features which we have mostly done using Spring > aspects. These features include service caching, service logging, service > validation , and service error handling. We use Spring AOP to declaratively > inject these lifecycle features, and use Spring introductions to dynamically > introduce common interfaces to service requests and service response objects > currently being generated by Tuscany SDO. > > In the coming months we will try to put a bit of a case study together, and > submit it up to the Tuscany wiki. > Regards > Jeff > > Hi Jeff, Good input. Thanks! Would you mind opening JIRAs to report the technical limitations you've run into with the current Spring implementation extension? We are about to put the next release together and if you do this soon we may be able to address some of them before we release. Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - ** Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank you. Information confidentielle: Le présent message, ainsi que tout fichier qui y est joint, est envoyé à l'intention exclusive de son ou de ses destinataires; il est de nature confidentielle et peut constituer une information privilégiée. Nous avertissons toute personne autre que le destinataire prévu que tout examen, réacheminement, impression, copie, distribution ou autre utilisation de ce message et de tout fichier qui y est joint est strictement interdit. Si vous n'êtes pas le destinataire prévu, veuillez en aviser immédiatement l'expéditeur par retour de courriel et supprimer ce message et tout document joint de votre système. Merci. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging and exceptions (again)
Anderson, Jeff T (CA - Toronto) wrote: Shore, I am currently leading a team working for a large Canadian financial services institution to develop what is going to be there standardized SOA platform going forward. Currently we are supporting a number of international banking initiatives, with domestic and other channels coming aboard within this in the next fiscal year. We plan to go in production with Tuscany within the next couple of months. We have done fairly rigorous performance testing When shopping around for the right technology to help support this initiative, we were careful to look at anything that would help us to support a "business centric/POJO" programming model. In other words, we didn't want infrastructure/plumbing code intermingled with our business logic, even on the inheritance level. The two technologies that seem to best serve our purposes was 1) Tuscany/SCA with its ability to inject services as well as various binding technologies, 2) Spring for its IOC/AOP support. We've done some fairly rigorous performance testing on the Tuscany/Spring mix, and are getting very good results. (Tomcat/Windows and websphere/Solaris) Once finished we would be happy to publish. One of the major things currently impacting our ability to deliver a truly integrated service assembly model is that we are running into limitations in terms of spring binding support from Tuscany. We are currently just using a pogo binding that calls a spring adapter, simply just a Java class that implements the service interface, invokes the application context and then delegates to the actual service implementation which is a Spring bean. Once the spring binding improves, we will probably be the first to jump on it, we are also considering contributing to the current spring binding implementation, but our development cycles are fairly packed with implementing service platform features which we have mostly done using Spring aspects. These features include service caching, service logging, service validation , and service error handling. We use Spring AOP to declaratively inject these lifecycle features, and use Spring introductions to dynamically introduce common interfaces to service requests and service response objects currently being generated by Tuscany SDO. In the coming months we will try to put a bit of a case study together, and submit it up to the Tuscany wiki. Regards Jeff Hi Jeff, Good input. Thanks! Would you mind opening JIRAs to report the technical limitations you've run into with the current Spring implementation extension? We are about to put the next release together and if you do this soon we may be able to address some of them before we release. Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Monitoring, logging and exceptions (again)
Shore,
I am currently leading a team working for a large Canadian financial services
institution to develop what is going to be there standardized SOA platform
going forward. Currently we are supporting a number of international banking
initiatives, with domestic and other channels coming aboard within this in the
next fiscal year. We plan to go in production with Tuscany within the next
couple of months. We have done fairly rigorous performance testing
When shopping around for the right technology to help support this initiative,
we were careful to look at anything that would help us to support a "business
centric/POJO" programming model. In other words, we didn't want
infrastructure/plumbing code intermingled with our business logic, even on the
inheritance level.
The two technologies that seem to best serve our purposes was
1) Tuscany/SCA with its ability to inject services as well as various binding
technologies,
2) Spring for its IOC/AOP support.
We've done some fairly rigorous performance testing on the Tuscany/Spring mix,
and are getting very good results. (Tomcat/Windows and websphere/Solaris)
Once finished we would be happy to publish.
One of the major things currently impacting our ability to deliver a truly
integrated service assembly model is that we are running into limitations in
terms of spring binding support from Tuscany. We are currently just using a
pogo binding that calls a spring adapter, simply just a Java class that
implements the service interface, invokes the application context and then
delegates to the actual service implementation which is a Spring bean.
Once the spring binding improves, we will probably be the first to jump on it,
we are also considering contributing to the current spring binding
implementation, but our development cycles are fairly packed with implementing
service platform features which we have mostly done using Spring aspects.
These features include service caching, service logging, service validation ,
and service error handling. We use Spring AOP to declaratively inject these
lifecycle features, and use Spring introductions to dynamically introduce
common interfaces to service requests and service response objects currently
being generated by Tuscany SDO.
In the coming months we will try to put a bit of a case study together, and
submit it up to the Tuscany wiki.
Regards
Jeff
From: Raymond Feng [mailto:[EMAIL PROTECTED]
Sent: Tue 2007-08-14 13:34
To: tuscany-user@ws.apache.org
Subject: Re: Monitoring, logging and exceptions (again)
Hi,
Would you like to share your experience with us? It will be very helpful.
Thanks,
Raymond
- Original Message -
From: "Anderson, Jeff T (CA - Toronto)" <[EMAIL PROTECTED]>
To: ;
Sent: Tuesday, August 14, 2007 9:47 AM
Subject: RE: Monitoring, logging and exceptions (again)
We are using Tuscany integrated with spring to provide aspects for logging
and exception management.
I agree that AOP is the ideal approach for these kinds of pieces of
functionality. IMHO I would rather see Tuscany leverage Spring AOP then
start developing its own aspect functionality from scratch
regards
Jeff
From: Raymond Feng [mailto:[EMAIL PROTECTED]
Sent: Tue 2007-08-14 12:23
To: tuscany-user@ws.apache.org
Subject: Re: Monitoring, logging and exceptions (again)
Hi,
I think we have three categories in this area:
1) Monitoring: Listen on the events generated by Tuscany, for example, a
component is started or stopped. (Target for management interfaces)
2) Logging: Produce end-user readable information (info/warning/error) which
is subject to I18N/L10N. (Target for end-users)
3) Tracing: Dump out input/output/exception for method calls for the purpose
of debugging/troubleshooting. (Target for developers/technical support)
IMO, we can cover 2) & 3) using AOP.
AOP-based tracing is obvious. It's simple to define pointcuts to trap all
the methods of interest and dump out the input/output/exception data.
@Pointcut("call(* org.apache.tuscany.sca..*(..))")
Logging is a bit tricky because we will need to know what method calls are
meant to be logging. We could use a Logger (for example,
org.apache.tuscany.sca.logging.Logger or just the pure
java.util.logging.Logger) in the code where logging is desired.
Logger logger = ...;// By default, the logging is no-op
logger.info(msgID, param...); // The code will be instrumented by an aspect
if logging is desired
Then we can create an aspect to trap the following pattern (any logging
calls within the Tuscany code).
@Pointcut("call(* org.apache.tuscany.sca.logging.Logger.*(..))")
Thanks,
Raymond
- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "tuscany-user"
Sent: Friday, August 10, 2007 2:41 PM
Subj
Re: Monitoring, logging and exceptions (again)
Hi,
Would you like to share your experience with us? It will be very helpful.
Thanks,
Raymond
- Original Message -
From: "Anderson, Jeff T (CA - Toronto)" <[EMAIL PROTECTED]>
To: ;
Sent: Tuesday, August 14, 2007 9:47 AM
Subject: RE: Monitoring, logging and exceptions (again)
We are using Tuscany integrated with spring to provide aspects for logging
and exception management.
I agree that AOP is the ideal approach for these kinds of pieces of
functionality. IMHO I would rather see Tuscany leverage Spring AOP then
start developing its own aspect functionality from scratch
regards
Jeff
From: Raymond Feng [mailto:[EMAIL PROTECTED]
Sent: Tue 2007-08-14 12:23
To: tuscany-user@ws.apache.org
Subject: Re: Monitoring, logging and exceptions (again)
Hi,
I think we have three categories in this area:
1) Monitoring: Listen on the events generated by Tuscany, for example, a
component is started or stopped. (Target for management interfaces)
2) Logging: Produce end-user readable information (info/warning/error) which
is subject to I18N/L10N. (Target for end-users)
3) Tracing: Dump out input/output/exception for method calls for the purpose
of debugging/troubleshooting. (Target for developers/technical support)
IMO, we can cover 2) & 3) using AOP.
AOP-based tracing is obvious. It's simple to define pointcuts to trap all
the methods of interest and dump out the input/output/exception data.
@Pointcut("call(* org.apache.tuscany.sca..*(..))")
Logging is a bit tricky because we will need to know what method calls are
meant to be logging. We could use a Logger (for example,
org.apache.tuscany.sca.logging.Logger or just the pure
java.util.logging.Logger) in the code where logging is desired.
Logger logger = ...;// By default, the logging is no-op
logger.info(msgID, param...); // The code will be instrumented by an aspect
if logging is desired
Then we can create an aspect to trap the following pattern (any logging
calls within the Tuscany code).
@Pointcut("call(* org.apache.tuscany.sca.logging.Logger.*(..))")
Thanks,
Raymond
- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "tuscany-user"
Sent: Friday, August 10, 2007 2:41 PM
Subject: Re: Monitoring, logging and exceptions (again)
Simon Laws wrote:
On 8/8/07, ant elder <[EMAIL PROTECTED]> wrote:
On 8/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
We talked about this before (
http://www.mail-archive.com/[EMAIL PROTECTED]/msg16784.html)
but
didn't come to any conclusions. So,
1/ What is the requirement?
2/ What is the technical solution?
3/ When should we try and get it done?
To get things going again here are some thoughts drawn from what was
said
in
the referenced thread.
1/ An API in line with accepted logging/management practices to support
arbitrary debugging and runtime info, warning and error logging
A common approach to exception/error handling specifically around
the
detail recorded in the error messages
Internationalization/localization
Execution Tracing
2/ Keeping it simple was a popular sentiment
A number of java logging solutions have been proposed Log4J, SLF4J
etc.
I believe DAS is using Log4J.
We have dependencies that also use logging tools. We can take a
look
at how others approach this, e.g, quick glance at the last CxF release
shows
they include SLF4J jars
Aspects were investigated to show how they can be used for tracing,
seems like an interesting optional facility but adds extra
complexity/dependencies
There was also a suggestion that we could implement some higher
level
tracing, e.g. runtime starts, stops, application loading, component
instance
creation etc.
We need to move error message out of the code and into resource
files
3/ I think we can reasonably expect to agree what approach we are going
to
take fairly quickly and provide some examples, i.e. before the next
release?
People suggested before that we take time out to go through the
code
based and bring it into line. This will take a lot of time but can we
get
it
into 1.0?
Please add your thoughts to the list and we can then draw them
together,
try
some of it out and come to some conclusions.
Simon
+1 for going with SLF4J. If we can decide on this soon then we can all
just
start adding it in to the code we're working on and debugging, and then
maybe have a focused sweep before 1.0 to make sure its in everywhere
useful.
...ant
Cross posting to the user list also as I expect this is close to everyone
heart. Can everyone reply to both lists.
Thanks
Simon
We had a similar discussion in April [1].
Here's what I suggest for logging:
- Separate the trace calls from the runtime code. Insert them
automatically at build time or run time using Aspectj. Raymond on S
RE: Monitoring, logging and exceptions (again)
We are using Tuscany integrated with spring to provide aspects for logging and
exception management.
I agree that AOP is the ideal approach for these kinds of pieces of
functionality. IMHO I would rather see Tuscany leverage Spring AOP then start
developing its own aspect functionality from scratch
regards
Jeff
From: Raymond Feng [mailto:[EMAIL PROTECTED]
Sent: Tue 2007-08-14 12:23
To: tuscany-user@ws.apache.org
Subject: Re: Monitoring, logging and exceptions (again)
Hi,
I think we have three categories in this area:
1) Monitoring: Listen on the events generated by Tuscany, for example, a
component is started or stopped. (Target for management interfaces)
2) Logging: Produce end-user readable information (info/warning/error) which
is subject to I18N/L10N. (Target for end-users)
3) Tracing: Dump out input/output/exception for method calls for the purpose
of debugging/troubleshooting. (Target for developers/technical support)
IMO, we can cover 2) & 3) using AOP.
AOP-based tracing is obvious. It's simple to define pointcuts to trap all
the methods of interest and dump out the input/output/exception data.
@Pointcut("call(* org.apache.tuscany.sca..*(..))")
Logging is a bit tricky because we will need to know what method calls are
meant to be logging. We could use a Logger (for example,
org.apache.tuscany.sca.logging.Logger or just the pure
java.util.logging.Logger) in the code where logging is desired.
Logger logger = ...;// By default, the logging is no-op
logger.info(msgID, param...); // The code will be instrumented by an aspect
if logging is desired
Then we can create an aspect to trap the following pattern (any logging
calls within the Tuscany code).
@Pointcut("call(* org.apache.tuscany.sca.logging.Logger.*(..))")
Thanks,
Raymond
- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "tuscany-user"
Sent: Friday, August 10, 2007 2:41 PM
Subject: Re: Monitoring, logging and exceptions (again)
> Simon Laws wrote:
>> On 8/8/07, ant elder <[EMAIL PROTECTED]> wrote:
>>
>>> On 8/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>>>
>>>> We talked about this before (
>>>> http://www.mail-archive.com/[EMAIL PROTECTED]/msg16784.html)
>>>> but
>>>> didn't come to any conclusions. So,
>>>>
>>>> 1/ What is the requirement?
>>>> 2/ What is the technical solution?
>>>> 3/ When should we try and get it done?
>>>>
>>>> To get things going again here are some thoughts drawn from what was
>>>>
>>> said
>>>
>>>> in
>>>> the referenced thread.
>>>>
>>>> 1/ An API in line with accepted logging/management practices to support
>>>> arbitrary debugging and runtime info, warning and error logging
>>>> A common approach to exception/error handling specifically around
>>>>
>>> the
>>>
>>>> detail recorded in the error messages
>>>> Internationalization/localization
>>>> Execution Tracing
>>>>
>>>> 2/ Keeping it simple was a popular sentiment
>>>> A number of java logging solutions have been proposed Log4J, SLF4J
>>>> etc.
>>>>I believe DAS is using Log4J.
>>>>We have dependencies that also use logging tools. We can take a
>>>> look
>>>> at how others approach this, e.g, quick glance at the last CxF release
>>>> shows
>>>> they include SLF4J jars
>>>> Aspects were investigated to show how they can be used for tracing,
>>>> seems like an interesting optional facility but adds extra
>>>> complexity/dependencies
>>>> There was also a suggestion that we could implement some higher
>>>>
>>> level
>>>
>>>> tracing, e.g. runtime starts, stops, application loading, component
>>>> instance
>>>> creation etc.
>>>> We need to move error message out of the code and into resource
>>>>
>>> files
>>>
>>>> 3/ I think we can reasonably expect to agree what approach we are going
>>>>
>>> to
>>>
>>>> take fairly quickly and provide some examples, i.e. before the next
>>>> release?
>>>> People suggested before that we take time out to go through the
>>>> code
>>>> based and bring it into line. This will take a lot of time but can we
>>>>
>>> get
>>>
>>>> it
>>>> into
Re: Monitoring, logging and exceptions (again)
Hi,
I think we have three categories in this area:
1) Monitoring: Listen on the events generated by Tuscany, for example, a
component is started or stopped. (Target for management interfaces)
2) Logging: Produce end-user readable information (info/warning/error) which
is subject to I18N/L10N. (Target for end-users)
3) Tracing: Dump out input/output/exception for method calls for the purpose
of debugging/troubleshooting. (Target for developers/technical support)
IMO, we can cover 2) & 3) using AOP.
AOP-based tracing is obvious. It's simple to define pointcuts to trap all
the methods of interest and dump out the input/output/exception data.
@Pointcut("call(* org.apache.tuscany.sca..*(..))")
Logging is a bit tricky because we will need to know what method calls are
meant to be logging. We could use a Logger (for example,
org.apache.tuscany.sca.logging.Logger or just the pure
java.util.logging.Logger) in the code where logging is desired.
Logger logger = ...;// By default, the logging is no-op
logger.info(msgID, param...); // The code will be instrumented by an aspect
if logging is desired
Then we can create an aspect to trap the following pattern (any logging
calls within the Tuscany code).
@Pointcut("call(* org.apache.tuscany.sca.logging.Logger.*(..))")
Thanks,
Raymond
- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "tuscany-user"
Sent: Friday, August 10, 2007 2:41 PM
Subject: Re: Monitoring, logging and exceptions (again)
Simon Laws wrote:
On 8/8/07, ant elder <[EMAIL PROTECTED]> wrote:
On 8/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
We talked about this before (
http://www.mail-archive.com/[EMAIL PROTECTED]/msg16784.html)
but
didn't come to any conclusions. So,
1/ What is the requirement?
2/ What is the technical solution?
3/ When should we try and get it done?
To get things going again here are some thoughts drawn from what was
said
in
the referenced thread.
1/ An API in line with accepted logging/management practices to support
arbitrary debugging and runtime info, warning and error logging
A common approach to exception/error handling specifically around
the
detail recorded in the error messages
Internationalization/localization
Execution Tracing
2/ Keeping it simple was a popular sentiment
A number of java logging solutions have been proposed Log4J, SLF4J
etc.
I believe DAS is using Log4J.
We have dependencies that also use logging tools. We can take a
look
at how others approach this, e.g, quick glance at the last CxF release
shows
they include SLF4J jars
Aspects were investigated to show how they can be used for tracing,
seems like an interesting optional facility but adds extra
complexity/dependencies
There was also a suggestion that we could implement some higher
level
tracing, e.g. runtime starts, stops, application loading, component
instance
creation etc.
We need to move error message out of the code and into resource
files
3/ I think we can reasonably expect to agree what approach we are going
to
take fairly quickly and provide some examples, i.e. before the next
release?
People suggested before that we take time out to go through the
code
based and bring it into line. This will take a lot of time but can we
get
it
into 1.0?
Please add your thoughts to the list and we can then draw them
together,
try
some of it out and come to some conclusions.
Simon
+1 for going with SLF4J. If we can decide on this soon then we can all
just
start adding it in to the code we're working on and debugging, and then
maybe have a focused sweep before 1.0 to make sure its in everywhere
useful.
...ant
Cross posting to the user list also as I expect this is close to everyone
heart. Can everyone reply to both lists.
Thanks
Simon
We had a similar discussion in April [1].
Here's what I suggest for logging:
- Separate the trace calls from the runtime code. Insert them
automatically at build time or run time using Aspectj. Raymond on SCA and
Kelvin on SDO already showed how to do it.
- Use SLF4J in these generated trace calls.
[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL
PROTECTED]
Thoughts?
--
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 (again)
Simon Laws wrote: On 8/8/07, ant elder <[EMAIL PROTECTED]> wrote: On 8/7/07, Simon Laws <[EMAIL PROTECTED]> wrote: We talked about this before ( http://www.mail-archive.com/[EMAIL PROTECTED]/msg16784.html) but didn't come to any conclusions. So, 1/ What is the requirement? 2/ What is the technical solution? 3/ When should we try and get it done? To get things going again here are some thoughts drawn from what was said in the referenced thread. 1/ An API in line with accepted logging/management practices to support arbitrary debugging and runtime info, warning and error logging A common approach to exception/error handling specifically around the detail recorded in the error messages Internationalization/localization Execution Tracing 2/ Keeping it simple was a popular sentiment A number of java logging solutions have been proposed Log4J, SLF4J etc. I believe DAS is using Log4J. We have dependencies that also use logging tools. We can take a look at how others approach this, e.g, quick glance at the last CxF release shows they include SLF4J jars Aspects were investigated to show how they can be used for tracing, seems like an interesting optional facility but adds extra complexity/dependencies There was also a suggestion that we could implement some higher level tracing, e.g. runtime starts, stops, application loading, component instance creation etc. We need to move error message out of the code and into resource files 3/ I think we can reasonably expect to agree what approach we are going to take fairly quickly and provide some examples, i.e. before the next release? People suggested before that we take time out to go through the code based and bring it into line. This will take a lot of time but can we get it into 1.0? Please add your thoughts to the list and we can then draw them together, try some of it out and come to some conclusions. Simon +1 for going with SLF4J. If we can decide on this soon then we can all just start adding it in to the code we're working on and debugging, and then maybe have a focused sweep before 1.0 to make sure its in everywhere useful. ...ant Cross posting to the user list also as I expect this is close to everyone heart. Can everyone reply to both lists. Thanks Simon We had a similar discussion in April [1]. Here's what I suggest for logging: - Separate the trace calls from the runtime code. Insert them automatically at build time or run time using Aspectj. Raymond on SCA and Kelvin on SDO already showed how to do it. - Use SLF4J in these generated trace calls. [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging and exceptions (again)
On 8/8/07, ant elder <[EMAIL PROTECTED]> wrote: > > On 8/7/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > We talked about this before ( > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg16784.html) but > > didn't come to any conclusions. So, > > > > 1/ What is the requirement? > > 2/ What is the technical solution? > > 3/ When should we try and get it done? > > > > To get things going again here are some thoughts drawn from what was > said > > in > > the referenced thread. > > > > 1/ An API in line with accepted logging/management practices to support > > arbitrary debugging and runtime info, warning and error logging > > A common approach to exception/error handling specifically around > the > > detail recorded in the error messages > > Internationalization/localization > > Execution Tracing > > > > 2/ Keeping it simple was a popular sentiment > > A number of java logging solutions have been proposed Log4J, SLF4J > > etc. > >I believe DAS is using Log4J. > >We have dependencies that also use logging tools. We can take a > > look > > at how others approach this, e.g, quick glance at the last CxF release > > shows > > they include SLF4J jars > > Aspects were investigated to show how they can be used for tracing, > > seems like an interesting optional facility but adds extra > > complexity/dependencies > > There was also a suggestion that we could implement some higher > level > > tracing, e.g. runtime starts, stops, application loading, component > > instance > > creation etc. > > We need to move error message out of the code and into resource > files > > > > 3/ I think we can reasonably expect to agree what approach we are going > to > > take fairly quickly and provide some examples, i.e. before the next > > release? > > People suggested before that we take time out to go through the code > > based and bring it into line. This will take a lot of time but can we > get > > it > > into 1.0? > > > > Please add your thoughts to the list and we can then draw them together, > > try > > some of it out and come to some conclusions. > > > > Simon > > > > +1 for going with SLF4J. If we can decide on this soon then we can all > just > start adding it in to the code we're working on and debugging, and then > maybe have a focused sweep before 1.0 to make sure its in everywhere > useful. > >...ant > Cross posting to the user list also as I expect this is close to everyone heart. Can everyone reply to both lists. Thanks Simon
