[2/8] git commit: Add validation message to @RequiresNonNull.

[Gary Gregory]

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

<div>-------- Original message --------</div><div>From: ***@apache.org </div><div>Date:09/14/2014 23:34 (GMT-05:00) </div><div>To: ***@logging.apache.org </div><div>Subject: [2/8] git commit: Add validation message to @RequiresNonNull. </div><div>
</div>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 <***@apache.org>
Authored: Sun Sep 14 20:26:48 2014 -0500
Committer: Matt Sicker <***@apache.org>
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]

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.

Post by Gary Gregory
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 --------
Date:09/14/2014 23:34 (GMT-05:00)
Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
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
Authored: Sun Sep 14 20:26:48 2014 -0500
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)
+
+ /**
+ * 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;
/**
@@ -25,12 +27,22 @@ import
org.apache.logging.log4j.core.config.plugins.validation.constraints.Requi
*/
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;
}
}

[Gary Gregory]

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

Post by Matt Sicker
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.

Post by Gary Gregory
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 --------
Date:09/14/2014 23:34 (GMT-05:00)
Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
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
Authored: Sun Sep 14 20:26:48 2014 -0500
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)
+
+ /**
+ * 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;
/**
@@ -25,12 +27,22 @@ import
org.apache.logging.log4j.core.config.plugins.validation.constraints.Requi
*/
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]

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?

Post by Gary Gregory
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

Post by Matt Sicker
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.

Post by Gary Gregory
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 --------
Date:09/14/2014 23:34 (GMT-05:00)
Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/20e739a5
http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/20e739a5
http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/20e739a5
Branch: refs/heads/master
Commit: 20e739a5308023e4f5b03a49ea12f473193dcbea
Parents: 84e7fed
Authored: Sun Sep 14 20:26:48 2014 -0500
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)
+
+ /**
+ * 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;
/**
@@ -25,12 +27,22 @@ import
org.apache.logging.log4j.core.config.plugins.validation.constraints.Requi
*/
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;
}
}

--

--
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

[Gary Gregory]

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

Post by Matt Sicker
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?

Post by Gary Gregory
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

Post by Matt Sicker
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.

Post by Gary Gregory
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 --------
Date:09/14/2014 23:34 (GMT-05:00)
Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/20e739a5
http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/20e739a5
http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/20e739a5
Branch: refs/heads/master
Commit: 20e739a5308023e4f5b03a49ea12f473193dcbea
Parents: 84e7fed
Authored: Sun Sep 14 20:26:48 2014 -0500
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)
+
+ /**
+ * 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;
/**
@@ -25,12 +27,22 @@ import
org.apache.logging.log4j.core.config.plugins.validation.constraints.Requi
*/
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;
}
}

--

--
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

--

[Ralph Goers]

You aren’t talking about bringing another jar as a required dependency are you? Required dependencies for core should be 0.

Ralph

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
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?
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
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.
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 --------
Date:09/14/2014 23:34 (GMT-05:00)
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
Authored: Sun Sep 14 20:26:48 2014 -0500
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)
+
+ /**
+ * 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;
/**
@@ -25,12 +27,22 @@ import org.apache.logging.log4j.core.config.plugins.validation.constraints.Requi
*/
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;
}
}
--
--
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
--
--
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

[Gary Gregory]

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

You aren’t talking about bringing another jar as a required dependency are
you? Required dependencies for core should be 0.
Ralph
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

Post by Matt Sicker
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?

Post by Gary Gregory
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

Post by Matt Sicker
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.

Post by Gary Gregory
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 --------
Date:09/14/2014 23:34 (GMT-05:00)
Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/20e739a5
http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/20e739a5
http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/20e739a5
Branch: refs/heads/master
Commit: 20e739a5308023e4f5b03a49ea12f473193dcbea
Parents: 84e7fed
Authored: Sun Sep 14 20:26:48 2014 -0500
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)
+
+ /**
+ * 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;
/**
@@ -25,12 +27,22 @@ import
org.apache.logging.log4j.core.config.plugins.validation.constraints.Requi
*/
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;
}
}

--

--
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

--

--
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

[Ralph Goers]

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

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
You aren’t talking about bringing another jar as a required dependency are you? Required dependencies for core should be 0.
Ralph

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
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?
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
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.
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 --------
Date:09/14/2014 23:34 (GMT-05:00)
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
Authored: Sun Sep 14 20:26:48 2014 -0500
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)
+
+ /**
+ * 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;
/**
@@ -25,12 +27,22 @@ import org.apache.logging.log4j.core.config.plugins.validation.constraints.Requi
*/
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;
}
}
--
--
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
--
--
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

--
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]

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.

Post by Ralph Goers
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
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

You aren’t talking about bringing another jar as a required dependency
are you? Required dependencies for core should be 0.
Ralph
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

Post by Matt Sicker
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?

Post by Gary Gregory
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

Post by Matt Sicker
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.

Post by Gary Gregory
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 --------
Date:09/14/2014 23:34 (GMT-05:00)
Subject: [2/8] git commit: Add validation message to
@RequiresNonNull.
Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/20e739a5
http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/20e739a5
http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/20e739a5
Branch: refs/heads/master
Commit: 20e739a5308023e4f5b03a49ea12f473193dcbea
Parents: 84e7fed
Authored: Sun Sep 14 20:26:48 2014 -0500
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)
+
+ /**
+ * 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;
/**
@@ -25,12 +27,22 @@ import
org.apache.logging.log4j.core.config.plugins.validation.constraints.Requi
*/
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;
}
}

--

--
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

--

--
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

--
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

[Ralph Goers]

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

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.
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

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
You aren’t talking about bringing another jar as a required dependency are you? Required dependencies for core should be 0.
Ralph

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
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?
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
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.
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 --------
Date:09/14/2014 23:34 (GMT-05:00)
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
Authored: Sun Sep 14 20:26:48 2014 -0500
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)
+
+ /**
+ * 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;
/**
@@ -25,12 +27,22 @@ import org.apache.logging.log4j.core.config.plugins.validation.constraints.Requi
*/
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;
}
}
--
--
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
--
--
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

--
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

--

[Remko Popma]

This page is the closest:
http://logging.apache.org/log4j/2.x/log4j-core/index.html

Ralph, are you looking for something different? What would a chart look like in this case, and where on the site would be the best place for it?

Sent from my iPhone

I donft think you really can. I suspect AsyncLoggers would be a problem. The JSON stuff probably could.
I donft think it is really a problem as long as it is well documented.
Ralph

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.

Post by Ralph Goers
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ft 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 gcore of coreh 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

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

You arenft talking about bringing another jar as a required dependency are you? Required dependencies for core should be 0.
Ralph

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

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?

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

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.

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 --------
Date:09/14/2014 23:34 (GMT-05:00)
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
Authored: Sun Sep 14 20:26:48 2014 -0500
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)
+
+ /**
+ * 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;
/**
@@ -25,12 +27,22 @@ import org.apache.logging.log4j.core.config.plugins.validation.constraints.Requi
*/
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;
}
}

--

--
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

--

--
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

--
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

--

[Ralph Goers]

That has the correct information on it. I was thinking it would be on a menu item on the top left rather than under the core component. In fact, it might be nice to have a table of dependencies for each component on one page.

Ralph

Post by Remko Popma
http://logging.apache.org/log4j/2.x/log4j-core/index.html
Ralph, are you looking for something different? What would a chart look like in this case, and where on the site would be the best place for it?
Sent from my iPhone

Post by Ralph Goers
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

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.
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

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
You aren’t talking about bringing another jar as a required dependency are you? Required dependencies for core should be 0.
Ralph

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
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?
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
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.
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 --------
Date:09/14/2014 23:34 (GMT-05:00)
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
Authored: Sun Sep 14 20:26:48 2014 -0500
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)
+
+ /**
+ * 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;
/**
@@ -25,12 +27,22 @@ import org.apache.logging.log4j.core.config.plugins.validation.constraints.Requi
*/
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;
}
}
--
--
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
--
--
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

--
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

--