You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Curt Arnold (JIRA)" <ji...@apache.org> on 2008/06/19 22:39:45 UTC
[jira] Created: (LOG4J2-9) log4j 2.0 should leverage existing
(preferably ASF) configuration frameworks
log4j 2.0 should leverage existing (preferably ASF) configuration frameworks
----------------------------------------------------------------------------
Key: LOG4J2-9
URL: https://issues.apache.org/jira/browse/LOG4J2-9
Project: Log4j 2
Issue Type: Wish
Components: Configurators
Reporter: Curt Arnold
log4j 2.0 should avoid implementing its own configuration framework in preference to being compatible with commonly used configuration frameworks and services. Compatibility with existing log4j 1.2 configuration files might be accomplished by XSLT transforms that convert the legacy format into the equivalent with the selected configuration framework. log4j 2.0 should be readily configurable with JMX and a JMX centric design for configuration may be desirable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [jira] Created: (LOG4J2-9) log4j 2.0 should leverage existing
(preferably ASF) configuration frameworks
Posted by Jess Holle <je...@ptc.com>.
I'd also add that as long as log4j is going to continue to support
multiple LoggerRepository's per JVM the log4j JMX must fully support this.
The lack of such a capability was the clincher for me not using the
existing log4j JMX classes. There were other bugs/issues as well.
Beyond this I also really didn't like the fact that various things that
are logically data collections had each element modeled as a JMX
attribute. I'm not against dynamic attributes -- they make perfect
sense for reflection based coverage of Appender and Layout
implementations, but there were cases [whose details I forget,
unfortunately], where a logical list of data was converted into a
dynamic attribute set -- to ill effect. I used child MBeans for such
cases -- which also allowed for broader/deeper configuration coverage.
--
Jess Holle
Curt Arnold (JIRA) wrote:
> log4j 2.0 should leverage existing (preferably ASF) configuration frameworks
> ----------------------------------------------------------------------------
>
> Key: LOG4J2-9
> URL: https://issues.apache.org/jira/browse/LOG4J2-9
> Project: Log4j 2
> Issue Type: Wish
> Components: Configurators
> Reporter: Curt Arnold
>
>
> log4j 2.0 should avoid implementing its own configuration framework in preference to being compatible with commonly used configuration frameworks and services. Compatibility with existing log4j 1.2 configuration files might be accomplished by XSLT transforms that convert the legacy format into the equivalent with the selected configuration framework. log4j 2.0 should be readily configurable with JMX and a JMX centric design for configuration may be desirable.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-9) log4j 2.0 should leverage existing
(preferably ASF) configuration frameworks
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607245#action_12607245 ]
Ralph Goers commented on LOG4J2-9:
----------------------------------
I am in favor of leveraging Spring for wiring components together. I'm less clear on whether we want to expose it through to the components that have in the past been wired in via the log4j configuration. My first reaction is that it would be OK to allow Appenders, Layouts, etc as Spring beans, but not Loggers. However, if someone has a convincing argument to why everything should be configured via Spring I'm sure I could be convinced.
It seems to me that we need fundamental agreement on whether or not to leverage Spring before we move on.
> log4j 2.0 should leverage existing (preferably ASF) configuration frameworks
> ----------------------------------------------------------------------------
>
> Key: LOG4J2-9
> URL: https://issues.apache.org/jira/browse/LOG4J2-9
> Project: Log4j 2
> Issue Type: Wish
> Components: Configurators
> Reporter: Curt Arnold
>
> log4j 2.0 should avoid implementing its own configuration framework in preference to being compatible with commonly used configuration frameworks and services. Compatibility with existing log4j 1.2 configuration files might be accomplished by XSLT transforms that convert the legacy format into the equivalent with the selected configuration framework. log4j 2.0 should be readily configurable with JMX and a JMX centric design for configuration may be desirable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-9) log4j 2.0 should leverage existing
(preferably ASF) configuration frameworks
Posted by "Curt Arnold (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606558#action_12606558 ]
Curt Arnold commented on LOG4J2-9:
----------------------------------
On Jun 19, 2008, at 3:58 PM, Jess Holle wrote:
I'd also add that as long as log4j is going to continue to support multiple LoggerRepository's per JVM the log4j JMX must fully support this.
The lack of such a capability was the clincher for me not using the existing log4j JMX classes. There were other bugs/issues as well.
Beyond this I also really didn't like the fact that various things that are logically data collections had each element modeled as a JMX attribute. I'm not against dynamic attributes -- they make perfect sense for reflection based coverage of Appender and Layout implementations, but there were cases [whose details I forget, unfortunately], where a logical list of data was converted into a dynamic attribute set -- to ill effect. I used child MBeans for such cases -- which also allowed for broader/deeper configuration coverage.
--
Jess Holle
> log4j 2.0 should leverage existing (preferably ASF) configuration frameworks
> ----------------------------------------------------------------------------
>
> Key: LOG4J2-9
> URL: https://issues.apache.org/jira/browse/LOG4J2-9
> Project: Log4j 2
> Issue Type: Wish
> Components: Configurators
> Reporter: Curt Arnold
>
> log4j 2.0 should avoid implementing its own configuration framework in preference to being compatible with commonly used configuration frameworks and services. Compatibility with existing log4j 1.2 configuration files might be accomplished by XSLT transforms that convert the legacy format into the equivalent with the selected configuration framework. log4j 2.0 should be readily configurable with JMX and a JMX centric design for configuration may be desirable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-9) log4j 2.0 should leverage existing
(preferably ASF) configuration frameworks
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607120#action_12607120 ]
Ralph Goers commented on LOG4J2-9:
----------------------------------
The configuration mechanism needs to be pluggable. It should allow for simple mechanisms such as using commons-digester, or more complex user written configuration. Thus some sort of SPI should be provided.
> log4j 2.0 should leverage existing (preferably ASF) configuration frameworks
> ----------------------------------------------------------------------------
>
> Key: LOG4J2-9
> URL: https://issues.apache.org/jira/browse/LOG4J2-9
> Project: Log4j 2
> Issue Type: Wish
> Components: Configurators
> Reporter: Curt Arnold
>
> log4j 2.0 should avoid implementing its own configuration framework in preference to being compatible with commonly used configuration frameworks and services. Compatibility with existing log4j 1.2 configuration files might be accomplished by XSLT transforms that convert the legacy format into the equivalent with the selected configuration framework. log4j 2.0 should be readily configurable with JMX and a JMX centric design for configuration may be desirable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-9) log4j 2.0 should leverage existing
(preferably ASF) configuration frameworks
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867816#action_12867816 ]
Ralph Goers commented on LOG4J2-9:
----------------------------------
In my experimental branch the configuration is pluggable. I investigated using other frameworks but adding a dependency really isn't worth the cost (and risk that the framework will somehow create a circularity problem). In the end the configuration I implemented is extremely simple.
> log4j 2.0 should leverage existing (preferably ASF) configuration frameworks
> ----------------------------------------------------------------------------
>
> Key: LOG4J2-9
> URL: https://issues.apache.org/jira/browse/LOG4J2-9
> Project: Log4j 2
> Issue Type: Wish
> Components: Configurators
> Reporter: Curt Arnold
>
> log4j 2.0 should avoid implementing its own configuration framework in preference to being compatible with commonly used configuration frameworks and services. Compatibility with existing log4j 1.2 configuration files might be accomplished by XSLT transforms that convert the legacy format into the equivalent with the selected configuration framework. log4j 2.0 should be readily configurable with JMX and a JMX centric design for configuration may be desirable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-9) log4j 2.0 should leverage existing
(preferably ASF) configuration frameworks
Posted by "Paul Smith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607124#action_12607124 ]
Paul Smith commented on LOG4J2-9:
---------------------------------
We should consider Spring as part of this configuration too. I don't have anything off the top of my head in mind here,but since Spring is such a rich configuration environment we should probably not ignore how log4j may fit into a Spring environment.
> log4j 2.0 should leverage existing (preferably ASF) configuration frameworks
> ----------------------------------------------------------------------------
>
> Key: LOG4J2-9
> URL: https://issues.apache.org/jira/browse/LOG4J2-9
> Project: Log4j 2
> Issue Type: Wish
> Components: Configurators
> Reporter: Curt Arnold
>
> log4j 2.0 should avoid implementing its own configuration framework in preference to being compatible with commonly used configuration frameworks and services. Compatibility with existing log4j 1.2 configuration files might be accomplished by XSLT transforms that convert the legacy format into the equivalent with the selected configuration framework. log4j 2.0 should be readily configurable with JMX and a JMX centric design for configuration may be desirable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-9) log4j 2.0 should leverage existing
(preferably ASF) configuration frameworks
Posted by "Paul Smith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607389#action_12607389 ]
Paul Smith commented on LOG4J2-9:
---------------------------------
Just to clear up what I actually meant, I wasn't actually advocating the _use_ of Spring within log4j, but given how useful and popular Spring is, we should at least factor into the design something that is IoC friendly.
for example, perhaps so 'spring-extras' companion that obey the Spring Lifecycle interface to startup/shutdown.
The more difficult objective though for a logging framework is to then _support_ the container in it's startup routine by allowing useful logging. Bit of a chicken/egg problem there unless the log4j configuration can be done as early as possible.
Anyway, I was just voicing that we should probably have a Spring-like container in mind during the configuration design. May even be worth reaching out into the, say, Spring community for further discussion (or bringing them into this one)
> log4j 2.0 should leverage existing (preferably ASF) configuration frameworks
> ----------------------------------------------------------------------------
>
> Key: LOG4J2-9
> URL: https://issues.apache.org/jira/browse/LOG4J2-9
> Project: Log4j 2
> Issue Type: Wish
> Components: Configurators
> Reporter: Curt Arnold
>
> log4j 2.0 should avoid implementing its own configuration framework in preference to being compatible with commonly used configuration frameworks and services. Compatibility with existing log4j 1.2 configuration files might be accomplished by XSLT transforms that convert the legacy format into the equivalent with the selected configuration framework. log4j 2.0 should be readily configurable with JMX and a JMX centric design for configuration may be desirable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org