I don’t think you really can. I suspect AsyncLoggers would be a problem. The JSON stuff probably could.
I don’t think it is really a problem as long as it is well documented. Ralph On Sep 15, 2014, at 1:47 PM, Matt Sicker <[email protected]> wrote: > Could we split up core into a core core and the other core plugins that > require third party dependencies? I don't know how confusing that would be > for the end user. I mean, Log4j 1 required just the single jar, but it did > provide rather minimal features. > > On 15 September 2014 13:33, Ralph Goers <[email protected]> wrote: > Yes, Async Loggers are optional because the pom lists the disruptor as an > optional dependency. In core, all dependencies are optional. We really need > a chart for core that lists what the optional features are and what the > dependencies that are needed for them are. > > Hopefully Log4j will be used in lots of use cases. Log4j 1 was used (and > probably still is) in embedded applications. I don’t want to preclude Log4j 2 > being used in similar circumstances. > > When writing the code for the XML configuration I considered the choices but > specifically did not want to bring in a third party jar for that. > > The “core of core” that has no dependencies is pretty much what a large > number of will use and many would not be happy if we required other things. > > Ralph > > > > > > On Sep 15, 2014, at 10:43 AM, Gary Gregory <[email protected]> wrote: > >> I guess that is what I am suggesting, core depends on a bunch of jars as it >> is but I do see what you mean, there is the core of core... It's confusing >> as heck to have all of our "optional" features that depend on 3rd party jars >> undocumented from the code's POV, since we do not have an optional source >> folder or package. Maybe it would be obvious if the "core" was really just >> the "core"... So are async loggers "optional" because of the LMAX Disruptor? >> Right now, we have a rule that the core of core cannot depend on anything >> (like the API does). But then I async loggers... >> >> From my POV, any app I write that needs to do logging instead of System.out >> is "serious" enough that will do work requiring a pile of other jars. >> >> One of the thing I do not like about v2 is all of our custom code for >> configuration of XML and JSON. It would have been so much simpler with >> Jackson, annotate the class once, then get XML and JSON IO, (not sure about >> YAML) but hey, that's just me ;-) >> >> Enough rambling. >> >> Gary >> >> On Mon, Sep 15, 2014 at 1:22 PM, Ralph Goers <[email protected]> >> wrote: >> You aren’t talking about bringing another jar as a required dependency are >> you? Required dependencies for core should be 0. >> >> Ralph >> >> On Sep 15, 2014, at 9:31 AM, Gary Gregory <[email protected]> wrote: >> >>> This is all in the core, so I do not see the need to repackage anything. We >>> certainly do not do it for anything else. Why would you want to do it here? >>> >>> Gary >>> >>> On Mon, Sep 15, 2014 at 12:28 PM, Matt Sicker <[email protected]> wrote: >>> Well, it's certainly worth trying. However, if we went that route, would we >>> have a hard dependency on the javax.validation API? Or would we >>> package-rename things and embed it? >>> >>> On 15 September 2014 11:24, Gary Gregory <[email protected]> wrote: >>> It all depends on your POV ;-) , one of which is, what we are doing now is >>> overkill compared to what we started with... >>> >>> So, why not Bean Validation, more precisely? It seems we owe it to the >>> project to try it (in a branch perhaps) and _know_ that it is possible or >>> not a right fit. >>> >>> Conceptually, it's hard to see how it would not be a right fit. >>> >>> Gary >>> >>> On Mon, Sep 15, 2014 at 11:10 AM, Matt Sicker <[email protected]> wrote: >>> I was looking at bean validation, and not only is it overkill for our >>> situation, but I don't know how well it would work either. >>> >>> On 15 September 2014 05:50, Gary Gregory <[email protected]> wrote: >>> I don't about this... I feel we need to discuss this before we reinvent the >>> bean validation JSR wheel and Hibernate Validator or some other >>> implementation. Why are we forcing users to learn another framework instead >>> of using a standard? This is almost -1 territory... I feel we need to clean >>> up the builder pattern mess before we make another decision on plugins... >>> >>> Gary >>> >>> >>> -------- Original message -------- >>> From: [email protected] >>> Date:09/14/2014 23:34 (GMT-05:00) >>> To: [email protected] >>> Subject: [2/8] git commit: Add validation message to @RequiresNonNull. >>> >>> Add validation message to @RequiresNonNull. >>> >>> >>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo >>> Commit: >>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/20e739a5 >>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/20e739a5 >>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/20e739a5 >>> >>> Branch: refs/heads/master >>> Commit: 20e739a5308023e4f5b03a49ea12f473193dcbea >>> Parents: 84e7fed >>> Author: Matt Sicker <[email protected]> >>> Authored: Sun Sep 14 20:26:48 2014 -0500 >>> Committer: Matt Sicker <[email protected]> >>> Committed: Sun Sep 14 20:26:48 2014 -0500 >>> >>> ---------------------------------------------------------------------- >>> .../validation/constraints/RequiresNonNull.java | 5 +++++ >>> .../validators/RequiresNonNullValidator.java | 14 +++++++++++++- >>> 2 files changed, 18 insertions(+), 1 deletion(-) >>> ---------------------------------------------------------------------- >>> >>> >>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/20e739a5/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/validation/constraints/RequiresNonNull.java >>> ---------------------------------------------------------------------- >>> diff --git >>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/validation/constraints/RequiresNonNull.java >>> >>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/validation/constraints/RequiresNonNull.java >>> index b3ef11d..7eb83e2 100644 >>> --- >>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/validation/constraints/RequiresNonNull.java >>> +++ >>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/validation/constraints/RequiresNonNull.java >>> @@ -36,4 +36,9 @@ import >>> org.apache.logging.log4j.core.config.plugins.validation.validators.Requir >>> @Target({ElementType.FIELD, ElementType.PARAMETER}) >>> @Constraint(RequiresNonNullValidator.class) >>> public @interface RequiresNonNull { >>> + >>> + /** >>> + * The message to be logged if this constraint is violated. This >>> should normally be overridden. >>> + */ >>> + String message() default "The parameter is null"; >>> } >>> >>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/20e739a5/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/validation/validators/RequiresNonNullValidator.java >>> ---------------------------------------------------------------------- >>> diff --git >>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/validation/validators/RequiresNonNullValidator.java >>> >>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/validation/validators/RequiresNonNullValidator.java >>> index 49c5806..9a39d4d 100644 >>> --- >>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/validation/validators/RequiresNonNullValidator.java >>> +++ >>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/validation/validators/RequiresNonNullValidator.java >>> @@ -16,8 +16,10 @@ >>> */ >>> package org.apache.logging.log4j.core.config.plugins.validation.validators; >>> >>> +import org.apache.logging.log4j.Logger; >>> import >>> org.apache.logging.log4j.core.config.plugins.validation.ConstraintValidator; >>> import >>> org.apache.logging.log4j.core.config.plugins.validation.constraints.RequiresNonNull; >>> +import org.apache.logging.log4j.status.StatusLogger; >>> >>> /** >>> * Validator implementation for {@link RequiresNonNull}. >>> @@ -25,12 +27,22 @@ import >>> org.apache.logging.log4j.core.config.plugins.validation.constraints.Requi >>> * @since 2.1 >>> */ >>> public class RequiresNonNullValidator implements >>> ConstraintValidator<RequiresNonNull, Object> { >>> + >>> + private static final Logger LOGGER = StatusLogger.getLogger(); >>> + >>> + private RequiresNonNull annotation; >>> + >>> @Override >>> public void initialize(final RequiresNonNull annotation) { >>> + this.annotation = annotation; >>> } >>> >>> @Override >>> public boolean isValid(final Object value) { >>> - return value != null; >>> + if (value != null) { >>> + return true; >>> + } >>> + LOGGER.error(annotation.message()); >>> + return false; >>> } >>> } >>> >>> >>> >>> >>> -- >>> Matt Sicker <[email protected]> >>> >>> >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> 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 >>> >>> >>> >>> -- >>> Matt Sicker <[email protected]> >>> >>> >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> 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 >> >> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> 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 > > > > > -- > Matt Sicker <[email protected]>
