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 Gary Gregory <ga...@gmail.com> on 2013/04/12 17:23:18 UTC
Merge log4j-async into log4j-core
Why not more log4j-async into the core?
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Merge log4j-async into log4j-core
Posted by Remko Popma <re...@yahoo.com>.
I was wrong. Dalvik VM has the sun.misc.Unsafe class, but people were experiencing issues with something called ProGuard (part of Android build system) which was not recognizing it as a jdk class and obfuscating it.
Just fyi, putting
-keep sun.misc.Unsafe { *; }
in your ProGuard.cfg solves the problem. Phew.
It's beginning to look like I was paranoid for no reason...
Sent from my iPhone
On 2013/04/13, at 2:08, Remko Popma <re...@yahoo.com> wrote:
> Hm. Looks like the Dalvik VM used in Android may be missing part of the sun.misc.Unsafe class.
>
> Otherwise Google doesn't mention any complaints.
>
> Apparently in OSGi apps the sun.* packages are not exported by default requiring some additional configuration.
>
>
> Sent from my iPhone
>
> On 2013/04/13, at 1:51, Remko Popma <re...@yahoo.com> wrote:
>
>> The Disruptor needs Java 6. Internally it uses the sun.misc.Unsafe class. There may be JVMs that do not have this class, although I doubt that is actually the case: many of the java.* classes in the Oracle implementation rely on it. I know that the Azul JVM has this class.
>>
>> I was worried that there may be scenarios where an application would not have the security privileges to use this class. I haven't checked if such scenarios exist...
>>
>> Sent from my iPhone
>>
>> On 2013/04/13, at 1:23, Ralph Goers <rg...@apache.org> wrote:
>>
>>> Because it has a dependency on the Disruptor, which Remko has said may not work on all JDKs
>>>
>>> Sent from my iPad
>>>
>>> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>>> Why not more log4j-async into the core?
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> JUnit in Action, Second Edition
>>>> Spring Batch in Action
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
Re: Merge log4j-async into log4j-core
Posted by Remko Popma <re...@yahoo.com>.
Hm. Looks like the Dalvik VM used in Android may be missing part of the sun.misc.Unsafe class.
Otherwise Google doesn't mention any complaints.
Apparently in OSGi apps the sun.* packages are not exported by default requiring some additional configuration.
Sent from my iPhone
On 2013/04/13, at 1:51, Remko Popma <re...@yahoo.com> wrote:
> The Disruptor needs Java 6. Internally it uses the sun.misc.Unsafe class. There may be JVMs that do not have this class, although I doubt that is actually the case: many of the java.* classes in the Oracle implementation rely on it. I know that the Azul JVM has this class.
>
> I was worried that there may be scenarios where an application would not have the security privileges to use this class. I haven't checked if such scenarios exist...
>
> Sent from my iPhone
>
> On 2013/04/13, at 1:23, Ralph Goers <rg...@apache.org> wrote:
>
>> Because it has a dependency on the Disruptor, which Remko has said may not work on all JDKs
>>
>> Sent from my iPad
>>
>> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>>> Why not more log4j-async into the core?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
Re: Merge log4j-async into log4j-core
Posted by Remko Popma <re...@yahoo.com>.
The Disruptor needs Java 6. Internally it uses the sun.misc.Unsafe class. There may be JVMs that do not have this class, although I doubt that is actually the case: many of the java.* classes in the Oracle implementation rely on it. I know that the Azul JVM has this class.
I was worried that there may be scenarios where an application would not have the security privileges to use this class. I haven't checked if such scenarios exist...
Sent from my iPhone
On 2013/04/13, at 1:23, Ralph Goers <rg...@apache.org> wrote:
> Because it has a dependency on the Disruptor, which Remko has said may not work on all JDKs
>
> Sent from my iPad
>
> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>
>> Why not more log4j-async into the core?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
Re: Merge log4j-async into log4j-core
Posted by Ralph Goers <ra...@dslextreme.com>.
If a merge is done I would question why FastFileAppender and FastRollingFileAppender wouldn't replace their counterparts. If some option is desired to make them function like they currently do then that could be done.
As I said, if they are moved to core then I would also expect them to be modified to detect that the dependency is missing and log that.
While moving the async stuff into core may not be very hard, I don't think it is trivial.
Ralph
On Apr 12, 2013, at 11:33 AM, Scott Deboy wrote:
> Merge now and clean up docs later?
>
>
> On Fri, Apr 12, 2013 at 11:10 AM, Remko Popma <re...@yahoo.com> wrote:
> Most of the work would be rewriting the documentation. For example, the bit on FastFileAppender and FastRollingFileAppender. (Better names for these, anyone?)
>
> I guess the section on those would need to move into the manual page on Appenders. Not sure what to do with the performance results for those appenders... Maybe merge with the existing performance page and move that page into the manual?
> I was thinking about refactoring the existing performance page anyway, just thought I had more time to do it.
>
> I'm in two minds. I see your point about confusing some users, but on the other hand I would like to get it out there, get some feedback, and take the time to do the restructuring and rewriting the docs right.
>
> Sent from my iPhone
>
> On 2013/04/13, at 2:42, Gary Gregory <ga...@gmail.com> wrote:
>
>> Since this is new, it would be less confusing to do it now instead of adding and removing a jar from one beta to the next. IMO that is ;)
>>
>> Gary
>>
>> On Apr 12, 2013, at 13:32, Remko Popma <re...@yahoo.com> wrote:
>>
>>> If we do merge async into core, can we do it after beta 5? I'd like to get it out there and get people's feedback...
>>>
>>> Sent from my iPhone
>>>
>>> On 2013/04/13, at 2:11, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>>> The dependency only kicks in when you run the class. We have the same issue in Commoms VFS and we do not split out in a bunch of jars, nice and simple.
>>>>
>>>> Gary
>>>>
>>>> On Apr 12, 2013, at 12:38, Scott Deboy <sc...@gmail.com> wrote:
>>>>
>>>>> I'd like to avoid what we had with log4j 1.x - the receivers/companions mess. Whether or something belongs in core or not is a fuzzy judgment call sometimes. If possible, I would like to see as much as possible included in a single 'release' (that includes 'receivers/companions' if they ever are rewritten for log4j2).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 12, 2013 at 9:30 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>> It probably should be done anyway, but the various components would also need to check for the presence of the disruptor and log a warning if it isn't there (I believe we do this for Jansi and Jackson) as the disruptor would have to be an optional dependency. In the async package it can be non-optional so this is less important for anyone using Maven.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Apr 12, 2013, at 9:23 AM, Ralph Goers wrote:
>>>>>
>>>>>> Because it has a dependency on the Disruptor, which Remko has said may not work on all JDKs
>>>>>>
>>>>>> Sent from my iPad
>>>>>>
>>>>>> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>
>>>>>>> Why not more log4j-async into the core?
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> JUnit in Action, Second Edition
>>>>>>> Spring Batch in Action
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>>
>
Re: Merge log4j-async into log4j-core
Posted by Scott Deboy <sc...@gmail.com>.
Merge now and clean up docs later?
On Fri, Apr 12, 2013 at 11:10 AM, Remko Popma <re...@yahoo.com> wrote:
> Most of the work would be rewriting the documentation. For example, the
> bit on FastFileAppender and FastRollingFileAppender. (Better names for
> these, anyone?)
>
> I guess the section on those would need to move into the manual page on
> Appenders. Not sure what to do with the performance results for those
> appenders... Maybe merge with the existing performance page and move that
> page into the manual?
> I was thinking about refactoring the existing performance page anyway,
> just thought I had more time to do it.
>
> I'm in two minds. I see your point about confusing some users, but on the
> other hand I would like to get it out there, get some feedback, and take
> the time to do the restructuring and rewriting the docs right.
>
> Sent from my iPhone
>
> On 2013/04/13, at 2:42, Gary Gregory <ga...@gmail.com> wrote:
>
> Since this is new, it would be less confusing to do it now instead of
> adding and removing a jar from one beta to the next. IMO that is ;)
>
> Gary
>
> On Apr 12, 2013, at 13:32, Remko Popma <re...@yahoo.com> wrote:
>
> If we do merge async into core, can we do it after beta 5? I'd like to get
> it out there and get people's feedback...
>
> Sent from my iPhone
>
> On 2013/04/13, at 2:11, Gary Gregory <ga...@gmail.com> wrote:
>
> The dependency only kicks in when you run the class. We have the same
> issue in Commoms VFS and we do not split out in a bunch of jars, nice and
> simple.
>
> Gary
>
> On Apr 12, 2013, at 12:38, Scott Deboy <sc...@gmail.com> wrote:
>
> I'd like to avoid what we had with log4j 1.x - the receivers/companions
> mess. Whether or something belongs in core or not is a fuzzy judgment call
> sometimes. If possible, I would like to see as much as possible included
> in a single 'release' (that includes 'receivers/companions' if they ever
> are rewritten for log4j2).
>
>
>
>
>
>
> On Fri, Apr 12, 2013 at 9:30 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> It probably should be done anyway, but the various components would also
>> need to check for the presence of the disruptor and log a warning if it
>> isn't there (I believe we do this for Jansi and Jackson) as the disruptor
>> would have to be an optional dependency. In the async package it can be
>> non-optional so this is less important for anyone using Maven.
>>
>> Ralph
>>
>> On Apr 12, 2013, at 9:23 AM, Ralph Goers wrote:
>>
>> Because it has a dependency on the Disruptor, which Remko has said may
>> not work on all JDKs
>>
>> Sent from my iPad
>>
>> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> Why not more log4j-async into the core?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
Re: Merge log4j-async into log4j-core
Posted by Remko Popma <re...@yahoo.com>.
Most of the work would be rewriting the documentation. For example, the bit on FastFileAppender and FastRollingFileAppender. (Better names for these, anyone?)
I guess the section on those would need to move into the manual page on Appenders. Not sure what to do with the performance results for those appenders... Maybe merge with the existing performance page and move that page into the manual?
I was thinking about refactoring the existing performance page anyway, just thought I had more time to do it.
I'm in two minds. I see your point about confusing some users, but on the other hand I would like to get it out there, get some feedback, and take the time to do the restructuring and rewriting the docs right.
Sent from my iPhone
On 2013/04/13, at 2:42, Gary Gregory <ga...@gmail.com> wrote:
> Since this is new, it would be less confusing to do it now instead of adding and removing a jar from one beta to the next. IMO that is ;)
>
> Gary
>
> On Apr 12, 2013, at 13:32, Remko Popma <re...@yahoo.com> wrote:
>
>> If we do merge async into core, can we do it after beta 5? I'd like to get it out there and get people's feedback...
>>
>> Sent from my iPhone
>>
>> On 2013/04/13, at 2:11, Gary Gregory <ga...@gmail.com> wrote:
>>
>>> The dependency only kicks in when you run the class. We have the same issue in Commoms VFS and we do not split out in a bunch of jars, nice and simple.
>>>
>>> Gary
>>>
>>> On Apr 12, 2013, at 12:38, Scott Deboy <sc...@gmail.com> wrote:
>>>
>>>> I'd like to avoid what we had with log4j 1.x - the receivers/companions mess. Whether or something belongs in core or not is a fuzzy judgment call sometimes. If possible, I would like to see as much as possible included in a single 'release' (that includes 'receivers/companions' if they ever are rewritten for log4j2).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Apr 12, 2013 at 9:30 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>> It probably should be done anyway, but the various components would also need to check for the presence of the disruptor and log a warning if it isn't there (I believe we do this for Jansi and Jackson) as the disruptor would have to be an optional dependency. In the async package it can be non-optional so this is less important for anyone using Maven.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Apr 12, 2013, at 9:23 AM, Ralph Goers wrote:
>>>>>
>>>>>> Because it has a dependency on the Disruptor, which Remko has said may not work on all JDKs
>>>>>>
>>>>>> Sent from my iPad
>>>>>>
>>>>>> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>
>>>>>>> Why not more log4j-async into the core?
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> JUnit in Action, Second Edition
>>>>>>> Spring Batch in Action
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
Re: Merge log4j-async into log4j-core
Posted by Gary Gregory <ga...@gmail.com>.
Since this is new, it would be less confusing to do it now instead of
adding and removing a jar from one beta to the next. IMO that is ;)
Gary
On Apr 12, 2013, at 13:32, Remko Popma <re...@yahoo.com> wrote:
If we do merge async into core, can we do it after beta 5? I'd like to get
it out there and get people's feedback...
Sent from my iPhone
On 2013/04/13, at 2:11, Gary Gregory <ga...@gmail.com> wrote:
The dependency only kicks in when you run the class. We have the same issue
in Commoms VFS and we do not split out in a bunch of jars, nice and simple.
Gary
On Apr 12, 2013, at 12:38, Scott Deboy <sc...@gmail.com> wrote:
I'd like to avoid what we had with log4j 1.x - the receivers/companions
mess. Whether or something belongs in core or not is a fuzzy judgment call
sometimes. If possible, I would like to see as much as possible included
in a single 'release' (that includes 'receivers/companions' if they ever
are rewritten for log4j2).
On Fri, Apr 12, 2013 at 9:30 AM, Ralph Goers <ra...@dslextreme.com>wrote:
> It probably should be done anyway, but the various components would also
> need to check for the presence of the disruptor and log a warning if it
> isn't there (I believe we do this for Jansi and Jackson) as the disruptor
> would have to be an optional dependency. In the async package it can be
> non-optional so this is less important for anyone using Maven.
>
> Ralph
>
> On Apr 12, 2013, at 9:23 AM, Ralph Goers wrote:
>
> Because it has a dependency on the Disruptor, which Remko has said may
> not work on all JDKs
>
> Sent from my iPad
>
> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Why not more log4j-async into the core?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
Re: Merge log4j-async into log4j-core
Posted by Remko Popma <re...@yahoo.com>.
If we do merge async into core, can we do it after beta 5? I'd like to get it out there and get people's feedback...
Sent from my iPhone
On 2013/04/13, at 2:11, Gary Gregory <ga...@gmail.com> wrote:
> The dependency only kicks in when you run the class. We have the same issue in Commoms VFS and we do not split out in a bunch of jars, nice and simple.
>
> Gary
>
> On Apr 12, 2013, at 12:38, Scott Deboy <sc...@gmail.com> wrote:
>
>> I'd like to avoid what we had with log4j 1.x - the receivers/companions mess. Whether or something belongs in core or not is a fuzzy judgment call sometimes. If possible, I would like to see as much as possible included in a single 'release' (that includes 'receivers/companions' if they ever are rewritten for log4j2).
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 12, 2013 at 9:30 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>>> It probably should be done anyway, but the various components would also need to check for the presence of the disruptor and log a warning if it isn't there (I believe we do this for Jansi and Jackson) as the disruptor would have to be an optional dependency. In the async package it can be non-optional so this is less important for anyone using Maven.
>>>
>>> Ralph
>>>
>>> On Apr 12, 2013, at 9:23 AM, Ralph Goers wrote:
>>>
>>>> Because it has a dependency on the Disruptor, which Remko has said may not work on all JDKs
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>
>>>>> Why not more log4j-async into the core?
>>>>>
>>>>> Gary
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
Re: Merge log4j-async into log4j-core
Posted by Gary Gregory <ga...@gmail.com>.
The dependency only kicks in when you run the class. We have the same issue
in Commoms VFS and we do not split out in a bunch of jars, nice and simple.
Gary
On Apr 12, 2013, at 12:38, Scott Deboy <sc...@gmail.com> wrote:
I'd like to avoid what we had with log4j 1.x - the receivers/companions
mess. Whether or something belongs in core or not is a fuzzy judgment call
sometimes. If possible, I would like to see as much as possible included
in a single 'release' (that includes 'receivers/companions' if they ever
are rewritten for log4j2).
On Fri, Apr 12, 2013 at 9:30 AM, Ralph Goers <ra...@dslextreme.com>wrote:
> It probably should be done anyway, but the various components would also
> need to check for the presence of the disruptor and log a warning if it
> isn't there (I believe we do this for Jansi and Jackson) as the disruptor
> would have to be an optional dependency. In the async package it can be
> non-optional so this is less important for anyone using Maven.
>
> Ralph
>
> On Apr 12, 2013, at 9:23 AM, Ralph Goers wrote:
>
> Because it has a dependency on the Disruptor, which Remko has said may not
> work on all JDKs
>
> Sent from my iPad
>
> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Why not more log4j-async into the core?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
Re: Merge log4j-async into log4j-core
Posted by Remko Popma <re...@yahoo.com>.
The Fast*Appenders don't depend on the disruptor. Sorry for the confusion.
I'll see what I can do this weekend regarding submitting a patch for the merge. Just fyi, some of the patches I submitted (LOG4J2-199, LOG4J2-203 and LOG4J2-207) modify files in the log4j-async module. I'm not sure how easy it is to apply those after the log4j-async module is gone.
Sent from my iPhone
On 2013/04/13, at 4:16, Ralph Goers <ra...@dslextreme.com> wrote:
> Core has optional dependencies on Jackson (for JSON configuration), Jansi (Windows color support), javax.mail (SMTP appender) and geronimo-jms (JMS appender). These should be called out on the core page. All the others are test dependencies.
>
> What is different? Maybe nothing. IMO, all the "critical" things a user expects should be available without any dependencies. For example, I would hate to have either the FileAppender or RollingFileAppender dependent on anything (I'm not sure the Fast versions are).
>
> I'd be a lot happier if Maven had a way to say "this component is optional but if you are using this feature I will include it". IOW, Log4j provides an AsyncLogger feature and project y specifies that it requires that feature. I've wanted a feature like that for years but have never had the time to implement it, nor can it really be implemented without changing the schema for the pom.
>
> Ralph
>
>
> On Apr 12, 2013, at 11:53 AM, Scott Deboy wrote:
>
>>
>> This link says there are no dependencies :) Something to fix there?
>>
>> http://logging.apache.org/log4j/2.x/dependencies.html
>>
>> Of course, the convergence link shows dependencies:
>>
>> http://logging.apache.org/log4j/2.x/dependency-convergence.html
>>
>> I can't tell which ones are required at runtime for a minimal configuration - anything?
>>
>> If the other dependencies listed are optional at runtime, but available in core, why would this one be different?
>>
>> Scott
>>
>>
>>
>> On Fri, Apr 12, 2013 at 11:45 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>>> I'm not sure what you mean, but the guideline I use as to whether something belongs in core is what dependencies it requires. The functionality it provides is secondary to me. My preference is for the Log4j API & core to have as few dependencies as possible.
>>>
>>> Ralph
>>>
>>>
>>>
>>> On Apr 12, 2013, at 9:38 AM, Scott Deboy wrote:
>>>
>>>> I'd like to avoid what we had with log4j 1.x - the receivers/companions mess. Whether or something belongs in core or not is a fuzzy judgment call sometimes. If possible, I would like to see as much as possible included in a single 'release' (that includes 'receivers/companions' if they ever are rewritten for log4j2).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Apr 12, 2013 at 9:30 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>> It probably should be done anyway, but the various components would also need to check for the presence of the disruptor and log a warning if it isn't there (I believe we do this for Jansi and Jackson) as the disruptor would have to be an optional dependency. In the async package it can be non-optional so this is less important for anyone using Maven.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Apr 12, 2013, at 9:23 AM, Ralph Goers wrote:
>>>>>
>>>>>> Because it has a dependency on the Disruptor, which Remko has said may not work on all JDKs
>>>>>>
>>>>>> Sent from my iPad
>>>>>>
>>>>>> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>
>>>>>>> Why not more log4j-async into the core?
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> JUnit in Action, Second Edition
>>>>>>> Spring Batch in Action
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>
Re: Merge log4j-async into log4j-core
Posted by Ralph Goers <ra...@dslextreme.com>.
Core has optional dependencies on Jackson (for JSON configuration), Jansi (Windows color support), javax.mail (SMTP appender) and geronimo-jms (JMS appender). These should be called out on the core page. All the others are test dependencies.
What is different? Maybe nothing. IMO, all the "critical" things a user expects should be available without any dependencies. For example, I would hate to have either the FileAppender or RollingFileAppender dependent on anything (I'm not sure the Fast versions are).
I'd be a lot happier if Maven had a way to say "this component is optional but if you are using this feature I will include it". IOW, Log4j provides an AsyncLogger feature and project y specifies that it requires that feature. I've wanted a feature like that for years but have never had the time to implement it, nor can it really be implemented without changing the schema for the pom.
Ralph
On Apr 12, 2013, at 11:53 AM, Scott Deboy wrote:
>
> This link says there are no dependencies :) Something to fix there?
>
> http://logging.apache.org/log4j/2.x/dependencies.html
>
> Of course, the convergence link shows dependencies:
>
> http://logging.apache.org/log4j/2.x/dependency-convergence.html
>
> I can't tell which ones are required at runtime for a minimal configuration - anything?
>
> If the other dependencies listed are optional at runtime, but available in core, why would this one be different?
>
> Scott
>
>
>
> On Fri, Apr 12, 2013 at 11:45 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> I'm not sure what you mean, but the guideline I use as to whether something belongs in core is what dependencies it requires. The functionality it provides is secondary to me. My preference is for the Log4j API & core to have as few dependencies as possible.
>
> Ralph
>
>
>
> On Apr 12, 2013, at 9:38 AM, Scott Deboy wrote:
>
>> I'd like to avoid what we had with log4j 1.x - the receivers/companions mess. Whether or something belongs in core or not is a fuzzy judgment call sometimes. If possible, I would like to see as much as possible included in a single 'release' (that includes 'receivers/companions' if they ever are rewritten for log4j2).
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 12, 2013 at 9:30 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>> It probably should be done anyway, but the various components would also need to check for the presence of the disruptor and log a warning if it isn't there (I believe we do this for Jansi and Jackson) as the disruptor would have to be an optional dependency. In the async package it can be non-optional so this is less important for anyone using Maven.
>>
>> Ralph
>>
>> On Apr 12, 2013, at 9:23 AM, Ralph Goers wrote:
>>
>>> Because it has a dependency on the Disruptor, which Remko has said may not work on all JDKs
>>>
>>> Sent from my iPad
>>>
>>> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>>> Why not more log4j-async into the core?
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> JUnit in Action, Second Edition
>>>> Spring Batch in Action
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>
>
Re: Merge log4j-async into log4j-core
Posted by Scott Deboy <sc...@gmail.com>.
This link says there are no dependencies :) Something to fix there?
http://logging.apache.org/log4j/2.x/dependencies.html
Of course, the convergence link shows dependencies:
http://logging.apache.org/log4j/2.x/dependency-convergence.html
I can't tell which ones are required at runtime for a minimal configuration
- anything?
If the other dependencies listed are optional at runtime, but available in
core, why would this one be different?
Scott
On Fri, Apr 12, 2013 at 11:45 AM, Ralph Goers <ra...@dslextreme.com>wrote:
> I'm not sure what you mean, but the guideline I use as to whether
> something belongs in core is what dependencies it requires. The
> functionality it provides is secondary to me. My preference is for the
> Log4j API & core to have as few dependencies as possible.
>
> Ralph
>
>
>
> On Apr 12, 2013, at 9:38 AM, Scott Deboy wrote:
>
> I'd like to avoid what we had with log4j 1.x - the receivers/companions
> mess. Whether or something belongs in core or not is a fuzzy judgment call
> sometimes. If possible, I would like to see as much as possible included
> in a single 'release' (that includes 'receivers/companions' if they ever
> are rewritten for log4j2).
>
>
>
>
>
>
> On Fri, Apr 12, 2013 at 9:30 AM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> It probably should be done anyway, but the various components would also
>> need to check for the presence of the disruptor and log a warning if it
>> isn't there (I believe we do this for Jansi and Jackson) as the disruptor
>> would have to be an optional dependency. In the async package it can be
>> non-optional so this is less important for anyone using Maven.
>>
>> Ralph
>>
>> On Apr 12, 2013, at 9:23 AM, Ralph Goers wrote:
>>
>> Because it has a dependency on the Disruptor, which Remko has said may
>> not work on all JDKs
>>
>> Sent from my iPad
>>
>> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> Why not more log4j-async into the core?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
Re: Merge log4j-async into log4j-core
Posted by Ralph Goers <ra...@dslextreme.com>.
I'm not sure what you mean, but the guideline I use as to whether something belongs in core is what dependencies it requires. The functionality it provides is secondary to me. My preference is for the Log4j API & core to have as few dependencies as possible.
Ralph
On Apr 12, 2013, at 9:38 AM, Scott Deboy wrote:
> I'd like to avoid what we had with log4j 1.x - the receivers/companions mess. Whether or something belongs in core or not is a fuzzy judgment call sometimes. If possible, I would like to see as much as possible included in a single 'release' (that includes 'receivers/companions' if they ever are rewritten for log4j2).
>
>
>
>
>
>
> On Fri, Apr 12, 2013 at 9:30 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> It probably should be done anyway, but the various components would also need to check for the presence of the disruptor and log a warning if it isn't there (I believe we do this for Jansi and Jackson) as the disruptor would have to be an optional dependency. In the async package it can be non-optional so this is less important for anyone using Maven.
>
> Ralph
>
> On Apr 12, 2013, at 9:23 AM, Ralph Goers wrote:
>
>> Because it has a dependency on the Disruptor, which Remko has said may not work on all JDKs
>>
>> Sent from my iPad
>>
>> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>>> Why not more log4j-async into the core?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>
>
Re: Merge log4j-async into log4j-core
Posted by Scott Deboy <sc...@gmail.com>.
I'd like to avoid what we had with log4j 1.x - the receivers/companions
mess. Whether or something belongs in core or not is a fuzzy judgment call
sometimes. If possible, I would like to see as much as possible included
in a single 'release' (that includes 'receivers/companions' if they ever
are rewritten for log4j2).
On Fri, Apr 12, 2013 at 9:30 AM, Ralph Goers <ra...@dslextreme.com>wrote:
> It probably should be done anyway, but the various components would also
> need to check for the presence of the disruptor and log a warning if it
> isn't there (I believe we do this for Jansi and Jackson) as the disruptor
> would have to be an optional dependency. In the async package it can be
> non-optional so this is less important for anyone using Maven.
>
> Ralph
>
> On Apr 12, 2013, at 9:23 AM, Ralph Goers wrote:
>
> Because it has a dependency on the Disruptor, which Remko has said may not
> work on all JDKs
>
> Sent from my iPad
>
> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Why not more log4j-async into the core?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
Re: Merge log4j-async into log4j-core
Posted by Ralph Goers <ra...@dslextreme.com>.
It probably should be done anyway, but the various components would also need to check for the presence of the disruptor and log a warning if it isn't there (I believe we do this for Jansi and Jackson) as the disruptor would have to be an optional dependency. In the async package it can be non-optional so this is less important for anyone using Maven.
Ralph
On Apr 12, 2013, at 9:23 AM, Ralph Goers wrote:
> Because it has a dependency on the Disruptor, which Remko has said may not work on all JDKs
>
> Sent from my iPad
>
> On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
>
>> Why not more log4j-async into the core?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
Re: Merge log4j-async into log4j-core
Posted by Ralph Goers <rg...@apache.org>.
Because it has a dependency on the Disruptor, which Remko has said may not work on all JDKs
Sent from my iPad
On Apr 12, 2013, at 8:23 AM, Gary Gregory <ga...@gmail.com> wrote:
> Why not more log4j-async into the core?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory