addendum: I think I was confused about Loggers and Appenders in point f) of my original post.
Anyway, I may have been heading in an entirely wrong direction. Consider this interesting article about logging in an OSGi environment: http://blog.kornr.net/index.php/2008/12/18/osgi-logging-putting-it-all-together I suppose that many insights from that article will apply to SCA (without OSGi) as well. To quote: <quote> I've started my series about logging in OSGi out of the sad notice that most blog entries and comments just missed the point and had an erroneous idea of logging on OSGi, mainly because they are trying to use log4j or the java.logging API as they are used to, without taking into account the drastic change of architecture imposed by the OSGI component model. For instance, implementing a LogService hard-coded to bind on logback or log4j (or any specific engine) is definitely a bad idea: OSGi is all about dynamic component, and the way to go is to build a LogListener backed by logback or log4j, and let it connect to the LogReaderService. That way, not only can we easily *swap* the component in charge of storing/processing the logs, but we can also *combine* several of them if needed. </quote> Are there any plans to support OSGi-compliant logging in Tuscany 2.0? What would be my best approach while working with Tuscany 1.6 to minimize the logging-related migration effort when switching to Tuscany 2.0? Or is it too early to tell? -- Sebastian > -----Original Message----- > From: Millies, Sebastian [mailto:[email protected]] > Sent: Friday, September 10, 2010 11:43 AM > To: [email protected] > Subject: Distributed Logging with SCA and Log4J > > Hello there, > > what are your thoughts on distributed logging with SCA services? > > To me, the obvious approach would be to use the Log4J JMSAppender, > create a JMS provider with a loggingTopic, and write my own > Log4JJMSMessageListener (modelled on org.apache.log4j.net.JMSSink) > to persist the messages whenever one is ready to be consumed. (Perhaps > I would also write my own JMSQueueAppender, because using point-to- > point > instead of pub/sub would seem more logical to me when logging). > > The above would probably work, but it would not involve SCA at all. How > then > would one go about creating an SCA component that offers a logging > service > and can be used in conjunction with an established logging framework > like > Log4J? > > Would I perhaps do the following: > > a) define an SCAAppender by extending org.apache.log4j.AppenderSkeleton > b) provide a LoggingService interface with an append(LoggingEvent) > method > c) make LoggingService available over an SCA binding (e. g. JMS) > d) wrap my SCAAppender in a composite XML file and give it a reference > to LoggingService > e) in SCAAppender.append() delegate to loggingServiceRef.append() > f) implement interface org.apache.log4j.spi.LoggerFactory in my own > SCALoggerFactory class to obtain an instance of the SCAAppender > service > from the SCA domain > g) create all Logger instances in my services through calls of > Logger.getLogger(String, new SCALoggerFactory(String)) > > Does this even make sense in your view, or would it be needlessly > roundabout? > > -- Sebastian
