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 <rem...@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 <garydgreg...@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 <rem...@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 <garydgreg...@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 <scott.de...@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 <ralph.go...@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 <garydgreg...@gmail.com> wrote: >>>>>> >>>>>>> Why not more log4j-async into the core? >>>>>>> >>>>>>> Gary >>>>>>> >>>>>>> -- >>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@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 >>>>> >>>>> >
