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 e
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 "cri
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 mi
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
modi
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
Merge now and clean up docs later?
On Fri, Apr 12, 2013 at 11:10 AM, Remko Popma 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 nee
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 t
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 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 f
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 wrote:
> The dependency only kicks in when you run the class. We have the same issue
> in Commoms VFS and we do not spl
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
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 wrote:
I'd like to avoid what we had with log4j 1.x - the receivers/companions
mess. Whether or so
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
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
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
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-
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 wrote:
> Why not more log4j-async into the core?
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence
16 matches
Mail list logo
