Develop Reference

How we can get the invalid value that we have pass in the request from Set<ConstraintViolation<Object>>

Currently, I am validating my request using javax validation.
Set<ConstraintViolation<Request>> constraintViolations = validator
.validate(Request);
So from constraint violations I want two things,
constraint violation.getPropertyPath() which will return which fields is violating
I want the invalid value that I was passing in the request for the fields from the constraintViolations variable
So how we can get the invalid value?
For 2. I tried using constraintViolation.getInvalidValue() this but it is giving like com.practice.domain.PaymentInstrumentRequest#258d8cb5
I want specific value that I have passed in that field.

Using Before keyword with method parameter in spring data

I have entity Composition containing fields Date publicationDate and Boolean archival. I'm trying to get list of Compositions with publicationDate before date passed as argument and having archival flag set to false. After going through some of 'query creation from method names' tutorials and docs i came up with methods
List<Composition> findByPublicationDateBeforeDateAndArchivalFalse(Date date);
or
List<Composition> findByPublicationDateBeforeDateAndArchivalFalse(#Param("date")Date date);
but none of this works. Both gives UnsatisfiedDependencyException with
nested exception is org.springframework.data.mapping.PropertyReferenceException: No property beforeDate found for type Date! Traversed path: Composition.publicationDate.
Intellij also underlines BeforeDate as it cannot resolve property beforeDate. What is the proper way of using those keywords with parameters so the parameters could be distinguished from fields by Spring?

Refactor your method to following:
List<Composition> findByPublicationDateBeforeAndArchivalFalse(Date date);
Before keyword will compare publicationDate with date you pass as an argument, so there is no need to say BeforeDate. Just like an example in Spring Data documentation:
Before -> findByStartDateBefore produces following SQL part … where x.startDate < ?1

Jboss LDAP login module using non-case sensitive [duplicate]

What is the syntax for performing a case-insensitive match on a uid attribute? If attribute definition matters then how would that be changed?
In particular I am using ApacheDS for my LDAP store.

(uid=miXedCaseUSer) will match a uid of mixedcaseuser.
According to the OID Description for 0.9.2342.19200300.100.1.1 - Userid userId is defined to have EQUALITY MATCHING RULE caseIgnoreMatch
This means it is one of the attribute definitions that employ case-insensitive matching by default.

I think they are case insensitive by default, unless its a password attribute.

Spring "typemismatch" and required fields

In the context of Spring Webflow 2.0.x......
I handle form binding "typemismatches", i.e. as a result of trying to map a String onto a Integer field, by using the following in my messages.properties
typeMismatch={0} contains invalid data.
This works fine.
The problem is that if the field that the typeMismatch error occurred on was "required" then I also receive an error for the missing required field, which is logical I guess because the value that was submitted was never bound. ("Required" being defined in a Commons Validation XML file)
So, I dont want to see the "XXX is required field" error message when the field is only missing due to the typeMismatch. How do I resolve this? I thought about overriding initBinder() on the FormAction but quickly got nowhere.....

Like Yves mentioned, among the three approaches, i have used a custom validator method and its very easy. You can use a custom validator which checks if the form field already has a xml error message of required. If the field does not have an error, then you can check for your string validation. That way it will display only one.
The other method that you could use is try a multiple xml validation, one being required and the other one being a mask which checks for a particular regular expression. In your case if your field is an integer field, then you can go and perform a mask with regex checking for only numbers. The order of mask, required or required, mask in the xml decides which message gets a higher preference.
For example:
<field property="somefield" depends="required,mask" page="2">
<arg key="somelabel"/>
<var>
<var-name>mask</var-name>
<var-value>${somepattern}</var-value>
</var>
</field>

You have many options, in order of preference:
Set selectively the message typeMismatch.target.yourFieldName or typeMismatch.int in resources files
Implement your own Validator so that you can send a dedicated message when Integer parsing will fail before the binding step
Create a BindingErrorProcessor to handle different kind of parsing issues

Unique constraint with JPA and Bean Validation

I'd like to have a #Unique constraint with Bean Validation, but that is not provided by the standard. If I would use JPA's #UniqueConstraint I wouldn't have a unique validation and error reporting mechanism.
Is there a way to define #Unique as a Bean Validation constraint and combine it with JPA, such that JPA creates a column with an unique constraint and checks wheter a value is unique or not?

Unless you acquire a lock on a whole table, it is basically not possible to check for unicity using a SQL query (any concurrent transaction could modify data after a manual check but before the commit of the ongoing transaction). In other words, it isn't possible to implement a valid unique verification at the Java level and thus to provide a validation implementation. The only reliable way to check for unicity is while committing the transaction.
The BV spec summarizes it like this:
Appendix D. Java Persistence 2.0 integration
Question: should we add #Unique that
would map to #Column(unique=true)?
#Unique cannot be tested at the Java
level reliably but could generate a
database unique constraint generation.
#Unique is not part of the BV spec
today.
So while I agree that it would be nice to have unique (and non null) constraint violations wrapped in a Bean Validation exception, this is currently not the case.
References
Bean Validation specification (JSR 303)
Appendix D. Java Persistence 2.0 integration
Question about validation and persistence constraints

More information on how to implement a #Unique and the problematic around it can be found here - http://community.jboss.org/wiki/AccessingtheHibernateSessionwithinaConstraintValidator

Well you CAN do it, but it's not trivial. The problem is: the validator requires database access to perform some queries to check, if the value you want to insert is already there or not. And this can't be really done from the validator, as it doesn't have access to the sessionFactory/session. Of course you could instantiate it (session/sessionFactory) inside the validator, but it's not a good coding practice.

You can make a validator read the JPA annotations and apply it. Here is somewhat of an example using spring validators that can be used as an idea to expand on.
JPA JSR303 Spring Form Validation
You can also inject (#Inject or Spring's #Autowired) your session bean in a custom validator and the container should know how to wire it up. I only know this as a Spring example:
import javax.validation.ConstraintValidator;
public class MyConstraintValidator implements ConstraintValidator {
#Autowired //#Inject
private Foo aDependency;
...
}

You should try (insert or update), catch the exception and do some action. For example in a JSF backing bean :
try {
dao.create(record);//or dao.modify(record)
//add message success
} catch(EJBException e) {
//look for origin of error (duplicate label, duplicate code, ...)
var err = dao.isUnique(record);
if(err == null) throw e;//other error
String clientId = null;
String message = null;
switch(err) {
case CODE:
clientId = "client_id_of_input_code";
message = "duplicate code";
break;
case LABEL:
clientId = "client_id_of_input_label";
message = "duplicate label";
break;
default:
throw new AssertionError();//or something else
}
facesContext.addMessage(clientId, new FacesMessage(FacesMessage.SEVERITY_ERROR, message));
facesContext.validationFailed();
}
Another option is to check before the insertion/modification. This can be time consuming and doesn't prevent the error to happen in the end.