Re: Das Logging Framework

[Jim Marino]

Hi Luciano,

Comments inline...
Jim

On Aug 18, 2006, at 10:35 AM, Luciano Resende wrote:

Not sure if I'm just repeating what Robbie just said, but what  
about also
having a common log/trace infrastructure/abstraction between SCA,  
SDO and
DAS, and we could provide a default implementation using a standard  
log
framework (e.g log4J or java native log support) and allow user to  
customize
it by implementing a specific interface and registering/loading it  
somehow ?

It would depend on how it works and it would have to be better than  
what SCA Java already has to justify taking an external dependency.  
In SCA Java, we've externalized everything into a MonitorFactory and  
use a programming model extension to obtain an appropriate monitor  
interface - @Monitor.

My initial concern with the approach you are describing is that it  
seems a lot like Commons Logging, a.k.a. "clogging", which introduces  
a plethora of issues around memory leaks, classloading, and  
versioning clashes. Typically this type of approach winds up  
introducing singletons to obtain a logger. With the current monitor  
approach, we have the ability to swap implementations of logging  
frameworks and avoid the use of singletons, so we don't need to worry  
about managing classloader references that break reloadability and  
lead to memory leaks.

Not being familiar with SDO or DAS code, I'd maybe suggest seeing if  
an externalization mechanism works. We may be able to standardize on  
a common interface:

public interface MonitorFactory {
    /**
     * Initializes MonitorFactory instances with implementation- 
specific configuration properties.
     *
     * @param configProperties a map of named configuration  
properties.  May be null.
     * @throws IllegalArgumentException if the instance can't be  
configured using the supplied properties
     */
    void initialize(Map<String, Object> configProperties);
    /**
     * Return a monitor for a component's monitor interface.
     *
     * @param monitorInterface the component's monitoring interface
     * @return an implementation of the monitoring interface; will  
not be null
     */
    <T> T getMonitor(Class<T> monitorInterface);
}

There could be various independent projects that implemented this for  
logging frameworks such as Log4J or whatever people wanted to use.  
Each project (DAS, SDO, SCA Java) would have its own mechanism for  
passing MonitorFactory references to its subsystems.

Jim


I think today we have :

-SCA
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg01492.html
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg00454.html

SDO
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06377.html

DAS
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06398.html

If people think we could/should have a common framework, I could  
take a
quick look and provide a draft design for discussion.

- Luciano

On 8/18/06, Robbie Minshall <[EMAIL PROTECTED]> wrote:

What do people think about providing various aspects to weave in log
statements for various frameworks.  That way a user could weave in  
the
logging statements of their choice without a complicated  
infrastructure.

. . . thoughts ?

Robbie


On 8/15/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>
> I'm not sure you would want to use the entire thing as is since it
> makes use of the IoC engine. I would maybe look at the  
interfaces in
> org.apache.tuscany.spi.monitor and see if you can use those,
> providing your own mechanism for injecting a monitor into various
> classes. There was also a write-up n the Wiki as I recall that
> explains further.
>
> Jim
>
>
>
>
> On Aug 15, 2006, at 11:48 AM, Luciano Resende wrote:
>
> > Hi Jeremy
> >
> >   What you guys did for SCA, is that something that could be used
> > across
> > other components on the project (e.g.: SDO/DAS) ? Or is something
> > specific
> > to SCA ? Could you point us where in the code to look for that ?
> >
> > - Luciano
> >
> > On 8/15/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> >>
> >> It doesn't matter which logging framework you pick, it will  
be the
> >> wrong one :-)
> >> What I mean is that, as a library, you don't get to pick which
> >> logging framework the application that is using you chose. This
> >> provides a problem where log messages from the library may  
end up
> >> routed separately from the user's messages, or where the user  
needs
> >> to maintain multiple logging configurations.
> >>
> >> What we did in the SCA runtime is externalize logging. Any of  
our
> >> components can define a monitor interface that is independent  
of a
> >> logging framework. The runtime (not the user code) provides an
> >> implementation of that interface that forwards monitoring  
events to a
> >> logging framework that is provided by the user when they boot  
the
> >> runtime.
> >>
> >> There have been a few discussion on the list and I think on  
the wiki
> >> about our Monitoring Framework and MonitorFactory - it might  
be worth
> >> looking for those and see if they would work for DAS.
> >>
> >> --
> >> Jeremy
> >>
> >> On Aug 15, 2006, at 9:26 AM, Darius Dejesus wrote:
> >>
> >> > I've been looking at some of the older JIRA's, and upon  
looking at
> >> > the way
> >> > logging was currently handled in the DAS, inconsistent at  
best, I
> >> > figured
> >> > now would be a good time to throw some questions out there. I
> >> > believe this
> >> > falls under Tucsany-292 and Tuscany-441.
> >> >
> >> > As it stands I'm wondering what logging framework would be  
best for
> >> > the
> >> > project. At this point I've been looking at the libraries  
contained
> >> > in both
> >> > org.apache.log4j and those found in java.util.logging.  
While I'm
> >> > aware that
> >> > log4j is more robust, I'm wondering if it's all needed for  
these
> >> > purposes.
> >> > Not having any prior experiences with either of these logging
> >> > libraries, I'm
> >> > not clear on any extra overhead or other possible issues  
they may
> >> > have.
> >> >
> >> > I'm also curious as to the overall goals of the logging  
system. I
> >> > imagine
> >> > this is more for the user then for us, so in that case all  
message,
> >> > exceptions and what not should probably be separated and  
organized
> >> > in some
> >> > standard way or place ( some logging/debugging directory  
perhaps ).
> >> > Also do
> >> > any of the other subprojects already have some form of  
logging in
> >> > place?
> >> > Should we all be using the same standards and files?
> >> >
> >> > Thats all I'm wondering about so far. I appreciate any  
feedback.
> >> >
> >> > -Darius DeJesus
> >>
> >>
> >>  
---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> > --
> > -----------------------------------------------------
> > Luciano Resende
> > SOA Opensource - Apache Tuscany
> > -----------------------------------------------------
>
>
>  
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
* * * Charlie * * *
Check out some pics of little Charlie at
http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/

* * * Addresss * * *
1914 Overland Drive
Chapel Hill
NC 27517

* * * Number * * *
919-225-1553




--
-----------------------------------------------------
Luciano Resende
SOA Opensource - Apache Tuscany
-----------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]