[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524447 ] Ralph Goers commented on COCOON-1765: - Daniel, all you did was repeat back what I said. It hasn't answered my concern. In Cocoon 2.1 we use the Avalon logger API. We provide a couple of implementation but anyone can write an implementation of this API to plug in their own logging framework (as I have done). As I understand the pages referenced above PAX will bind the client using a particular API with the implementation of that API in a separate bundle. So it looks to me that if Cocoon used the log4j api that it would be tied to the log4j pax bundle, which is unacceptable. If this is correct then it is a requirement that Cocoon 2.2 continue to use an abstract logging api such as the Avalon logger. Is this clear or do I misunderstand what PAX does? Logging --- Key: COCOON-1765 URL: https://issues.apache.org/jira/browse/COCOON-1765 Project: Cocoon Issue Type: New Feature Components: - OSGi integration Reporter: Reinhard Poetz [...] But my main thoughts is that logging need to be a centralized service, common for all blocks (separate logging solutions for each block would be a pain). The logging implementation is contained in a block (that is installed early) and makes the logger available as a service that other block can get through the service manager. This way the logging implementation is chosen by the choice of logging block. Observe that I only is talking about the blocks fw, within a block an ordinary ECM can be set up and it will inject the logger in its managed objects through the usual Avalon style. Using the same logger interface everywhere is also practical I guess we continue to use the o.a.avalon.framework.logger.Logger one. (by Daniel Fagerstrom: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113889468124728w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524448 ] Carsten Ziegeler commented on COCOON-1765: -- Can we have such discussions in the mailing list please? Logging --- Key: COCOON-1765 URL: https://issues.apache.org/jira/browse/COCOON-1765 Project: Cocoon Issue Type: New Feature Components: - OSGi integration Reporter: Reinhard Poetz [...] But my main thoughts is that logging need to be a centralized service, common for all blocks (separate logging solutions for each block would be a pain). The logging implementation is contained in a block (that is installed early) and makes the logger available as a service that other block can get through the service manager. This way the logging implementation is chosen by the choice of logging block. Observe that I only is talking about the blocks fw, within a block an ordinary ECM can be set up and it will inject the logger in its managed objects through the usual Avalon style. Using the same logger interface everywhere is also practical I guess we continue to use the o.a.avalon.framework.logger.Logger one. (by Daniel Fagerstrom: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113889468124728w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524387 ] Daniel Fagerstrom commented on COCOON-1765: --- I use Pax Logging in the whiteboard and it works well. But there is work left to do on logging configuration and on decide if the OSGi logiing service from OPS4J should be used or not. Logging --- Key: COCOON-1765 URL: https://issues.apache.org/jira/browse/COCOON-1765 Project: Cocoon Issue Type: New Feature Components: - Servlet service framework Reporter: Reinhard Poetz [...] But my main thoughts is that logging need to be a centralized service, common for all blocks (separate logging solutions for each block would be a pain). The logging implementation is contained in a block (that is installed early) and makes the logger available as a service that other block can get through the service manager. This way the logging implementation is chosen by the choice of logging block. Observe that I only is talking about the blocks fw, within a block an ordinary ECM can be set up and it will inject the logger in its managed objects through the usual Avalon style. Using the same logger interface everywhere is also practical I guess we continue to use the o.a.avalon.framework.logger.Logger one. (by Daniel Fagerstrom: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113889468124728w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524400 ] Ralph Goers commented on COCOON-1765: - I don't care what is used as long as it is an interface that can have any implementation (including a proprietary logging framework) plugged in. Logging --- Key: COCOON-1765 URL: https://issues.apache.org/jira/browse/COCOON-1765 Project: Cocoon Issue Type: New Feature Components: - OSGi integration Reporter: Reinhard Poetz [...] But my main thoughts is that logging need to be a centralized service, common for all blocks (separate logging solutions for each block would be a pain). The logging implementation is contained in a block (that is installed early) and makes the logger available as a service that other block can get through the service manager. This way the logging implementation is chosen by the choice of logging block. Observe that I only is talking about the blocks fw, within a block an ordinary ECM can be set up and it will inject the logger in its managed objects through the usual Avalon style. Using the same logger interface everywhere is also practical I guess we continue to use the o.a.avalon.framework.logger.Logger one. (by Daniel Fagerstrom: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113889468124728w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524403 ] Daniel Fagerstrom commented on COCOON-1765: --- Pax logging supports all major logging framework in an OSGi friendly way. Currently I just use it as an (better) implementation of Commons Logging. All the classloading tricks of the ordinary Commons Logging implementation makes it frustrating to use in an OSGi environment. The point with using the Pax OSGi logging service from OPS4J in combination with the Commons Logging implementation would be that the logging output would be available though the API of the OSGi logging service. But at this point I don't know whether that would be useful or not, so it can wait. Logging --- Key: COCOON-1765 URL: https://issues.apache.org/jira/browse/COCOON-1765 Project: Cocoon Issue Type: New Feature Components: - OSGi integration Reporter: Reinhard Poetz [...] But my main thoughts is that logging need to be a centralized service, common for all blocks (separate logging solutions for each block would be a pain). The logging implementation is contained in a block (that is installed early) and makes the logger available as a service that other block can get through the service manager. This way the logging implementation is chosen by the choice of logging block. Observe that I only is talking about the blocks fw, within a block an ordinary ECM can be set up and it will inject the logger in its managed objects through the usual Avalon style. Using the same logger interface everywhere is also practical I guess we continue to use the o.a.avalon.framework.logger.Logger one. (by Daniel Fagerstrom: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113889468124728w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524405 ] Ralph Goers commented on COCOON-1765: - I looked at the link posted by Reinhard. While the doc clealy states that it supports several different logging frameworks the examples still have the client code using a particular implementation. In other words, it looks to me like I could create my own PAX implementation but if the client has coded to log4j's api then my implementation wouldn't work. Please correct me if I misunderstand how it works, but if that is the case then it doesn't meet the requirements. Logging --- Key: COCOON-1765 URL: https://issues.apache.org/jira/browse/COCOON-1765 Project: Cocoon Issue Type: New Feature Components: - OSGi integration Reporter: Reinhard Poetz [...] But my main thoughts is that logging need to be a centralized service, common for all blocks (separate logging solutions for each block would be a pain). The logging implementation is contained in a block (that is installed early) and makes the logger available as a service that other block can get through the service manager. This way the logging implementation is chosen by the choice of logging block. Observe that I only is talking about the blocks fw, within a block an ordinary ECM can be set up and it will inject the logger in its managed objects through the usual Avalon style. Using the same logger interface everywhere is also practical I guess we continue to use the o.a.avalon.framework.logger.Logger one. (by Daniel Fagerstrom: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113889468124728w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1765) Logging
[ https://issues.apache.org/jira/browse/COCOON-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524437 ] Daniel Fagerstrom commented on COCOON-1765: --- When I look at the same link I find client code examples for Log4J, Jakarta Commons Logging, SLF4J, Avalon Logging, JDK Logging, Knopflerfish Log and Pax Logging in the client code section. Also they are moving their documentation to Confluence, a newer version of the document can be found here http://wiki.ops4j.org/confluence/display/ops4j/Pax+Logging. Logging --- Key: COCOON-1765 URL: https://issues.apache.org/jira/browse/COCOON-1765 Project: Cocoon Issue Type: New Feature Components: - OSGi integration Reporter: Reinhard Poetz [...] But my main thoughts is that logging need to be a centralized service, common for all blocks (separate logging solutions for each block would be a pain). The logging implementation is contained in a block (that is installed early) and makes the logger available as a service that other block can get through the service manager. This way the logging implementation is chosen by the choice of logging block. Observe that I only is talking about the blocks fw, within a block an ordinary ECM can be set up and it will inject the logger in its managed objects through the usual Avalon style. Using the same logger interface everywhere is also practical I guess we continue to use the o.a.avalon.framework.logger.Logger one. (by Daniel Fagerstrom: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113889468124728w=2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COCOON-1765) Logging
On Thursday 13 April 2006 22:58, Reinhard Poetz (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1765?page=comments#action_12374 349 ] Reinhard Poetz commented on COCOON-1765: Fortunatly one of our latest committers is working on an OSGi logging framework: http://wiki.ops4j.org/dokuwiki/doku.php?id=pax:logging Pax Logging is about letting each thing use their preferred logging system, but having it routed into a Log4J driven backend. So far, it supports a native one, Log4J and Jakarta Commons Logging, and I am trying to figure out how to support JDK logging as well. Of course, I can add support for Avalon Logging API if there is interest. It should not be too hard. Please advice. Cheers Niclas
[jira] Commented: (COCOON-1765) Logging
[ http://issues.apache.org/jira/browse/COCOON-1765?page=comments#action_12374349 ] Reinhard Poetz commented on COCOON-1765: Fortunatly one of our latest committers is working on an OSGi logging framework: http://wiki.ops4j.org/dokuwiki/doku.php?id=pax:logging Logging --- Key: COCOON-1765 URL: http://issues.apache.org/jira/browse/COCOON-1765 Project: Cocoon Type: New Feature Components: - Blocks Framework Reporter: Reinhard Poetz [...] But my main thoughts is that logging need to be a centralized service, common for all blocks (separate logging solutions for each block would be a pain). The logging implementation is contained in a block (that is installed early) and makes the logger available as a service that other block can get through the service manager. This way the logging implementation is chosen by the choice of logging block. Observe that I only is talking about the blocks fw, within a block an ordinary ECM can be set up and it will inject the logger in its managed objects through the usual Avalon style. Using the same logger interface everywhere is also practical I guess we continue to use the o.a.avalon.framework.logger.Logger one. (by Daniel Fagerstrom: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113889468124728w=2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
