You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/08/08 18:16:15 UTC
Re: Monitoring, logging and exceptions (again)
On 8/8/07, ant elder <an...@gmail.com> wrote:
>
> On 8/7/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > We talked about this before (
> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/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
Re: Monitoring, logging and exceptions (again)
Posted by Simon Laws <si...@googlemail.com>.
On 8/31/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Simon Laws wrote:
> > On 8/31/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> >> Simon Laws wrote:
> >>
> >>>> What would be put in specific logging properties?
> >>>>
> >>>>
> >>> The usual logging configuration, what we want our default logging
> level
> >>>
> >> to
> >>
> >>> be on a module by module bases, what handlers to use, configuration of
> >>>
> >> the
> >>
> >>> handlers e.g. if it's a file handler where to put the file and what to
> >>>
> >> call
> >>
> >>> it. etc.
> >>>
> >>> I'm using the IBM JDK and that doesn't seem to come with a default
> >>> logging.properties file. We could go with hardcoded defaults but as
> soon
> >>>
> >> as
> >>
> >>> you want to change something it's problematic. We could ask people to
> >>>
> >> drop
> >>
> >>> one into jdk/lib but that would be active for any other java apps they
> >>>
> >> use.
> >>
> >>> Do you know an easy way round this?
> >>>
> >>>
> >>>
> >> I don't know an easy way around this, but I'm still a little confused.
> >> If we define a tuscany-logging properties file then what's going to
> >> happen when we do:
> >>
> >>> LogManager.getLogManager().readConfiguration(<stream for
> >>>
> >> tuscany-logging.properties>);
> >> Isn't that going to reset the logging configuration for the whole
> >> LogManager, altering the log configuration for other projects that use
> >> the JDK logger as well?
> >>
> >> --
> >> Jean-Sebastien
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >> Yes , say if we embed tuscany in some other project and we were to read
> >>
> > the logging.properties file as above we would mess up the settings of
> the
> > embedding application. Thats why we have to be able to remove any
> > configuration we provide, for example, for our samples.
> >
> > Simon
> >
> >
>
> How about not messing up the settings - i.e. not impose or provide a
> configuration properties file - and let the user configure the JDK
> logger the way he wants?
>
> Sometimes not providing anything is better than providing something
> that's going to get in the way, even if we document how to remove the
> obstacle we have created :)
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> I don't think we can get away with providing nothing. Even from a tuscany
developers point of view we are going to want a logging.properties file
checked into svn somewhere and probably some instructions describing what to
do with it.
We could rely on the dropping it into jdk/lib for logging during
development. Not clear that all developers will be happy with that but we
can ask.
We will have to ensure that we get what we need with the default logging
settings for the samples/demos. I could live with that but we need to try to
make sure it's ok.
Simon
Re: Monitoring, logging and exceptions (again)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On 8/31/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
>> Simon Laws wrote:
>>
>>>> What would be put in specific logging properties?
>>>>
>>>>
>>> The usual logging configuration, what we want our default logging level
>>>
>> to
>>
>>> be on a module by module bases, what handlers to use, configuration of
>>>
>> the
>>
>>> handlers e.g. if it's a file handler where to put the file and what to
>>>
>> call
>>
>>> it. etc.
>>>
>>> I'm using the IBM JDK and that doesn't seem to come with a default
>>> logging.properties file. We could go with hardcoded defaults but as soon
>>>
>> as
>>
>>> you want to change something it's problematic. We could ask people to
>>>
>> drop
>>
>>> one into jdk/lib but that would be active for any other java apps they
>>>
>> use.
>>
>>> Do you know an easy way round this?
>>>
>>>
>>>
>> I don't know an easy way around this, but I'm still a little confused.
>> If we define a tuscany-logging properties file then what's going to
>> happen when we do:
>>
>>> LogManager.getLogManager().readConfiguration(<stream for
>>>
>> tuscany-logging.properties>);
>> Isn't that going to reset the logging configuration for the whole
>> LogManager, altering the log configuration for other projects that use
>> the JDK logger as well?
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>> Yes , say if we embed tuscany in some other project and we were to read
>>
> the logging.properties file as above we would mess up the settings of the
> embedding application. Thats why we have to be able to remove any
> configuration we provide, for example, for our samples.
>
> Simon
>
>
How about not messing up the settings - i.e. not impose or provide a
configuration properties file - and let the user configure the JDK
logger the way he wants?
Sometimes not providing anything is better than providing something
that's going to get in the way, even if we document how to remove the
obstacle we have created :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Monitoring, logging and exceptions (again)
Posted by Simon Laws <si...@googlemail.com>.
On 8/31/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Simon Laws wrote:
> >
> >> What would be put in specific logging properties?
> >>
> >
> >
> > The usual logging configuration, what we want our default logging level
> to
> > be on a module by module bases, what handlers to use, configuration of
> the
> > handlers e.g. if it's a file handler where to put the file and what to
> call
> > it. etc.
> >
> > I'm using the IBM JDK and that doesn't seem to come with a default
> > logging.properties file. We could go with hardcoded defaults but as soon
> as
> > you want to change something it's problematic. We could ask people to
> drop
> > one into jdk/lib but that would be active for any other java apps they
> use.
> >
> > Do you know an easy way round this?
> >
> >
>
> I don't know an easy way around this, but I'm still a little confused.
> If we define a tuscany-logging properties file then what's going to
> happen when we do:
> > LogManager.getLogManager().readConfiguration(<stream for
> tuscany-logging.properties>);
> Isn't that going to reset the logging configuration for the whole
> LogManager, altering the log configuration for other projects that use
> the JDK logger as well?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Yes , say if we embed tuscany in some other project and we were to read
the logging.properties file as above we would mess up the settings of the
embedding application. Thats why we have to be able to remove any
configuration we provide, for example, for our samples.
Simon
Re: Monitoring, logging and exceptions (again)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
>
>> What would be put in specific logging properties?
>>
>
>
> The usual logging configuration, what we want our default logging level to
> be on a module by module bases, what handlers to use, configuration of the
> handlers e.g. if it's a file handler where to put the file and what to call
> it. etc.
>
> I'm using the IBM JDK and that doesn't seem to come with a default
> logging.properties file. We could go with hardcoded defaults but as soon as
> you want to change something it's problematic. We could ask people to drop
> one into jdk/lib but that would be active for any other java apps they use.
>
> Do you know an easy way round this?
>
>
I don't know an easy way around this, but I'm still a little confused.
If we define a tuscany-logging properties file then what's going to
happen when we do:
> LogManager.getLogManager().readConfiguration(<stream for tuscany-logging.properties>);
Isn't that going to reset the logging configuration for the whole
LogManager, altering the log configuration for other projects that use
the JDK logger as well?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Monitoring, logging and exceptions (again)
Posted by Simon Laws <si...@googlemail.com>.
On 8/31/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
> Simon Laws wrote:
> >
> >> Ok, so we know there is no generally acceptable logging interface. Has
> >>
> > been proved time and time again. All we can hope to do is use something
> that
> > suits us and doesn't mess up anyone who wants to embed our code.
> >
> > I'm perfectly happy to +1 JDK logging. However without some wrappers to
> do
> > it for us we need to define the ground rules for how we use it.
> >
> > So, in line with what I believe is common practice, how about these...
> >
> > End user readable information is expected to be recorded against the
> > following levels
> > SEVERE
> > WARNING
> > INFO
> > CONFIG
> >
> > The following levels are tracing levels and are assumed to be developer
> > readable only
> > FINE
> > FINER
> > FINEST
> >
>
> +1 from me
>
> > Loggers will be initialized against the class name to which they relate,
> and
> > a resource bundle for the package/or module.
> >
>
> How about leaving the resource-bundle part out for 1.0 and do a pass to
> externalize messages later?
I don't think it's a particularly big job putting in resource bundles but
I'll go with the majority decision if people are concerned about getting if
done in time. We will have to do it at some stage.
> private static final Logger Log = Logger.getLogger(
> > SomeTuscanyClassB.class.getName(), "tuscany-?-messages");
> >
> > We can define some global o.a.t.s loggers if we don't want to have to
> make
> > bundles for all of the non-extension modules, e.g.
> >
> > private static final Logger Log = Logger.getLogger("
> org.apache.tuscany.sca,
> > "tuscany-messages");
> >
>
> Hmm, wouldn't that require changes in the module containing the "global"
> module when an extension wants to change a message?
Only if you don;t specify a bundle for the extension . So the rule shoyuld
be you always provide an bundle for an extension. I was just making the
point that we don't absolutely need a bundle for each modules unless it's
loaded as an extension. However it may be simpler just to say 1 per module
and then it's easier to remember.
> Log statements for user readable messages will take the following form,
> for
> > example,
> >
> > Log.log(Level.INFO,
> > "MESSAGE1");
> >
> > String componentName = "Some component";
> >
> > Log.log(Level.INFO,
> > "MESSAGE2", // message id
> > componentName); // parameter
> >
> > Integer params[] = {8, 9, 4};
> >
> > Log.log(Level.INFO,
> > "MESSAGE3", // message id
> > params); // parameter
> >
> >
> > Exception ex = new IllegalStateException("TEST_MESSAGE");
> >
> > Log.log(Level.INFO,
> > "MESSAGE4", // message id
> > ex); // parameter
> >
> >
> > These messages will be localized against a message bundle from the
> classpath
> > based on the configuration of the Logger (or the Logger's parent), for
> > example, tuscany-messages.properties, tuscany-messages_en.properties
> etc.
> >
> > MESSAGE1 = This is a test message with no params
> > MESSAGE2 = This is a test message with a string param {0}
> > MESSAGE3 = This is a test message with numbers {0}, {1}, {2}
> > MESSAGE4 = This is a test message with exception
> >
>
> +1 for all that, except that again I'll be more comfortable to leave
> externalization to later after 1.0.
Ok , well let's see what people think. As you say not hugely difficult to
go round and hoover up all the messages and convert into bundles.
> Which can of course be provided on an extension by extension basis if
> > required and if specified when the logger is created.
> >
> > Developer readable messages are assumed not to be localized and so can
> be
> > output using the Logger convenience methods.
> >
> > We won't use log.entering and log exiting. This level of tracing will be
> > provided via AspectJ injection.
> >
>
> +1
>
> > I'm assuming we don't want our logging properties to have to live in
> > jdk/lib/logging properties so we need an extensible/replaceable way to
> > initialize logging. e.g.
> >
> > InputStream logConfigStream = Thread.currentThread
> > ().getContextClassLoader().getResourceAsStream("
> tuscany-logging.properties
> > ");
> > LogManager.getLogManager
> ().readConfiguration(logConfigStream);
> > + any other logging configuration that we need
> >
> > Anyone have a good idea where to put this. It should go close to the
> start
> > of our domain/node implementation but would be good if it's replaceable.
> So
> > we could do with a new logging extension type that is one of the first
> > things that gets loaded.
> >
> > Simon
> >
>
> What would be put in specific logging properties?
The usual logging configuration, what we want our default logging level to
be on a module by module bases, what handlers to use, configuration of the
handlers e.g. if it's a file handler where to put the file and what to call
it. etc.
I'm using the IBM JDK and that doesn't seem to come with a default
logging.properties file. We could go with hardcoded defaults but as soon as
you want to change something it's problematic. We could ask people to drop
one into jdk/lib but that would be active for any other java apps they use.
Do you know an easy way round this?
--
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Monitoring, logging and exceptions (again)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Simon Laws wrote:
>
>> Ok, so we know there is no generally acceptable logging interface. Has
>>
> been proved time and time again. All we can hope to do is use something that
> suits us and doesn't mess up anyone who wants to embed our code.
>
> I'm perfectly happy to +1 JDK logging. However without some wrappers to do
> it for us we need to define the ground rules for how we use it.
>
> So, in line with what I believe is common practice, how about these...
>
> End user readable information is expected to be recorded against the
> following levels
> SEVERE
> WARNING
> INFO
> CONFIG
>
> The following levels are tracing levels and are assumed to be developer
> readable only
> FINE
> FINER
> FINEST
>
+1 from me
> Loggers will be initialized against the class name to which they relate, and
> a resource bundle for the package/or module.
>
How about leaving the resource-bundle part out for 1.0 and do a pass to
externalize messages later?
> private static final Logger Log = Logger.getLogger(
> SomeTuscanyClassB.class.getName(), "tuscany-?-messages");
>
> We can define some global o.a.t.s loggers if we don't want to have to make
> bundles for all of the non-extension modules, e.g.
>
> private static final Logger Log = Logger.getLogger("org.apache.tuscany.sca,
> "tuscany-messages");
>
Hmm, wouldn't that require changes in the module containing the "global"
module when an extension wants to change a message?
> Log statements for user readable messages will take the following form, for
> example,
>
> Log.log(Level.INFO,
> "MESSAGE1");
>
> String componentName = "Some component";
>
> Log.log(Level.INFO,
> "MESSAGE2", // message id
> componentName); // parameter
>
> Integer params[] = {8, 9, 4};
>
> Log.log(Level.INFO,
> "MESSAGE3", // message id
> params); // parameter
>
>
> Exception ex = new IllegalStateException("TEST_MESSAGE");
>
> Log.log(Level.INFO,
> "MESSAGE4", // message id
> ex); // parameter
>
>
> These messages will be localized against a message bundle from the classpath
> based on the configuration of the Logger (or the Logger's parent), for
> example, tuscany-messages.properties, tuscany-messages_en.properties etc.
>
> MESSAGE1 = This is a test message with no params
> MESSAGE2 = This is a test message with a string param {0}
> MESSAGE3 = This is a test message with numbers {0}, {1}, {2}
> MESSAGE4 = This is a test message with exception
>
+1 for all that, except that again I'll be more comfortable to leave
externalization to later after 1.0.
> Which can of course be provided on an extension by extension basis if
> required and if specified when the logger is created.
>
> Developer readable messages are assumed not to be localized and so can be
> output using the Logger convenience methods.
>
> We won't use log.entering and log exiting. This level of tracing will be
> provided via AspectJ injection.
>
+1
> I'm assuming we don't want our logging properties to have to live in
> jdk/lib/logging properties so we need an extensible/replaceable way to
> initialize logging. e.g.
>
> InputStream logConfigStream = Thread.currentThread
> ().getContextClassLoader().getResourceAsStream("tuscany-logging.properties
> ");
> LogManager.getLogManager().readConfiguration(logConfigStream);
> + any other logging configuration that we need
>
> Anyone have a good idea where to put this. It should go close to the start
> of our domain/node implementation but would be good if it's replaceable. So
> we could do with a new logging extension type that is one of the first
> things that gets loaded.
>
> Simon
>
What would be put in specific logging properties?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Monitoring, logging and exceptions (again)
Posted by Simon Laws <si...@googlemail.com>.
On 8/29/07, Raymond Feng <en...@gmail.com> wrote:
>
> I just created https://issues.apache.org/jira/browse/TUSCANY-1635 to track
> the aspectj-based tracing.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Jean-Sebastien Delfino" <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Wednesday, August 29, 2007 11:06 AM
> Subject: Re: Monitoring, logging and exceptions (again)
>
>
> > Simon Laws wrote:
> >> On 8/20/07, Simon Laws <si...@googlemail.com> wrote:
> >>
> >>>
> >>> On 8/20/07, Simon Nash <nash@hursley.ibm.com > wrote:
> >>>
> >>>> See inline.
> >>>>
> >>>> Simon
> >>>>
> >>>> Raymond Feng wrote:
> >>>>
> >>>>
> >>>>> Comments inline.
> >>>>>
> >>>>> Thanks,
> >>>>> Raymond
> >>>>>
> >>>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> >>>>> < jsdelfino@apache.org>
> >>>>> To: < tuscany-dev@ws.apache.org>
> >>>>> Sent: Friday, August 17, 2007 9:27 AM
> >>>>> Subject: Re: Monitoring, logging and exceptions (again)
> >>>>>
> >>>>>
> >>>>>
> >>>>>> [snip]
> >>>>>> ant elder wrote:
> >>>>>>
> >>>>>>
> >>>>>>> And also my 2p inline...
> >>>>>>>
> >>>>>>> ...ant
> >>>>>>>
> >>>>>>> On 8/16/07, Simon Laws < simonslaws@googlemail.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> A number of different requirements have been discussed and
> >>>>>>>>
> >>>> solutions
> >>>>
> >>>>>>>> proposed. My 2p (I'm using Raymond's definitions b.t.w)
> >>>>>>>>
> >>>>>>>> Tracing: Dump out input/output/exception for method calls for the
> >>>>>>>> purpose
> >>>>>>>> of
> >>>>>>>> debugging/troubleshooting. (Target for developers/technical
> >>>>>>>>
> >>>> support)
> >>>>
> >>>>>>>> I feel that tracing of execution paths through the Tuscany
> codebase
> >>>>>>>> would
> >>>>>>>> be
> >>>>>>>> useful but agree that " it's a lot of work and will be difficult
> to
> >>>>>>>> maintain
> >>>>>>>> and keep consistent" if we did it manually. I'm happy that this
> is
> >>>>>>>>
> >>>> the
> >>>>
> >>>>>>>> responsibility of whoever wants to trace through the code and not
> a
> >>>>>>>> core
> >>>>>>>> part of the codebase. For the Tuscany developer community AspectJ
> >>>>>>>>
> >>>> have
> >>>>
> >>>>>>>> been
> >>>>>>>> proposed a couple of times and support has been prototyped. We
> >>>>>>>>
> >>>> could
> >>>>
> >>>>>>>> choose
> >>>>>>>> SLF4J as the interface through which messages are output.
> >>>>>>>>
> >>>>>>>>
> >>>>>>> I'm not sure we need to use SLF4J if we go the AspectJ route.
> SLF4J
> >>>>>>>
> >>>> is a
> >>>>
> >>>>>>> facade for logging APIs, so you can code to the SLF4J API and
> then
> >>>>>>> plug in
> >>>>>>> whatever logging impl you like, but if the only logging calls we
> >>>>>>>
> >>>> have
> >>>>
> >>>>>>> are
> >>>>>>> confined to a single tracing aspect we might as well just code
> that
> >>>>>>> aspect
> >>>>>>> to a specific logging API like JDK logging. That avoids the extra
> >>>>>>> dependency
> >>>>>>> on SLF4J and anyone can add additional aspects if they really want
> >>>>>>>
> >>>> to
> >>>>
> >>>>>>> use a
> >>>>>>> different logger. The main other benefit of SLF4J is its
> >>>>>>>
> >>>> parameterized
> >>>>
> >>>>>>> message logging (avoids all the "if(logger.isDebugEnabled())" )
> but
> >>>>>>> again if
> >>>>>>> all the logging calls are in a single aspect thats not so useful.
> >>>>>>>
> >>>>>>>
> >>>>>> Makes sense to me. If we go the aspectj route for tracing method
> >>>>>> entry/exit, I agree that using the JDK logger directly is simpler.
> >>>>>>
> >>>>>>
> >>>>> Since the aspect is on the side, we're flexible. JDK logger can be
> >>>>> default and it can be replaced easily if the embedders or users
> choose
> >>>>> to do so.
> >>>>>
> >>>>>
> >>>>>> A few more questions on this: What dependencies will aspectj add to
> >>>>>> our distribution? aspectjweaver is more than 1Mb, do we need it?
> >>>>>>
> >>>>> I'll try to spend some time to explore both the compile-time and
> >>>>> load-time weaving.
> >>>>>
> >>>>>
> >>>>>>> What about mid-method logging of specific interesting events, for
> >>>>>>> example
> >>>>>>> the contents of requests as the enter and leave bindings and
> >>>>>>> implementation
> >>>>>>> types and things like that? That sort of logging is often all a
> lot
> >>>>>>> of users
> >>>>>>> want to see not the detail tracing of every method entry/exit.
> Could
> >>>>>>> we add
> >>>>>>> things like this in specific places?
> >>>>>>>
> >>>>>>>
> >>>> +1 for the ability to produce this level of information. This is my
> >>>> preferred approach for debugging or understanding how some part of
> the
> >>>> code works. Having every method entry and exit produce a trace line
> >>>> often creates a huge amount of output that obscures the essential
> >>>> details
> >>>> of what is happening.
> >>>>
> >>>>
> >>>>>> Can this mid-method logging be split in two categories?
> >>>>>>
> >>>>>> a) Debug tracing
> >>>>>> A simple solution is to split the method in two, and then leverage
> >>>>>>
> >>>> the
> >>>>
> >>>>>> entry/exit method tracing as discussed above.
> >>>>>>
> >>>> In many cases this would lead to a convoluted code structure with
> local
> >>>> variables needing to be passed as parameters between the two methods,
> >>>> or
> >>>> methods that contain a single line of code (if a trace line needs to
> be
> >>>> produced from within a loop).
> >>>>
> >>>>
> >>>>> We can use JDK logger to add statements in the middle of a method.
> >>>>>
> >>>> Then
> >>>>
> >>>>> we can use an aspect to capture such calls to dump out the
> >>>>>
> >>>> information.
> >>>>
> >>>>> For example, if we have the following statement in a method:
> >>>>> logger.debug(...);
> >>>>> The apsect can trap it by a point cut like "call *
> >>>>> java.util.logger.Logger.debug(..).
> >>>>>
> >>>>>
> >>>> If the logger call is already there, why is an aspect needed to trap
> >>>> it?
> >>>> Why not just let it execute?
> >>>>
> >>>>
> >>>>>> b) End-user readable information (info that a binding is
> >>>>>> sending/receiving a message for example)
> >>>>>> This falls into the second category discussed in this thread,
> >>>>>> reporting significant events to a management console.
> >>>>>>
> >>>>> The above suggestion should help too. The key here is to have some
> >>>>>
> >>>> calls
> >>>>
> >>>>> to indicate such requirements and they can be then trapped to
> provide
> >>>>> the concrete logic.
> >>>>>
> >>>>>
> >>>>>> I think we're starting to see concrete solutions for (a) with
> >>>>>>
> >>>> aspectj.
> >>>>
> >>>>>> I have not seen any real concrete proposal for (b) yet.
> >>>>>>
> >>>>>> --
> >>>>>> Jean-Sebastien
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>
> >>> I agree that entry and exit tracing can be overwhelming in a lot of
> >>> situations. I think this is an advantage of taking the AspectJ
> approach.
> >>> If
> >>> people want to add this kind of tracing then we can make that possible
> >>> with
> >>> no direct impact on the tuscany code base.
> >>>
> >>> A concrete proposal for other messages...
> >>>
> >>> I've been poking around to see what others do and, on closer
> inspection,
> >>> CXF have a rather nice, IMHO, approach which is a combination of a
> home
> >>> grown logging util class and the JDK logger that.
> >>>
> >>> uses parameters to reduce the formatting load for inactive log
> >>> statements
> >>> uses message property files for message lookup
> >>> encompasses basic internationalization support using ICU and the
> >>> message
> >>> files behind the scenes
> >>> handles exceptions and strings (although it doesn't localize
> exception
> >>> strings)
> >>>
> >>> SLF4J does very similar things to this but we didn't seem to get much
> >>> traction with that before on this thread. It seems that we all have
> >>> different requirements for reducing dependencies vs providing logging
> >>> function. If we can reach a satisfactory level of function while
> relying
> >>> on
> >>> the built in JDK logging features then that seems to be a good
> >>> compromise.
> >>> Also with some home grown utilities we can at least make life a little
> >>> easier for ourselves in terms of recording user oriented messages
> >>> related to
> >>> model elements.
> >>>
> >>> Looking at the CXF code this is what you build.
> >>>
> >>> MyModule
> >>> src
> >>> main
> >>> java
> >>> somepath
> >>> SomeTuscanyClassA
> >>> Messages.properties
> >>> resources
> >>> logging.properties
> >>>
> >>> Nothing too surprising there. They have a LogUtil class (see
> >>> cxf-common-utilities) which provides an interface for getting JDK
> >>> loggers
> >>> and for logging with them. I'm assuming they created it but we should
> >>> check.
> >>> Here is an example of how to use it.
> >>>
> >>> import java.util.logging.Level;
> >>> import java.util.logging.Logger;
> >>>
> >>> import org.apache.cxf.common.logging.LogUtils;
> >>>
> >>> public class SomeTuscanyClassA {
> >>>
> >>> private static final Logger Log1 = LogUtils.getL7dLogger (
> >>> SomeTuscanyClassA.class);
> >>>
> >>> public SomeTuscanyClassA() {
> >>> Integer params[] = {8, 9, 4};
> >>>
> >>> LogUtils.log(Log1,
> >>> Level.INFO,
> >>> "TEST_MESSAGE",
> >>> null,
> >>> (Object[])params);
> >>>
> >>> Exception ex = new IllegalStateException("some exception
> >>> string");
> >>>
> >>> LogUtils.log(Log1,
> >>> Level.INFO ,
> >>> "TEST_MESSAGE",
> >>> ex,
> >>> (Object[])params);
> >>>
> >>>
> >>> }
> >>>
> >>> We could then extend this to allow for common Tuscany situations. For
> >>> example, by allowing a model element to be passed in,
> >>>
> >>> LogUtils.log(Log1,
> >>> Level.INFO,
> >>> composite, // or some other specialization
> of
> >>> Base where the component name, uri can be read from
> >>> "TEST_MESSAGE",
> >>> null,
> >>> (Object[])params);
> >>>
> >>> We could then chose to use
> >>>
> >>> SEVERE
> >>> WARNING
> >>> INFO
> >>> CONFIG
> >>>
> >>> To record our end user readable information. This proposal assumes
> >>> people
> >>> are comfortable with committing to JDK logging. If people are
> >>> comfortable
> >>> with this then I don't see why we can't use.
> >>>
> >>> FINE
> >>> FINER
> >>> FINEST
> >>>
> >>> for mid method tracing.
> >>>
> >>> So is this going in the right direction? Or do people have completely
> >>> different approaches in mind?
> >>>
> >>> Regards
> >>>
> >>> Simon
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> I have noticed JDK logger statements appearing in various places in
> the
> >>>
> >> code. Did we reached a conclusion on this?
> >>
> >> Simon
> >>
> >>
> >
> > Looks like System.out.println calls have been replaced by JDK logger
> calls
> > in revision r568417:
> > http://svn.apache.org/viewvc?view=rev&revision=568417
> >
> > I'm happy with that change, JDK logger is probably not perfect... but
> > which logger library is? Sorry for bringing that up :)
> >
> > I don't think we've reached any clear conclusion on tracing. Here's my
> > opinion:
> >
> > I'm +1 on using JDK logger;
> >
> > would prefer to avoid a home-grown logger layer on top of it (as we have
> > better things to do than grow yet another not perfect logger API);
> >
> > and I'm happy with using aspectj to generate entry/exit trace calls
> > externally without polluting the runtime source code, but I think we
> > should just provide a sample + documentation showing how to do it on the
> > side instead of embedding aspectj in our runtime.
> >
> > I don't have a firm opinion on monitoring - which is a different subject
> > IMO - yet.
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Ok, so we know there is no generally acceptable logging interface. Has
been proved time and time again. All we can hope to do is use something that
suits us and doesn't mess up anyone who wants to embed our code.
I'm perfectly happy to +1 JDK logging. However without some wrappers to do
it for us we need to define the ground rules for how we use it.
So, in line with what I believe is common practice, how about these...
End user readable information is expected to be recorded against the
following levels
SEVERE
WARNING
INFO
CONFIG
The following levels are tracing levels and are assumed to be developer
readable only
FINE
FINER
FINEST
Loggers will be initialized against the class name to which they relate, and
a resource bundle for the package/or module.
private static final Logger Log = Logger.getLogger(
SomeTuscanyClassB.class.getName(), "tuscany-?-messages");
We can define some global o.a.t.s loggers if we don't want to have to make
bundles for all of the non-extension modules, e.g.
private static final Logger Log = Logger.getLogger("org.apache.tuscany.sca,
"tuscany-messages");
Log statements for user readable messages will take the following form, for
example,
Log.log(Level.INFO,
"MESSAGE1");
String componentName = "Some component";
Log.log(Level.INFO,
"MESSAGE2", // message id
componentName); // parameter
Integer params[] = {8, 9, 4};
Log.log(Level.INFO,
"MESSAGE3", // message id
params); // parameter
Exception ex = new IllegalStateException("TEST_MESSAGE");
Log.log(Level.INFO,
"MESSAGE4", // message id
ex); // parameter
These messages will be localized against a message bundle from the classpath
based on the configuration of the Logger (or the Logger's parent), for
example, tuscany-messages.properties, tuscany-messages_en.properties etc.
MESSAGE1 = This is a test message with no params
MESSAGE2 = This is a test message with a string param {0}
MESSAGE3 = This is a test message with numbers {0}, {1}, {2}
MESSAGE4 = This is a test message with exception
Which can of course be provided on an extension by extension basis if
required and if specified when the logger is created.
Developer readable messages are assumed not to be localized and so can be
output using the Logger convenience methods.
We won't use log.entering and log exiting. This level of tracing will be
provided via AspectJ injection.
I'm assuming we don't want our logging properties to have to live in
jdk/lib/logging properties so we need an extensible/replaceable way to
initialize logging. e.g.
InputStream logConfigStream = Thread.currentThread
().getContextClassLoader().getResourceAsStream("tuscany-logging.properties
");
LogManager.getLogManager().readConfiguration(logConfigStream);
+ any other logging configuration that we need
Anyone have a good idea where to put this. It should go close to the start
of our domain/node implementation but would be good if it's replaceable. So
we could do with a new logging extension type that is one of the first
things that gets loaded.
Simon
JDKLogger calls, was: Monitoring, logging and exceptions (again)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> I just created https://issues.apache.org/jira/browse/TUSCANY-1635 to
> track the aspectj-based tracing.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Wednesday, August 29, 2007 11:06 AM
> Subject: Re: Monitoring, logging and exceptions (again)
>
>
>> Simon Laws wrote:
>>> On 8/20/07, Simon Laws <si...@googlemail.com> wrote:
>>>
>>>>
>>>> On 8/20/07, Simon Nash <nash@hursley.ibm.com > wrote:
>>>>
>>>>> See inline.
>>>>>
>>>>> Simon
>>>>>
>>>>> Raymond Feng wrote:
>>>>>
>>>>>
>>>>>> Comments inline.
>>>>>>
>>>>>> Thanks,
>>>>>> Raymond
>>>>>>
>>>>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>>>>> < jsdelfino@apache.org>
>>>>>> To: < tuscany-dev@ws.apache.org>
>>>>>> Sent: Friday, August 17, 2007 9:27 AM
>>>>>> Subject: Re: Monitoring, logging and exceptions (again)
>>>>>>
>>>>>>
>>>>>>
>>>>>>> [snip]
>>>>>>> ant elder wrote:
>>>>>>>
>>>>>>>
>>>>>>>> And also my 2p inline...
>>>>>>>>
>>>>>>>> ...ant
>>>>>>>>
>>>>>>>> On 8/16/07, Simon Laws < simonslaws@googlemail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> A number of different requirements have been discussed and
>>>>>>>>>
>>>>> solutions
>>>>>
>>>>>>>>> proposed. My 2p (I'm using Raymond's definitions b.t.w)
>>>>>>>>>
>>>>>>>>> Tracing: Dump out input/output/exception for method calls for the
>>>>>>>>> purpose
>>>>>>>>> of
>>>>>>>>> debugging/troubleshooting. (Target for developers/technical
>>>>>>>>>
>>>>> support)
>>>>>
>>>>>>>>> I feel that tracing of execution paths through the Tuscany
>>>>>>>>> codebase
>>>>>>>>> would
>>>>>>>>> be
>>>>>>>>> useful but agree that " it's a lot of work and will be
>>>>>>>>> difficult to
>>>>>>>>> maintain
>>>>>>>>> and keep consistent" if we did it manually. I'm happy that
>>>>>>>>> this is
>>>>>>>>>
>>>>> the
>>>>>
>>>>>>>>> responsibility of whoever wants to trace through the code and
>>>>>>>>> not a
>>>>>>>>> core
>>>>>>>>> part of the codebase. For the Tuscany developer community AspectJ
>>>>>>>>>
>>>>> have
>>>>>
>>>>>>>>> been
>>>>>>>>> proposed a couple of times and support has been prototyped. We
>>>>>>>>>
>>>>> could
>>>>>
>>>>>>>>> choose
>>>>>>>>> SLF4J as the interface through which messages are output.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I'm not sure we need to use SLF4J if we go the AspectJ route.
>>>>>>>> SLF4J
>>>>>>>>
>>>>> is a
>>>>>
>>>>>>>> facade for logging APIs, so you can code to the SLF4J API and
>>>>>>>> then
>>>>>>>> plug in
>>>>>>>> whatever logging impl you like, but if the only logging calls we
>>>>>>>>
>>>>> have
>>>>>
>>>>>>>> are
>>>>>>>> confined to a single tracing aspect we might as well just code
>>>>>>>> that
>>>>>>>> aspect
>>>>>>>> to a specific logging API like JDK logging. That avoids the extra
>>>>>>>> dependency
>>>>>>>> on SLF4J and anyone can add additional aspects if they really want
>>>>>>>>
>>>>> to
>>>>>
>>>>>>>> use a
>>>>>>>> different logger. The main other benefit of SLF4J is its
>>>>>>>>
>>>>> parameterized
>>>>>
>>>>>>>> message logging (avoids all the "if(logger.isDebugEnabled())" )
>>>>>>>> but
>>>>>>>> again if
>>>>>>>> all the logging calls are in a single aspect thats not so useful.
>>>>>>>>
>>>>>>>>
>>>>>>> Makes sense to me. If we go the aspectj route for tracing method
>>>>>>> entry/exit, I agree that using the JDK logger directly is simpler.
>>>>>>>
>>>>>>>
>>>>>> Since the aspect is on the side, we're flexible. JDK logger can be
>>>>>> default and it can be replaced easily if the embedders or users
>>>>>> choose
>>>>>> to do so.
>>>>>>
>>>>>>
>>>>>>> A few more questions on this: What dependencies will aspectj add to
>>>>>>> our distribution? aspectjweaver is more than 1Mb, do we need it?
>>>>>>>
>>>>>> I'll try to spend some time to explore both the compile-time and
>>>>>> load-time weaving.
>>>>>>
>>>>>>
>>>>>>>> What about mid-method logging of specific interesting events, for
>>>>>>>> example
>>>>>>>> the contents of requests as the enter and leave bindings and
>>>>>>>> implementation
>>>>>>>> types and things like that? That sort of logging is often all a
>>>>>>>> lot
>>>>>>>> of users
>>>>>>>> want to see not the detail tracing of every method entry/exit.
>>>>>>>> Could
>>>>>>>> we add
>>>>>>>> things like this in specific places?
>>>>>>>>
>>>>>>>>
>>>>> +1 for the ability to produce this level of information. This is my
>>>>> preferred approach for debugging or understanding how some part of
>>>>> the
>>>>> code works. Having every method entry and exit produce a trace line
>>>>> often creates a huge amount of output that obscures the essential
>>>>> details
>>>>> of what is happening.
>>>>>
>>>>>
>>>>>>> Can this mid-method logging be split in two categories?
>>>>>>>
>>>>>>> a) Debug tracing
>>>>>>> A simple solution is to split the method in two, and then leverage
>>>>>>>
>>>>> the
>>>>>
>>>>>>> entry/exit method tracing as discussed above.
>>>>>>>
>>>>> In many cases this would lead to a convoluted code structure with
>>>>> local
>>>>> variables needing to be passed as parameters between the two
>>>>> methods, or
>>>>> methods that contain a single line of code (if a trace line needs
>>>>> to be
>>>>> produced from within a loop).
>>>>>
>>>>>
>>>>>> We can use JDK logger to add statements in the middle of a method.
>>>>>>
>>>>> Then
>>>>>
>>>>>> we can use an aspect to capture such calls to dump out the
>>>>>>
>>>>> information.
>>>>>
>>>>>> For example, if we have the following statement in a method:
>>>>>> logger.debug(...);
>>>>>> The apsect can trap it by a point cut like "call *
>>>>>> java.util.logger.Logger.debug(..).
>>>>>>
>>>>>>
>>>>> If the logger call is already there, why is an aspect needed to
>>>>> trap it?
>>>>> Why not just let it execute?
>>>>>
>>>>>
>>>>>>> b) End-user readable information (info that a binding is
>>>>>>> sending/receiving a message for example)
>>>>>>> This falls into the second category discussed in this thread,
>>>>>>> reporting significant events to a management console.
>>>>>>>
>>>>>> The above suggestion should help too. The key here is to have some
>>>>>>
>>>>> calls
>>>>>
>>>>>> to indicate such requirements and they can be then trapped to
>>>>>> provide
>>>>>> the concrete logic.
>>>>>>
>>>>>>
>>>>>>> I think we're starting to see concrete solutions for (a) with
>>>>>>>
>>>>> aspectj.
>>>>>
>>>>>>> I have not seen any real concrete proposal for (b) yet.
>>>>>>>
>>>>>>> --
>>>>>>> Jean-Sebastien
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>
>>>> I agree that entry and exit tracing can be overwhelming in a lot of
>>>> situations. I think this is an advantage of taking the AspectJ
>>>> approach. If
>>>> people want to add this kind of tracing then we can make that
>>>> possible with
>>>> no direct impact on the tuscany code base.
>>>>
>>>> A concrete proposal for other messages...
>>>>
>>>> I've been poking around to see what others do and, on closer
>>>> inspection,
>>>> CXF have a rather nice, IMHO, approach which is a combination of a
>>>> home
>>>> grown logging util class and the JDK logger that.
>>>>
>>>> uses parameters to reduce the formatting load for inactive log
>>>> statements
>>>> uses message property files for message lookup
>>>> encompasses basic internationalization support using ICU and the
>>>> message
>>>> files behind the scenes
>>>> handles exceptions and strings (although it doesn't localize
>>>> exception
>>>> strings)
>>>>
>>>> SLF4J does very similar things to this but we didn't seem to get much
>>>> traction with that before on this thread. It seems that we all have
>>>> different requirements for reducing dependencies vs providing logging
>>>> function. If we can reach a satisfactory level of function while
>>>> relying on
>>>> the built in JDK logging features then that seems to be a good
>>>> compromise.
>>>> Also with some home grown utilities we can at least make life a little
>>>> easier for ourselves in terms of recording user oriented messages
>>>> related to
>>>> model elements.
>>>>
>>>> Looking at the CXF code this is what you build.
>>>>
>>>> MyModule
>>>> src
>>>> main
>>>> java
>>>> somepath
>>>> SomeTuscanyClassA
>>>> Messages.properties
>>>> resources
>>>> logging.properties
>>>>
>>>> Nothing too surprising there. They have a LogUtil class (see
>>>> cxf-common-utilities) which provides an interface for getting JDK
>>>> loggers
>>>> and for logging with them. I'm assuming they created it but we
>>>> should check.
>>>> Here is an example of how to use it.
>>>>
>>>> import java.util.logging.Level;
>>>> import java.util.logging.Logger;
>>>>
>>>> import org.apache.cxf.common.logging.LogUtils;
>>>>
>>>> public class SomeTuscanyClassA {
>>>>
>>>> private static final Logger Log1 = LogUtils.getL7dLogger (
>>>> SomeTuscanyClassA.class);
>>>>
>>>> public SomeTuscanyClassA() {
>>>> Integer params[] = {8, 9, 4};
>>>>
>>>> LogUtils.log(Log1,
>>>> Level.INFO,
>>>> "TEST_MESSAGE",
>>>> null,
>>>> (Object[])params);
>>>>
>>>> Exception ex = new IllegalStateException("some exception
>>>> string");
>>>>
>>>> LogUtils.log(Log1,
>>>> Level.INFO ,
>>>> "TEST_MESSAGE",
>>>> ex,
>>>> (Object[])params);
>>>>
>>>>
>>>> }
>>>>
>>>> We could then extend this to allow for common Tuscany situations. For
>>>> example, by allowing a model element to be passed in,
>>>>
>>>> LogUtils.log(Log1,
>>>> Level.INFO,
>>>> composite, // or some other
>>>> specialization of
>>>> Base where the component name, uri can be read from
>>>> "TEST_MESSAGE",
>>>> null,
>>>> (Object[])params);
>>>>
>>>> We could then chose to use
>>>>
>>>> SEVERE
>>>> WARNING
>>>> INFO
>>>> CONFIG
>>>>
>>>> To record our end user readable information. This proposal assumes
>>>> people
>>>> are comfortable with committing to JDK logging. If people are
>>>> comfortable
>>>> with this then I don't see why we can't use.
>>>>
>>>> FINE
>>>> FINER
>>>> FINEST
>>>>
>>>> for mid method tracing.
>>>>
>>>> So is this going in the right direction? Or do people have completely
>>>> different approaches in mind?
>>>>
>>>> Regards
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I have noticed JDK logger statements appearing in various places in
>>>> the
>>>>
>>> code. Did we reached a conclusion on this?
>>>
>>> Simon
>>>
>>>
>>
>> Looks like System.out.println calls have been replaced by JDK logger
>> calls in revision r568417:
>> http://svn.apache.org/viewvc?view=rev&revision=568417
>>
>> I'm happy with that change, JDK logger is probably not perfect... but
>> which logger library is? Sorry for bringing that up :)
>>
>> I don't think we've reached any clear conclusion on tracing. Here's
>> my opinion:
>>
>> I'm +1 on using JDK logger;
>>
>> would prefer to avoid a home-grown logger layer on top of it (as we
>> have better things to do than grow yet another not perfect logger API);
>>
>> and I'm happy with using aspectj to generate entry/exit trace calls
>> externally without polluting the runtime source code, but I think we
>> should just provide a sample + documentation showing how to do it on
>> the side instead of embedding aspectj in our runtime.
>>
>> I don't have a firm opinion on monitoring - which is a different
>> subject IMO - yet.
>>
>> --
>> Jean-Sebastien
>>
>>
So how about we all spend a few hours going through the modules we've
been working on and add JDKLogger calls to log important events, infos,
errors (like I'm starting a component, sending a message, about to fail
etc.)?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Monitoring, logging and exceptions (again)
Posted by Raymond Feng <en...@gmail.com>.
I just created https://issues.apache.org/jira/browse/TUSCANY-1635 to track
the aspectj-based tracing.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, August 29, 2007 11:06 AM
Subject: Re: Monitoring, logging and exceptions (again)
> Simon Laws wrote:
>> On 8/20/07, Simon Laws <si...@googlemail.com> wrote:
>>
>>>
>>> On 8/20/07, Simon Nash <nash@hursley.ibm.com > wrote:
>>>
>>>> See inline.
>>>>
>>>> Simon
>>>>
>>>> Raymond Feng wrote:
>>>>
>>>>
>>>>> Comments inline.
>>>>>
>>>>> Thanks,
>>>>> Raymond
>>>>>
>>>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>>>> < jsdelfino@apache.org>
>>>>> To: < tuscany-dev@ws.apache.org>
>>>>> Sent: Friday, August 17, 2007 9:27 AM
>>>>> Subject: Re: Monitoring, logging and exceptions (again)
>>>>>
>>>>>
>>>>>
>>>>>> [snip]
>>>>>> ant elder wrote:
>>>>>>
>>>>>>
>>>>>>> And also my 2p inline...
>>>>>>>
>>>>>>> ...ant
>>>>>>>
>>>>>>> On 8/16/07, Simon Laws < simonslaws@googlemail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> A number of different requirements have been discussed and
>>>>>>>>
>>>> solutions
>>>>
>>>>>>>> proposed. My 2p (I'm using Raymond's definitions b.t.w)
>>>>>>>>
>>>>>>>> Tracing: Dump out input/output/exception for method calls for the
>>>>>>>> purpose
>>>>>>>> of
>>>>>>>> debugging/troubleshooting. (Target for developers/technical
>>>>>>>>
>>>> support)
>>>>
>>>>>>>> I feel that tracing of execution paths through the Tuscany codebase
>>>>>>>> would
>>>>>>>> be
>>>>>>>> useful but agree that " it's a lot of work and will be difficult to
>>>>>>>> maintain
>>>>>>>> and keep consistent" if we did it manually. I'm happy that this is
>>>>>>>>
>>>> the
>>>>
>>>>>>>> responsibility of whoever wants to trace through the code and not a
>>>>>>>> core
>>>>>>>> part of the codebase. For the Tuscany developer community AspectJ
>>>>>>>>
>>>> have
>>>>
>>>>>>>> been
>>>>>>>> proposed a couple of times and support has been prototyped. We
>>>>>>>>
>>>> could
>>>>
>>>>>>>> choose
>>>>>>>> SLF4J as the interface through which messages are output.
>>>>>>>>
>>>>>>>>
>>>>>>> I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J
>>>>>>>
>>>> is a
>>>>
>>>>>>> facade for logging APIs, so you can code to the SLF4J API and then
>>>>>>> plug in
>>>>>>> whatever logging impl you like, but if the only logging calls we
>>>>>>>
>>>> have
>>>>
>>>>>>> are
>>>>>>> confined to a single tracing aspect we might as well just code that
>>>>>>> aspect
>>>>>>> to a specific logging API like JDK logging. That avoids the extra
>>>>>>> dependency
>>>>>>> on SLF4J and anyone can add additional aspects if they really want
>>>>>>>
>>>> to
>>>>
>>>>>>> use a
>>>>>>> different logger. The main other benefit of SLF4J is its
>>>>>>>
>>>> parameterized
>>>>
>>>>>>> message logging (avoids all the "if(logger.isDebugEnabled())" ) but
>>>>>>> again if
>>>>>>> all the logging calls are in a single aspect thats not so useful.
>>>>>>>
>>>>>>>
>>>>>> Makes sense to me. If we go the aspectj route for tracing method
>>>>>> entry/exit, I agree that using the JDK logger directly is simpler.
>>>>>>
>>>>>>
>>>>> Since the aspect is on the side, we're flexible. JDK logger can be
>>>>> default and it can be replaced easily if the embedders or users choose
>>>>> to do so.
>>>>>
>>>>>
>>>>>> A few more questions on this: What dependencies will aspectj add to
>>>>>> our distribution? aspectjweaver is more than 1Mb, do we need it?
>>>>>>
>>>>> I'll try to spend some time to explore both the compile-time and
>>>>> load-time weaving.
>>>>>
>>>>>
>>>>>>> What about mid-method logging of specific interesting events, for
>>>>>>> example
>>>>>>> the contents of requests as the enter and leave bindings and
>>>>>>> implementation
>>>>>>> types and things like that? That sort of logging is often all a lot
>>>>>>> of users
>>>>>>> want to see not the detail tracing of every method entry/exit. Could
>>>>>>> we add
>>>>>>> things like this in specific places?
>>>>>>>
>>>>>>>
>>>> +1 for the ability to produce this level of information. This is my
>>>> preferred approach for debugging or understanding how some part of the
>>>> code works. Having every method entry and exit produce a trace line
>>>> often creates a huge amount of output that obscures the essential
>>>> details
>>>> of what is happening.
>>>>
>>>>
>>>>>> Can this mid-method logging be split in two categories?
>>>>>>
>>>>>> a) Debug tracing
>>>>>> A simple solution is to split the method in two, and then leverage
>>>>>>
>>>> the
>>>>
>>>>>> entry/exit method tracing as discussed above.
>>>>>>
>>>> In many cases this would lead to a convoluted code structure with local
>>>> variables needing to be passed as parameters between the two methods,
>>>> or
>>>> methods that contain a single line of code (if a trace line needs to be
>>>> produced from within a loop).
>>>>
>>>>
>>>>> We can use JDK logger to add statements in the middle of a method.
>>>>>
>>>> Then
>>>>
>>>>> we can use an aspect to capture such calls to dump out the
>>>>>
>>>> information.
>>>>
>>>>> For example, if we have the following statement in a method:
>>>>> logger.debug(...);
>>>>> The apsect can trap it by a point cut like "call *
>>>>> java.util.logger.Logger.debug(..).
>>>>>
>>>>>
>>>> If the logger call is already there, why is an aspect needed to trap
>>>> it?
>>>> Why not just let it execute?
>>>>
>>>>
>>>>>> b) End-user readable information (info that a binding is
>>>>>> sending/receiving a message for example)
>>>>>> This falls into the second category discussed in this thread,
>>>>>> reporting significant events to a management console.
>>>>>>
>>>>> The above suggestion should help too. The key here is to have some
>>>>>
>>>> calls
>>>>
>>>>> to indicate such requirements and they can be then trapped to provide
>>>>> the concrete logic.
>>>>>
>>>>>
>>>>>> I think we're starting to see concrete solutions for (a) with
>>>>>>
>>>> aspectj.
>>>>
>>>>>> I have not seen any real concrete proposal for (b) yet.
>>>>>>
>>>>>> --
>>>>>> Jean-Sebastien
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>> I agree that entry and exit tracing can be overwhelming in a lot of
>>> situations. I think this is an advantage of taking the AspectJ approach.
>>> If
>>> people want to add this kind of tracing then we can make that possible
>>> with
>>> no direct impact on the tuscany code base.
>>>
>>> A concrete proposal for other messages...
>>>
>>> I've been poking around to see what others do and, on closer inspection,
>>> CXF have a rather nice, IMHO, approach which is a combination of a home
>>> grown logging util class and the JDK logger that.
>>>
>>> uses parameters to reduce the formatting load for inactive log
>>> statements
>>> uses message property files for message lookup
>>> encompasses basic internationalization support using ICU and the
>>> message
>>> files behind the scenes
>>> handles exceptions and strings (although it doesn't localize exception
>>> strings)
>>>
>>> SLF4J does very similar things to this but we didn't seem to get much
>>> traction with that before on this thread. It seems that we all have
>>> different requirements for reducing dependencies vs providing logging
>>> function. If we can reach a satisfactory level of function while relying
>>> on
>>> the built in JDK logging features then that seems to be a good
>>> compromise.
>>> Also with some home grown utilities we can at least make life a little
>>> easier for ourselves in terms of recording user oriented messages
>>> related to
>>> model elements.
>>>
>>> Looking at the CXF code this is what you build.
>>>
>>> MyModule
>>> src
>>> main
>>> java
>>> somepath
>>> SomeTuscanyClassA
>>> Messages.properties
>>> resources
>>> logging.properties
>>>
>>> Nothing too surprising there. They have a LogUtil class (see
>>> cxf-common-utilities) which provides an interface for getting JDK
>>> loggers
>>> and for logging with them. I'm assuming they created it but we should
>>> check.
>>> Here is an example of how to use it.
>>>
>>> import java.util.logging.Level;
>>> import java.util.logging.Logger;
>>>
>>> import org.apache.cxf.common.logging.LogUtils;
>>>
>>> public class SomeTuscanyClassA {
>>>
>>> private static final Logger Log1 = LogUtils.getL7dLogger (
>>> SomeTuscanyClassA.class);
>>>
>>> public SomeTuscanyClassA() {
>>> Integer params[] = {8, 9, 4};
>>>
>>> LogUtils.log(Log1,
>>> Level.INFO,
>>> "TEST_MESSAGE",
>>> null,
>>> (Object[])params);
>>>
>>> Exception ex = new IllegalStateException("some exception
>>> string");
>>>
>>> LogUtils.log(Log1,
>>> Level.INFO ,
>>> "TEST_MESSAGE",
>>> ex,
>>> (Object[])params);
>>>
>>>
>>> }
>>>
>>> We could then extend this to allow for common Tuscany situations. For
>>> example, by allowing a model element to be passed in,
>>>
>>> LogUtils.log(Log1,
>>> Level.INFO,
>>> composite, // or some other specialization of
>>> Base where the component name, uri can be read from
>>> "TEST_MESSAGE",
>>> null,
>>> (Object[])params);
>>>
>>> We could then chose to use
>>>
>>> SEVERE
>>> WARNING
>>> INFO
>>> CONFIG
>>>
>>> To record our end user readable information. This proposal assumes
>>> people
>>> are comfortable with committing to JDK logging. If people are
>>> comfortable
>>> with this then I don't see why we can't use.
>>>
>>> FINE
>>> FINER
>>> FINEST
>>>
>>> for mid method tracing.
>>>
>>> So is this going in the right direction? Or do people have completely
>>> different approaches in mind?
>>>
>>> Regards
>>>
>>> Simon
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I have noticed JDK logger statements appearing in various places in the
>>>
>> code. Did we reached a conclusion on this?
>>
>> Simon
>>
>>
>
> Looks like System.out.println calls have been replaced by JDK logger calls
> in revision r568417:
> http://svn.apache.org/viewvc?view=rev&revision=568417
>
> I'm happy with that change, JDK logger is probably not perfect... but
> which logger library is? Sorry for bringing that up :)
>
> I don't think we've reached any clear conclusion on tracing. Here's my
> opinion:
>
> I'm +1 on using JDK logger;
>
> would prefer to avoid a home-grown logger layer on top of it (as we have
> better things to do than grow yet another not perfect logger API);
>
> and I'm happy with using aspectj to generate entry/exit trace calls
> externally without polluting the runtime source code, but I think we
> should just provide a sample + documentation showing how to do it on the
> side instead of embedding aspectj in our runtime.
>
> I don't have a firm opinion on monitoring - which is a different subject
> IMO - yet.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Monitoring, logging and exceptions (again)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On 8/20/07, Simon Laws <si...@googlemail.com> wrote:
>
>>
>> On 8/20/07, Simon Nash <nash@hursley.ibm.com > wrote:
>>
>>> See inline.
>>>
>>> Simon
>>>
>>> Raymond Feng wrote:
>>>
>>>
>>>> Comments inline.
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>>> < jsdelfino@apache.org>
>>>> To: < tuscany-dev@ws.apache.org>
>>>> Sent: Friday, August 17, 2007 9:27 AM
>>>> Subject: Re: Monitoring, logging and exceptions (again)
>>>>
>>>>
>>>>
>>>>> [snip]
>>>>> ant elder wrote:
>>>>>
>>>>>
>>>>>> And also my 2p inline...
>>>>>>
>>>>>> ...ant
>>>>>>
>>>>>> On 8/16/07, Simon Laws < simonslaws@googlemail.com> wrote:
>>>>>>
>>>>>>
>>>>>>> A number of different requirements have been discussed and
>>>>>>>
>>> solutions
>>>
>>>>>>> proposed. My 2p (I'm using Raymond's definitions b.t.w)
>>>>>>>
>>>>>>> Tracing: Dump out input/output/exception for method calls for the
>>>>>>> purpose
>>>>>>> of
>>>>>>> debugging/troubleshooting. (Target for developers/technical
>>>>>>>
>>> support)
>>>
>>>>>>> I feel that tracing of execution paths through the Tuscany codebase
>>>>>>> would
>>>>>>> be
>>>>>>> useful but agree that " it's a lot of work and will be difficult to
>>>>>>>
>>>>>>> maintain
>>>>>>> and keep consistent" if we did it manually. I'm happy that this is
>>>>>>>
>>> the
>>>
>>>>>>> responsibility of whoever wants to trace through the code and not a
>>>>>>> core
>>>>>>> part of the codebase. For the Tuscany developer community AspectJ
>>>>>>>
>>> have
>>>
>>>>>>> been
>>>>>>> proposed a couple of times and support has been prototyped. We
>>>>>>>
>>> could
>>>
>>>>>>> choose
>>>>>>> SLF4J as the interface through which messages are output.
>>>>>>>
>>>>>>>
>>>>>> I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J
>>>>>>
>>> is a
>>>
>>>>>> facade for logging APIs, so you can code to the SLF4J API and then
>>>>>> plug in
>>>>>> whatever logging impl you like, but if the only logging calls we
>>>>>>
>>> have
>>>
>>>>>> are
>>>>>> confined to a single tracing aspect we might as well just code that
>>>>>> aspect
>>>>>> to a specific logging API like JDK logging. That avoids the extra
>>>>>> dependency
>>>>>> on SLF4J and anyone can add additional aspects if they really want
>>>>>>
>>> to
>>>
>>>>>> use a
>>>>>> different logger. The main other benefit of SLF4J is its
>>>>>>
>>> parameterized
>>>
>>>>>> message logging (avoids all the "if(logger.isDebugEnabled())" ) but
>>>>>> again if
>>>>>> all the logging calls are in a single aspect thats not so useful.
>>>>>>
>>>>>>
>>>>> Makes sense to me. If we go the aspectj route for tracing method
>>>>> entry/exit, I agree that using the JDK logger directly is simpler.
>>>>>
>>>>>
>>>> Since the aspect is on the side, we're flexible. JDK logger can be
>>>> default and it can be replaced easily if the embedders or users choose
>>>> to do so.
>>>>
>>>>
>>>>> A few more questions on this: What dependencies will aspectj add to
>>>>> our distribution? aspectjweaver is more than 1Mb, do we need it?
>>>>>
>>>> I'll try to spend some time to explore both the compile-time and
>>>> load-time weaving.
>>>>
>>>>
>>>>>> What about mid-method logging of specific interesting events, for
>>>>>> example
>>>>>> the contents of requests as the enter and leave bindings and
>>>>>> implementation
>>>>>> types and things like that? That sort of logging is often all a lot
>>>>>> of users
>>>>>> want to see not the detail tracing of every method entry/exit. Could
>>>>>> we add
>>>>>> things like this in specific places?
>>>>>>
>>>>>>
>>> +1 for the ability to produce this level of information. This is my
>>> preferred approach for debugging or understanding how some part of the
>>> code works. Having every method entry and exit produce a trace line
>>> often creates a huge amount of output that obscures the essential
>>> details
>>> of what is happening.
>>>
>>>
>>>>> Can this mid-method logging be split in two categories?
>>>>>
>>>>> a) Debug tracing
>>>>> A simple solution is to split the method in two, and then leverage
>>>>>
>>> the
>>>
>>>>> entry/exit method tracing as discussed above.
>>>>>
>>> In many cases this would lead to a convoluted code structure with local
>>> variables needing to be passed as parameters between the two methods, or
>>> methods that contain a single line of code (if a trace line needs to be
>>> produced from within a loop).
>>>
>>>
>>>> We can use JDK logger to add statements in the middle of a method.
>>>>
>>> Then
>>>
>>>> we can use an aspect to capture such calls to dump out the
>>>>
>>> information.
>>>
>>>> For example, if we have the following statement in a method:
>>>> logger.debug(...);
>>>> The apsect can trap it by a point cut like "call *
>>>> java.util.logger.Logger.debug(..).
>>>>
>>>>
>>> If the logger call is already there, why is an aspect needed to trap it?
>>> Why not just let it execute?
>>>
>>>
>>>>> b) End-user readable information (info that a binding is
>>>>> sending/receiving a message for example)
>>>>> This falls into the second category discussed in this thread,
>>>>> reporting significant events to a management console.
>>>>>
>>>> The above suggestion should help too. The key here is to have some
>>>>
>>> calls
>>>
>>>> to indicate such requirements and they can be then trapped to provide
>>>> the concrete logic.
>>>>
>>>>
>>>>> I think we're starting to see concrete solutions for (a) with
>>>>>
>>> aspectj.
>>>
>>>>> I have not seen any real concrete proposal for (b) yet.
>>>>>
>>>>> --
>>>>> Jean-Sebastien
>>>>>
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>> I agree that entry and exit tracing can be overwhelming in a lot of
>> situations. I think this is an advantage of taking the AspectJ approach. If
>> people want to add this kind of tracing then we can make that possible with
>> no direct impact on the tuscany code base.
>>
>> A concrete proposal for other messages...
>>
>> I've been poking around to see what others do and, on closer inspection,
>> CXF have a rather nice, IMHO, approach which is a combination of a home
>> grown logging util class and the JDK logger that.
>>
>> uses parameters to reduce the formatting load for inactive log
>> statements
>> uses message property files for message lookup
>> encompasses basic internationalization support using ICU and the message
>> files behind the scenes
>> handles exceptions and strings (although it doesn't localize exception
>> strings)
>>
>> SLF4J does very similar things to this but we didn't seem to get much
>> traction with that before on this thread. It seems that we all have
>> different requirements for reducing dependencies vs providing logging
>> function. If we can reach a satisfactory level of function while relying on
>> the built in JDK logging features then that seems to be a good compromise.
>> Also with some home grown utilities we can at least make life a little
>> easier for ourselves in terms of recording user oriented messages related to
>> model elements.
>>
>> Looking at the CXF code this is what you build.
>>
>> MyModule
>> src
>> main
>> java
>> somepath
>> SomeTuscanyClassA
>> Messages.properties
>> resources
>> logging.properties
>>
>> Nothing too surprising there. They have a LogUtil class (see
>> cxf-common-utilities) which provides an interface for getting JDK loggers
>> and for logging with them. I'm assuming they created it but we should check.
>> Here is an example of how to use it.
>>
>> import java.util.logging.Level;
>> import java.util.logging.Logger;
>>
>> import org.apache.cxf.common.logging.LogUtils;
>>
>> public class SomeTuscanyClassA {
>>
>> private static final Logger Log1 = LogUtils.getL7dLogger (
>> SomeTuscanyClassA.class);
>>
>> public SomeTuscanyClassA() {
>> Integer params[] = {8, 9, 4};
>>
>> LogUtils.log(Log1,
>> Level.INFO,
>> "TEST_MESSAGE",
>> null,
>> (Object[])params);
>>
>> Exception ex = new IllegalStateException("some exception string");
>>
>> LogUtils.log(Log1,
>> Level.INFO ,
>> "TEST_MESSAGE",
>> ex,
>> (Object[])params);
>>
>>
>> }
>>
>> We could then extend this to allow for common Tuscany situations. For
>> example, by allowing a model element to be passed in,
>>
>> LogUtils.log(Log1,
>> Level.INFO,
>> composite, // or some other specialization of
>> Base where the component name, uri can be read from
>> "TEST_MESSAGE",
>> null,
>> (Object[])params);
>>
>> We could then chose to use
>>
>> SEVERE
>> WARNING
>> INFO
>> CONFIG
>>
>> To record our end user readable information. This proposal assumes people
>> are comfortable with committing to JDK logging. If people are comfortable
>> with this then I don't see why we can't use.
>>
>> FINE
>> FINER
>> FINEST
>>
>> for mid method tracing.
>>
>> So is this going in the right direction? Or do people have completely
>> different approaches in mind?
>>
>> Regards
>>
>> Simon
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I have noticed JDK logger statements appearing in various places in the
>>
> code. Did we reached a conclusion on this?
>
> Simon
>
>
Looks like System.out.println calls have been replaced by JDK logger
calls in revision r568417:
http://svn.apache.org/viewvc?view=rev&revision=568417
I'm happy with that change, JDK logger is probably not perfect... but
which logger library is? Sorry for bringing that up :)
I don't think we've reached any clear conclusion on tracing. Here's my
opinion:
I'm +1 on using JDK logger;
would prefer to avoid a home-grown logger layer on top of it (as we have
better things to do than grow yet another not perfect logger API);
and I'm happy with using aspectj to generate entry/exit trace calls
externally without polluting the runtime source code, but I think we
should just provide a sample + documentation showing how to do it on the
side instead of embedding aspectj in our runtime.
I don't have a firm opinion on monitoring - which is a different subject
IMO - yet.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Monitoring, logging and exceptions (again)
Posted by Simon Laws <si...@googlemail.com>.
On 8/20/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 8/20/07, Simon Nash <nash@hursley.ibm.com > wrote:
> >
> > See inline.
> >
> > Simon
> >
> > Raymond Feng wrote:
> >
> > > Comments inline.
> > >
> > > Thanks,
> > > Raymond
> > >
> > > ----- Original Message ----- From: "Jean-Sebastien Delfino"
> > > < jsdelfino@apache.org>
> > > To: < tuscany-dev@ws.apache.org>
> > > Sent: Friday, August 17, 2007 9:27 AM
> > > Subject: Re: Monitoring, logging and exceptions (again)
> > >
> > >
> > >> [snip]
> > >> ant elder wrote:
> > >>
> > >>> And also my 2p inline...
> > >>>
> > >>> ...ant
> > >>>
> > >>> On 8/16/07, Simon Laws < simonslaws@googlemail.com> wrote:
> > >>>
> > >>>> A number of different requirements have been discussed and
> > solutions
> > >>>> proposed. My 2p (I'm using Raymond's definitions b.t.w)
> > >>>>
> > >>>> Tracing: Dump out input/output/exception for method calls for the
> > >>>> purpose
> > >>>> of
> > >>>> debugging/troubleshooting. (Target for developers/technical
> > support)
> > >>>>
> > >>>> I feel that tracing of execution paths through the Tuscany codebase
> > >>>> would
> > >>>> be
> > >>>> useful but agree that " it's a lot of work and will be difficult to
> >
> > >>>> maintain
> > >>>> and keep consistent" if we did it manually. I'm happy that this is
> > the
> > >>>> responsibility of whoever wants to trace through the code and not a
> > >>>> core
> > >>>> part of the codebase. For the Tuscany developer community AspectJ
> > have
> > >>>> been
> > >>>> proposed a couple of times and support has been prototyped. We
> > could
> > >>>> choose
> > >>>> SLF4J as the interface through which messages are output.
> > >>>>
> > >>>
> > >>>
> > >>> I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J
> > is a
> > >>> facade for logging APIs, so you can code to the SLF4J API and then
> > >>> plug in
> > >>> whatever logging impl you like, but if the only logging calls we
> > have
> > >>> are
> > >>> confined to a single tracing aspect we might as well just code that
> > >>> aspect
> > >>> to a specific logging API like JDK logging. That avoids the extra
> > >>> dependency
> > >>> on SLF4J and anyone can add additional aspects if they really want
> > to
> > >>> use a
> > >>> different logger. The main other benefit of SLF4J is its
> > parameterized
> > >>> message logging (avoids all the "if(logger.isDebugEnabled())" ) but
> > >>> again if
> > >>> all the logging calls are in a single aspect thats not so useful.
> > >>>
> > >>
> > >> Makes sense to me. If we go the aspectj route for tracing method
> > >> entry/exit, I agree that using the JDK logger directly is simpler.
> > >>
> > >
> > > Since the aspect is on the side, we're flexible. JDK logger can be
> > > default and it can be replaced easily if the embedders or users choose
> > > to do so.
> > >
> > >> A few more questions on this: What dependencies will aspectj add to
> > >> our distribution? aspectjweaver is more than 1Mb, do we need it?
> > >
> > >
> > > I'll try to spend some time to explore both the compile-time and
> > > load-time weaving.
> > >
> > >>
> > >>> What about mid-method logging of specific interesting events, for
> > >>> example
> > >>> the contents of requests as the enter and leave bindings and
> > >>> implementation
> > >>> types and things like that? That sort of logging is often all a lot
> > >>> of users
> > >>> want to see not the detail tracing of every method entry/exit. Could
> > >>> we add
> > >>> things like this in specific places?
> > >>>
> > +1 for the ability to produce this level of information. This is my
> > preferred approach for debugging or understanding how some part of the
> > code works. Having every method entry and exit produce a trace line
> > often creates a huge amount of output that obscures the essential
> > details
> > of what is happening.
> >
> > >>
> > >> Can this mid-method logging be split in two categories?
> > >>
> > >> a) Debug tracing
> > >> A simple solution is to split the method in two, and then leverage
> > the
> > >> entry/exit method tracing as discussed above.
> > >
> > In many cases this would lead to a convoluted code structure with local
> > variables needing to be passed as parameters between the two methods, or
> > methods that contain a single line of code (if a trace line needs to be
> > produced from within a loop).
> >
> > >
> > > We can use JDK logger to add statements in the middle of a method.
> > Then
> > > we can use an aspect to capture such calls to dump out the
> > information.
> > >
> > > For example, if we have the following statement in a method:
> > > logger.debug(...);
> > > The apsect can trap it by a point cut like "call *
> > > java.util.logger.Logger.debug(..).
> > >
> > If the logger call is already there, why is an aspect needed to trap it?
> > Why not just let it execute?
> >
> > >>
> > >> b) End-user readable information (info that a binding is
> > >> sending/receiving a message for example)
> > >> This falls into the second category discussed in this thread,
> > >> reporting significant events to a management console.
> > >
> > >
> > > The above suggestion should help too. The key here is to have some
> > calls
> > > to indicate such requirements and they can be then trapped to provide
> > > the concrete logic.
> > >
> > >>
> > >> I think we're starting to see concrete solutions for (a) with
> > aspectj.
> > >> I have not seen any real concrete proposal for (b) yet.
> > >>
> > >> --
> > >> Jean-Sebastien
> > >>
> > >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> I agree that entry and exit tracing can be overwhelming in a lot of
> situations. I think this is an advantage of taking the AspectJ approach. If
> people want to add this kind of tracing then we can make that possible with
> no direct impact on the tuscany code base.
>
> A concrete proposal for other messages...
>
> I've been poking around to see what others do and, on closer inspection,
> CXF have a rather nice, IMHO, approach which is a combination of a home
> grown logging util class and the JDK logger that.
>
> uses parameters to reduce the formatting load for inactive log
> statements
> uses message property files for message lookup
> encompasses basic internationalization support using ICU and the message
> files behind the scenes
> handles exceptions and strings (although it doesn't localize exception
> strings)
>
> SLF4J does very similar things to this but we didn't seem to get much
> traction with that before on this thread. It seems that we all have
> different requirements for reducing dependencies vs providing logging
> function. If we can reach a satisfactory level of function while relying on
> the built in JDK logging features then that seems to be a good compromise.
> Also with some home grown utilities we can at least make life a little
> easier for ourselves in terms of recording user oriented messages related to
> model elements.
>
> Looking at the CXF code this is what you build.
>
> MyModule
> src
> main
> java
> somepath
> SomeTuscanyClassA
> Messages.properties
> resources
> logging.properties
>
> Nothing too surprising there. They have a LogUtil class (see
> cxf-common-utilities) which provides an interface for getting JDK loggers
> and for logging with them. I'm assuming they created it but we should check.
> Here is an example of how to use it.
>
> import java.util.logging.Level;
> import java.util.logging.Logger;
>
> import org.apache.cxf.common.logging.LogUtils;
>
> public class SomeTuscanyClassA {
>
> private static final Logger Log1 = LogUtils.getL7dLogger (
> SomeTuscanyClassA.class);
>
> public SomeTuscanyClassA() {
> Integer params[] = {8, 9, 4};
>
> LogUtils.log(Log1,
> Level.INFO,
> "TEST_MESSAGE",
> null,
> (Object[])params);
>
> Exception ex = new IllegalStateException("some exception string");
>
> LogUtils.log(Log1,
> Level.INFO ,
> "TEST_MESSAGE",
> ex,
> (Object[])params);
>
>
> }
>
> We could then extend this to allow for common Tuscany situations. For
> example, by allowing a model element to be passed in,
>
> LogUtils.log(Log1,
> Level.INFO,
> composite, // or some other specialization of
> Base where the component name, uri can be read from
> "TEST_MESSAGE",
> null,
> (Object[])params);
>
> We could then chose to use
>
> SEVERE
> WARNING
> INFO
> CONFIG
>
> To record our end user readable information. This proposal assumes people
> are comfortable with committing to JDK logging. If people are comfortable
> with this then I don't see why we can't use.
>
> FINE
> FINER
> FINEST
>
> for mid method tracing.
>
> So is this going in the right direction? Or do people have completely
> different approaches in mind?
>
> Regards
>
> Simon
>
>
>
>
>
>
>
>
>
> I have noticed JDK logger statements appearing in various places in the
code. Did we reached a conclusion on this?
Simon
Re: Monitoring, logging and exceptions (again)
Posted by Simon Laws <si...@googlemail.com>.
On 8/20/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> See inline.
>
> Simon
>
> Raymond Feng wrote:
>
> > Comments inline.
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message ----- From: "Jean-Sebastien Delfino"
> > < jsdelfino@apache.org>
> > To: <tu...@ws.apache.org>
> > Sent: Friday, August 17, 2007 9:27 AM
> > Subject: Re: Monitoring, logging and exceptions (again)
> >
> >
> >> [snip]
> >> ant elder wrote:
> >>
> >>> And also my 2p inline...
> >>>
> >>> ...ant
> >>>
> >>> On 8/16/07, Simon Laws < simonslaws@googlemail.com> wrote:
> >>>
> >>>> A number of different requirements have been discussed and solutions
> >>>> proposed. My 2p (I'm using Raymond's definitions b.t.w)
> >>>>
> >>>> Tracing: Dump out input/output/exception for method calls for the
> >>>> purpose
> >>>> of
> >>>> debugging/troubleshooting. (Target for developers/technical support)
> >>>>
> >>>> I feel that tracing of execution paths through the Tuscany codebase
> >>>> would
> >>>> be
> >>>> useful but agree that " it's a lot of work and will be difficult to
> >>>> maintain
> >>>> and keep consistent" if we did it manually. I'm happy that this is
> the
> >>>> responsibility of whoever wants to trace through the code and not a
> >>>> core
> >>>> part of the codebase. For the Tuscany developer community AspectJ
> have
> >>>> been
> >>>> proposed a couple of times and support has been prototyped. We could
> >>>> choose
> >>>> SLF4J as the interface through which messages are output.
> >>>>
> >>>
> >>>
> >>> I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J is
> a
> >>> facade for logging APIs, so you can code to the SLF4J API and then
> >>> plug in
> >>> whatever logging impl you like, but if the only logging calls we have
> >>> are
> >>> confined to a single tracing aspect we might as well just code that
> >>> aspect
> >>> to a specific logging API like JDK logging. That avoids the extra
> >>> dependency
> >>> on SLF4J and anyone can add additional aspects if they really want to
> >>> use a
> >>> different logger. The main other benefit of SLF4J is its parameterized
> >>> message logging (avoids all the "if(logger.isDebugEnabled())" ) but
> >>> again if
> >>> all the logging calls are in a single aspect thats not so useful.
> >>>
> >>
> >> Makes sense to me. If we go the aspectj route for tracing method
> >> entry/exit, I agree that using the JDK logger directly is simpler.
> >>
> >
> > Since the aspect is on the side, we're flexible. JDK logger can be
> > default and it can be replaced easily if the embedders or users choose
> > to do so.
> >
> >> A few more questions on this: What dependencies will aspectj add to
> >> our distribution? aspectjweaver is more than 1Mb, do we need it?
> >
> >
> > I'll try to spend some time to explore both the compile-time and
> > load-time weaving.
> >
> >>
> >>> What about mid-method logging of specific interesting events, for
> >>> example
> >>> the contents of requests as the enter and leave bindings and
> >>> implementation
> >>> types and things like that? That sort of logging is often all a lot
> >>> of users
> >>> want to see not the detail tracing of every method entry/exit. Could
> >>> we add
> >>> things like this in specific places?
> >>>
> +1 for the ability to produce this level of information. This is my
> preferred approach for debugging or understanding how some part of the
> code works. Having every method entry and exit produce a trace line
> often creates a huge amount of output that obscures the essential details
> of what is happening.
>
> >>
> >> Can this mid-method logging be split in two categories?
> >>
> >> a) Debug tracing
> >> A simple solution is to split the method in two, and then leverage the
> >> entry/exit method tracing as discussed above.
> >
> In many cases this would lead to a convoluted code structure with local
> variables needing to be passed as parameters between the two methods, or
> methods that contain a single line of code (if a trace line needs to be
> produced from within a loop).
>
> >
> > We can use JDK logger to add statements in the middle of a method. Then
> > we can use an aspect to capture such calls to dump out the information.
> >
> > For example, if we have the following statement in a method:
> > logger.debug(...);
> > The apsect can trap it by a point cut like "call *
> > java.util.logger.Logger.debug(..).
> >
> If the logger call is already there, why is an aspect needed to trap it?
> Why not just let it execute?
>
> >>
> >> b) End-user readable information (info that a binding is
> >> sending/receiving a message for example)
> >> This falls into the second category discussed in this thread,
> >> reporting significant events to a management console.
> >
> >
> > The above suggestion should help too. The key here is to have some calls
>
> > to indicate such requirements and they can be then trapped to provide
> > the concrete logic.
> >
> >>
> >> I think we're starting to see concrete solutions for (a) with aspectj.
> >> I have not seen any real concrete proposal for (b) yet.
> >>
> >> --
> >> Jean-Sebastien
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
I agree that entry and exit tracing can be overwhelming in a lot of
situations. I think this is an advantage of taking the AspectJ approach. If
people want to add this kind of tracing then we can make that possible with
no direct impact on the tuscany code base.
A concrete proposal for other messages...
I've been poking around to see what others do and, on closer inspection, CXF
have a rather nice, IMHO, approach which is a combination of a home grown
logging util class and the JDK logger that.
uses parameters to reduce the formatting load for inactive log statements
uses message property files for message lookup
encompasses basic internationalization support using ICU and the message
files behind the scenes
handles exceptions and strings (although it doesn't localize exception
strings)
SLF4J does very similar things to this but we didn't seem to get much
traction with that before on this thread. It seems that we all have
different requirements for reducing dependencies vs providing logging
function. If we can reach a satisfactory level of function while relying on
the built in JDK logging features then that seems to be a good compromise.
Also with some home grown utilities we can at least make life a little
easier for ourselves in terms of recording user oriented messages related to
model elements.
Looking at the CXF code this is what you build.
MyModule
src
main
java
somepath
SomeTuscanyClassA
Messages.properties
resources
logging.properties
Nothing too surprising there. They have a LogUtil class (see
cxf-common-utilities) which provides an interface for getting JDK loggers
and for logging with them. I'm assuming they created it but we should check.
Here is an example of how to use it.
import java.util.logging.Level;
import java.util.logging.Logger;
import org.apache.cxf.common.logging.LogUtils;
public class SomeTuscanyClassA {
private static final Logger Log1 = LogUtils.getL7dLogger (
SomeTuscanyClassA.class);
public SomeTuscanyClassA() {
Integer params[] = {8, 9, 4};
LogUtils.log(Log1,
Level.INFO,
"TEST_MESSAGE",
null,
(Object[])params);
Exception ex = new IllegalStateException("some exception string");
LogUtils.log(Log1,
Level.INFO ,
"TEST_MESSAGE",
ex,
(Object[])params);
}
We could then extend this to allow for common Tuscany situations. For
example, by allowing a model element to be passed in,
LogUtils.log(Log1,
Level.INFO,
composite, // or some other specialization of Base
where the component name, uri can be read from
"TEST_MESSAGE",
null,
(Object[])params);
We could then chose to use
SEVERE
WARNING
INFO
CONFIG
To record our end user readable information. This proposal assumes people
are comfortable with committing to JDK logging. If people are comfortable
with this then I don't see why we can't use.
FINE
FINER
FINEST
for mid method tracing.
So is this going in the right direction? Or do people have completely
different approaches in mind?
Regards
Simon
Re: Monitoring, logging and exceptions (again)
Posted by Simon Nash <na...@hursley.ibm.com>.
See inline.
Simon
Raymond Feng wrote:
> Comments inline.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Friday, August 17, 2007 9:27 AM
> Subject: Re: Monitoring, logging and exceptions (again)
>
>
>> [snip]
>> ant elder wrote:
>>
>>> And also my 2p inline...
>>>
>>> ...ant
>>>
>>> On 8/16/07, Simon Laws <si...@googlemail.com> wrote:
>>>
>>>> A number of different requirements have been discussed and solutions
>>>> proposed. My 2p (I'm using Raymond's definitions b.t.w)
>>>>
>>>> Tracing: Dump out input/output/exception for method calls for the
>>>> purpose
>>>> of
>>>> debugging/troubleshooting. (Target for developers/technical support)
>>>>
>>>> I feel that tracing of execution paths through the Tuscany codebase
>>>> would
>>>> be
>>>> useful but agree that " it's a lot of work and will be difficult to
>>>> maintain
>>>> and keep consistent" if we did it manually. I'm happy that this is the
>>>> responsibility of whoever wants to trace through the code and not a
>>>> core
>>>> part of the codebase. For the Tuscany developer community AspectJ have
>>>> been
>>>> proposed a couple of times and support has been prototyped. We could
>>>> choose
>>>> SLF4J as the interface through which messages are output.
>>>>
>>>
>>>
>>> I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J is a
>>> facade for logging APIs, so you can code to the SLF4J API and then
>>> plug in
>>> whatever logging impl you like, but if the only logging calls we have
>>> are
>>> confined to a single tracing aspect we might as well just code that
>>> aspect
>>> to a specific logging API like JDK logging. That avoids the extra
>>> dependency
>>> on SLF4J and anyone can add additional aspects if they really want to
>>> use a
>>> different logger. The main other benefit of SLF4J is its parameterized
>>> message logging (avoids all the "if(logger.isDebugEnabled())" ) but
>>> again if
>>> all the logging calls are in a single aspect thats not so useful.
>>>
>>
>> Makes sense to me. If we go the aspectj route for tracing method
>> entry/exit, I agree that using the JDK logger directly is simpler.
>>
>
> Since the aspect is on the side, we're flexible. JDK logger can be
> default and it can be replaced easily if the embedders or users choose
> to do so.
>
>> A few more questions on this: What dependencies will aspectj add to
>> our distribution? aspectjweaver is more than 1Mb, do we need it?
>
>
> I'll try to spend some time to explore both the compile-time and
> load-time weaving.
>
>>
>>> What about mid-method logging of specific interesting events, for
>>> example
>>> the contents of requests as the enter and leave bindings and
>>> implementation
>>> types and things like that? That sort of logging is often all a lot
>>> of users
>>> want to see not the detail tracing of every method entry/exit. Could
>>> we add
>>> things like this in specific places?
>>>
+1 for the ability to produce this level of information. This is my
preferred approach for debugging or understanding how some part of the
code works. Having every method entry and exit produce a trace line
often creates a huge amount of output that obscures the essential details
of what is happening.
>>
>> Can this mid-method logging be split in two categories?
>>
>> a) Debug tracing
>> A simple solution is to split the method in two, and then leverage the
>> entry/exit method tracing as discussed above.
>
In many cases this would lead to a convoluted code structure with local
variables needing to be passed as parameters between the two methods, or
methods that contain a single line of code (if a trace line needs to be
produced from within a loop).
>
> We can use JDK logger to add statements in the middle of a method. Then
> we can use an aspect to capture such calls to dump out the information.
>
> For example, if we have the following statement in a method:
> logger.debug(...);
> The apsect can trap it by a point cut like "call *
> java.util.logger.Logger.debug(..).
>
If the logger call is already there, why is an aspect needed to trap it?
Why not just let it execute?
>>
>> b) End-user readable information (info that a binding is
>> sending/receiving a message for example)
>> This falls into the second category discussed in this thread,
>> reporting significant events to a management console.
>
>
> The above suggestion should help too. The key here is to have some calls
> to indicate such requirements and they can be then trapped to provide
> the concrete logic.
>
>>
>> I think we're starting to see concrete solutions for (a) with aspectj.
>> I have not seen any real concrete proposal for (b) yet.
>>
>> --
>> Jean-Sebastien
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Monitoring, logging and exceptions (again)
Posted by Raymond Feng <en...@gmail.com>.
Comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Friday, August 17, 2007 9:27 AM
Subject: Re: Monitoring, logging and exceptions (again)
> [snip]
> ant elder wrote:
>> And also my 2p inline...
>>
>> ...ant
>>
>> On 8/16/07, Simon Laws <si...@googlemail.com> wrote:
>>
>>> A number of different requirements have been discussed and solutions
>>> proposed. My 2p (I'm using Raymond's definitions b.t.w)
>>>
>>> Tracing: Dump out input/output/exception for method calls for the
>>> purpose
>>> of
>>> debugging/troubleshooting. (Target for developers/technical support)
>>>
>>> I feel that tracing of execution paths through the Tuscany codebase
>>> would
>>> be
>>> useful but agree that " it's a lot of work and will be difficult to
>>> maintain
>>> and keep consistent" if we did it manually. I'm happy that this is the
>>> responsibility of whoever wants to trace through the code and not a core
>>> part of the codebase. For the Tuscany developer community AspectJ have
>>> been
>>> proposed a couple of times and support has been prototyped. We could
>>> choose
>>> SLF4J as the interface through which messages are output.
>>>
>>
>>
>> I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J is a
>> facade for logging APIs, so you can code to the SLF4J API and then plug
>> in
>> whatever logging impl you like, but if the only logging calls we have are
>> confined to a single tracing aspect we might as well just code that
>> aspect
>> to a specific logging API like JDK logging. That avoids the extra
>> dependency
>> on SLF4J and anyone can add additional aspects if they really want to use
>> a
>> different logger. The main other benefit of SLF4J is its parameterized
>> message logging (avoids all the "if(logger.isDebugEnabled())" ) but again
>> if
>> all the logging calls are in a single aspect thats not so useful.
>>
>
> Makes sense to me. If we go the aspectj route for tracing method
> entry/exit, I agree that using the JDK logger directly is simpler.
>
Since the aspect is on the side, we're flexible. JDK logger can be default
and it can be replaced easily if the embedders or users choose to do so.
> A few more questions on this: What dependencies will aspectj add to our
> distribution? aspectjweaver is more than 1Mb, do we need it?
I'll try to spend some time to explore both the compile-time and load-time
weaving.
>
>> What about mid-method logging of specific interesting events, for example
>> the contents of requests as the enter and leave bindings and
>> implementation
>> types and things like that? That sort of logging is often all a lot of
>> users
>> want to see not the detail tracing of every method entry/exit. Could we
>> add
>> things like this in specific places?
>>
>
> Can this mid-method logging be split in two categories?
>
> a) Debug tracing
> A simple solution is to split the method in two, and then leverage the
> entry/exit method tracing as discussed above.
We can use JDK logger to add statements in the middle of a method. Then we
can use an aspect to capture such calls to dump out the information.
For example, if we have the following statement in a method:
logger.debug(...);
The apsect can trap it by a point cut like "call *
java.util.logger.Logger.debug(..).
>
> b) End-user readable information (info that a binding is sending/receiving
> a message for example)
> This falls into the second category discussed in this thread, reporting
> significant events to a management console.
The above suggestion should help too. The key here is to have some calls to
indicate such requirements and they can be then trapped to provide the
concrete logic.
>
> I think we're starting to see concrete solutions for (a) with aspectj. I
> have not seen any real concrete proposal for (b) yet.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Monitoring, logging and exceptions (again)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
ant elder wrote:
> And also my 2p inline...
>
> ...ant
>
> On 8/16/07, Simon Laws <si...@googlemail.com> wrote:
>
>> A number of different requirements have been discussed and solutions
>> proposed. My 2p (I'm using Raymond's definitions b.t.w)
>>
>> Tracing: Dump out input/output/exception for method calls for the purpose
>> of
>> debugging/troubleshooting. (Target for developers/technical support)
>>
>> I feel that tracing of execution paths through the Tuscany codebase would
>> be
>> useful but agree that " it's a lot of work and will be difficult to
>> maintain
>> and keep consistent" if we did it manually. I'm happy that this is the
>> responsibility of whoever wants to trace through the code and not a core
>> part of the codebase. For the Tuscany developer community AspectJ have
>> been
>> proposed a couple of times and support has been prototyped. We could
>> choose
>> SLF4J as the interface through which messages are output.
>>
>
>
> I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J is a
> facade for logging APIs, so you can code to the SLF4J API and then plug in
> whatever logging impl you like, but if the only logging calls we have are
> confined to a single tracing aspect we might as well just code that aspect
> to a specific logging API like JDK logging. That avoids the extra dependency
> on SLF4J and anyone can add additional aspects if they really want to use a
> different logger. The main other benefit of SLF4J is its parameterized
> message logging (avoids all the "if(logger.isDebugEnabled())" ) but again if
> all the logging calls are in a single aspect thats not so useful.
>
Makes sense to me. If we go the aspectj route for tracing method
entry/exit, I agree that using the JDK logger directly is simpler.
A few more questions on this: What dependencies will aspectj add to our
distribution? aspectjweaver is more than 1Mb, do we need it?
> What about mid-method logging of specific interesting events, for example
> the contents of requests as the enter and leave bindings and implementation
> types and things like that? That sort of logging is often all a lot of users
> want to see not the detail tracing of every method entry/exit. Could we add
> things like this in specific places?
>
Can this mid-method logging be split in two categories?
a) Debug tracing
A simple solution is to split the method in two, and then leverage the
entry/exit method tracing as discussed above.
b) End-user readable information (info that a binding is
sending/receiving a message for example)
This falls into the second category discussed in this thread, reporting
significant events to a management console.
I think we're starting to see concrete solutions for (a) with aspectj. I
have not seen any real concrete proposal for (b) yet.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Monitoring, logging and exceptions (again)
Posted by ant elder <an...@gmail.com>.
And also my 2p inline...
...ant
On 8/16/07, Simon Laws <si...@googlemail.com> wrote:
>
> A number of different requirements have been discussed and solutions
> proposed. My 2p (I'm using Raymond's definitions b.t.w)
>
> Tracing: Dump out input/output/exception for method calls for the purpose
> of
> debugging/troubleshooting. (Target for developers/technical support)
>
> I feel that tracing of execution paths through the Tuscany codebase would
> be
> useful but agree that " it's a lot of work and will be difficult to
> maintain
> and keep consistent" if we did it manually. I'm happy that this is the
> responsibility of whoever wants to trace through the code and not a core
> part of the codebase. For the Tuscany developer community AspectJ have
> been
> proposed a couple of times and support has been prototyped. We could
> choose
> SLF4J as the interface through which messages are output.
I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J is a
facade for logging APIs, so you can code to the SLF4J API and then plug in
whatever logging impl you like, but if the only logging calls we have are
confined to a single tracing aspect we might as well just code that aspect
to a specific logging API like JDK logging. That avoids the extra dependency
on SLF4J and anyone can add additional aspects if they really want to use a
different logger. The main other benefit of SLF4J is its parameterized
message logging (avoids all the "if(logger.isDebugEnabled())" ) but again if
all the logging calls are in a single aspect thats not so useful.
What about mid-method logging of specific interesting events, for example
the contents of requests as the enter and leave bindings and implementation
types and things like that? That sort of logging is often all a lot of users
want to see not the detail tracing of every method entry/exit. Could we add
things like this in specific places?
<snip>
Logging: Produce end-user readable information (info/warning/error) which is
> subject to I18N/L10N.
>
> This seems to be one we have not really nailed down and it's probably the
> most important one. In this category I include anything where we want to
> write a message to a management console or log for a human user to read.
> In
> most cases it is unlikely to be Tuscany's log but the log of whoever is
> embedding the Tuscany code. I only differentiate this from the previous
> category as we are expecting human readable messages to be produced. In
> truth it might be the same interface. Let me provide concrete examples
> from
> the current code.
>
> From CompositeWireBuider.wireComposite()
>
> if (!promoted) {
> warning("No targets for reference: " +
> componentReference.getName(), composite);
> }
>
> From ContributionServiceImpl. readContributionMetadata
>
> } catch (XMLStreamException e) {
> throw new InvalidContributionMetadataException("Invalid
> contribution metadata for contribution.");
>
> }
Do we really need to internationalize the exception messages? That seems a
bit overkill to me, lots of (even commercial) software doesn't do that.
A little off topic, but do we need an InvalidContributionMetadataException
if the message is "Invalid contribution metadata for contribution"? It could
be just a generic exception with that message text. I don't really like the
way we have a zillion different exception classes, some of those
impl.javapackages have more exceptions than code making it real hard
to see the
actual code. It seems like its an attempt to avoid having to do
internationalization - "if it had a message it would need to be translated
so just make the class name the message text and then it wont have to be." -
but that doesn't actually make it any easier for non-english speakers.
Unless there's some reason someone would likely want to catch a specific
exception i think its better to just use a generic exception class with a
specific message.
> We need a consistent interface that allows us to record at least.
>
> The SCA artefact to which the message relates, e.g. the uri of the
> contribution, composite, component, reference, service etc
> The message (or message identifier) we can take
> internationalization/localization into account.
> Any parameters associated with the message
>
> Behind this interface is whatever, pluggable, platform mechanisms are
> required to get this information to the right place. How about we bring a
> monitoring module back to life?
Can you remind me what the monitoring module did?
...ant
Re: Monitoring, logging and exceptions (again)
Posted by Simon Laws <si...@googlemail.com>.
On 8/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 8/10/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> >> Simon Laws wrote:
> >>
> >>> On 8/8/07, ant elder <an...@gmail.com> wrote:
> >>>
> >>>
> >>>> On 8/7/07, Simon Laws <si...@googlemail.com> wrote:
> >>>>
> >>>>
> >>>>> We talked about this before (
> >>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/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/%3c462CF172.9090304@apache.org%3e
> >>
> >> Thoughts?
> >>
> >
> >
> > There were several posts on that referenced thread less keen on using
> > aspects - [1], [2], [3]. Aspects are cool, but I think I'd still favour
> the
> > simplicity of the more traditional approach of explicit logging calls
> in
> > Tuscany.
> >
> > ...ant
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/%3c71e1b5740704180351q31598a45vb2349a260bb14341@mail.gmail.com%3e
> > [2]
> >
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/%3cc0c051b50704180503w45f09a3aja872fbcc8d589143@mail.gmail.com%3e
> > [3]
> >
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/%3c462F689A.7060709@gmail.com%3e
> >
> >
>
> OK then, I don't care much about whether or not we use aspects, but I
> think that calls to trace method entry/exit+parameters should be
> externalized and inserted automatically when we build Tuscany, as IMO
> writing all these repetitive calls by hand will be problematic:
> - it's a lot of work and will be difficult to maintain and keep
> consistent (when methods are renamed, parameters added etc.)
> - it puts a big requirement on people contributing Tuscany extensions to
> write all these calls in their extensions as well
> - it will make Tuscany difficult to integrate in an environment using a
> different logging framework
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> A number of different requirements have been discussed and solutions
proposed. My 2p (I'm using Raymond's definitions b.t.w)
Tracing: Dump out input/output/exception for method calls for the purpose of
debugging/troubleshooting. (Target for developers/technical support)
I feel that tracing of execution paths through the Tuscany codebase would be
useful but agree that " it's a lot of work and will be difficult to maintain
and keep consistent" if we did it manually. I'm happy that this is the
responsibility of whoever wants to trace through the code and not a core
part of the codebase. For the Tuscany developer community AspectJ have been
proposed a couple of times and support has been prototyped. We could choose
SLF4J as the interface through which messages are output.
Monitoring: Listen on the events generated by Tuscany, for example, a
component is started or stopped.
We have had very little discussion about this. I expect this is because it
is generally accepted that from a management point of view it will be useful
to be able to tell which components are started, stopped etc. This will
likely be satisfied by Tuscany specific code at a fairly generic level, i.e.
it won't appear in many modules.
Logging: Produce end-user readable information (info/warning/error) which is
subject to I18N/L10N.
This seems to be one we have not really nailed down and it's probably the
most important one. In this category I include anything where we want to
write a message to a management console or log for a human user to read. In
most cases it is unlikely to be Tuscany's log but the log of whoever is
embedding the Tuscany code. I only differentiate this from the previous
category as we are expecting human readable messages to be produced. In
truth it might be the same interface. Let me provide concrete examples from
the current code.
>From CompositeWireBuider.wireComposite()
if (!promoted) {
warning("No targets for reference: " +
componentReference.getName(), composite);
}
>From ContributionServiceImpl. readContributionMetadata
} catch (XMLStreamException e) {
throw new InvalidContributionMetadataException("Invalid
contribution metadata for contribution.");
}
We need a consistent interface that allows us to record at least.
The SCA artefact to which the message relates, e.g. the uri of the
contribution, composite, component, reference, service etc
The message (or message identifier) we can take
internationalization/localization into account.
Any parameters associated with the message
Behind this interface is whatever, pluggable, platform mechanisms are
required to get this information to the right place. How about we bring a
monitoring module back to life?
Jeff also talked about " ...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.
". It sounds like these are features distinct from how we handle events from
the Tuscany code itself. Is that correct?
Regards
Simon
Re: Monitoring, logging and exceptions (again)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 8/10/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
>> Simon Laws wrote:
>>
>>> On 8/8/07, ant elder <an...@gmail.com> wrote:
>>>
>>>
>>>> On 8/7/07, Simon Laws <si...@googlemail.com> wrote:
>>>>
>>>>
>>>>> We talked about this before (
>>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/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/%3c462CF172.9090304@apache.org%3e
>>
>> Thoughts?
>>
>
>
> There were several posts on that referenced thread less keen on using
> aspects - [1], [2], [3]. Aspects are cool, but I think I'd still favour the
> simplicity of the more traditional approach of explicit logging calls in
> Tuscany.
>
> ...ant
>
> [1]
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/%3c71e1b5740704180351q31598a45vb2349a260bb14341@mail.gmail.com%3e
> [2]
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/%3cc0c051b50704180503w45f09a3aja872fbcc8d589143@mail.gmail.com%3e
> [3]
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/%3c462F689A.7060709@gmail.com%3e
>
>
OK then, I don't care much about whether or not we use aspects, but I
think that calls to trace method entry/exit+parameters should be
externalized and inserted automatically when we build Tuscany, as IMO
writing all these repetitive calls by hand will be problematic:
- it's a lot of work and will be difficult to maintain and keep
consistent (when methods are renamed, parameters added etc.)
- it puts a big requirement on people contributing Tuscany extensions to
write all these calls in their extensions as well
- it will make Tuscany difficult to integrate in an environment using a
different logging framework
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Monitoring, logging and exceptions (again)
Posted by ant elder <an...@gmail.com>.
On 8/10/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Simon Laws wrote:
> > On 8/8/07, ant elder <an...@gmail.com> wrote:
> >
> >> On 8/7/07, Simon Laws <si...@googlemail.com> wrote:
> >>
> >>> We talked about this before (
> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/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/%3c462CF172.9090304@apache.org%3e
>
> Thoughts?
There were several posts on that referenced thread less keen on using
aspects - [1], [2], [3]. Aspects are cool, but I think I'd still favour the
simplicity of the more traditional approach of explicit logging calls in
Tuscany.
...ant
[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/%3c71e1b5740704180351q31598a45vb2349a260bb14341@mail.gmail.com%3e
[2]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/%3cc0c051b50704180503w45f09a3aja872fbcc8d589143@mail.gmail.com%3e
[3]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/%3c462F689A.7060709@gmail.com%3e
RE: Monitoring, logging and exceptions (again)
Posted by "Anderson, Jeff T (CA - Toronto)" <je...@deloitte.ca>.
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:gengshaoguang@yahoo.com]
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 <js...@apache.org> 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: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------
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 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.
****************************************************************
Re: Monitoring, logging and exceptions (again)
Posted by shaoguang geng <ge...@yahoo.com>.
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 <js...@apache.org> 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: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------
Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.
RE: Monitoring, logging and exceptions (again)
Posted by "Anderson, Jeff T (CA - Toronto)" <je...@deloitte.ca>.
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:jsdelfino@apache.org]
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: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
-----------------------------------------
**************************************************************************************
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.
****************************************************************
Re: Monitoring, logging and exceptions (again)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: Monitoring, logging and exceptions (again)
Posted by "Anderson, Jeff T (CA - Toronto)" <je...@deloitte.ca>.
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:enjoyjava@gmail.com]
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)" <je...@deloitte.ca>
To: <tu...@ws.apache.org>; <tu...@ws.apache.org>
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:enjoyjava@gmail.com]
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" <js...@apache.org>
To: <tu...@ws.apache.org>
Cc: "tuscany-user" <tu...@ws.apache.org>
Sent: Friday, August 10, 2007 2:41 PM
Subject: Re: Monitoring, logging and exceptions (again)
> Simon Laws wrote:
>> On 8/8/07, ant elder <an...@gmail.com> wrote:
>>
>>> On 8/7/07, Simon Laws <si...@googlemail.com> wrote:
>>>
>>>> We talked about this before (
>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/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/%3c462CF172.9090304@apache.org%3e
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
-----------------------------------------
**************************************************************************************
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: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
-----------------------------------------
**************************************************************************************
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.
**************************************************************************************
Re: Monitoring, logging and exceptions (again)
Posted by Raymond Feng <en...@gmail.com>.
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)" <je...@deloitte.ca>
To: <tu...@ws.apache.org>; <tu...@ws.apache.org>
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:enjoyjava@gmail.com]
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" <js...@apache.org>
To: <tu...@ws.apache.org>
Cc: "tuscany-user" <tu...@ws.apache.org>
Sent: Friday, August 10, 2007 2:41 PM
Subject: Re: Monitoring, logging and exceptions (again)
> Simon Laws wrote:
>> On 8/8/07, ant elder <an...@gmail.com> wrote:
>>
>>> On 8/7/07, Simon Laws <si...@googlemail.com> wrote:
>>>
>>>> We talked about this before (
>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/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/%3c462CF172.9090304@apache.org%3e
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
-----------------------------------------
**************************************************************************************
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: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: Monitoring, logging and exceptions (again)
Posted by "Anderson, Jeff T (CA - Toronto)" <je...@deloitte.ca>.
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:enjoyjava@gmail.com]
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" <js...@apache.org>
To: <tu...@ws.apache.org>
Cc: "tuscany-user" <tu...@ws.apache.org>
Sent: Friday, August 10, 2007 2:41 PM
Subject: Re: Monitoring, logging and exceptions (again)
> Simon Laws wrote:
>> On 8/8/07, ant elder <an...@gmail.com> wrote:
>>
>>> On 8/7/07, Simon Laws <si...@googlemail.com> wrote:
>>>
>>>> We talked about this before (
>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/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/%3c462CF172.9090304@apache.org%3e
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
-----------------------------------------
**************************************************************************************
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.
****************************************************************
Re: Monitoring, logging and exceptions (again)
Posted by Raymond Feng <en...@gmail.com>.
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" <js...@apache.org>
To: <tu...@ws.apache.org>
Cc: "tuscany-user" <tu...@ws.apache.org>
Sent: Friday, August 10, 2007 2:41 PM
Subject: Re: Monitoring, logging and exceptions (again)
> Simon Laws wrote:
>> On 8/8/07, ant elder <an...@gmail.com> wrote:
>>
>>> On 8/7/07, Simon Laws <si...@googlemail.com> wrote:
>>>
>>>> We talked about this before (
>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/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/%3c462CF172.9090304@apache.org%3e
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Monitoring, logging and exceptions (again)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On 8/8/07, ant elder <an...@gmail.com> wrote:
>
>> On 8/7/07, Simon Laws <si...@googlemail.com> wrote:
>>
>>> We talked about this before (
>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/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/%3c462CF172.9090304@apache.org%3e
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Monitoring, logging and exceptions (again)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On 8/8/07, ant elder <an...@gmail.com> wrote:
>
>> On 8/7/07, Simon Laws <si...@googlemail.com> wrote:
>>
>>> We talked about this before (
>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/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/%3c462CF172.9090304@apache.org%3e
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org