See my last comment, the HV constraints actually might work also on another provider, given HV is available on the class path. So this shouldn't require any configuration specific to the server (although I personally don't see any problem with just setting HV as the default provider).
I can't comment on how easy or difficult it is to add HV to WebSphere and what class loader issues that may cause. I'd be very appy about any feedback though, maybe you even could contribute a how-to to our [wiki|https://community.jboss.org/en/hibernate/validator] or an entry to our [FAQ|http://hibernate.org/validator/faq/]? I suggest you experiment a bit with the options we discussed and see whether any of them is feasible (the unpack plug-in should work as measure of last resort in any case).
Note that this is not to say that I'm against having a separate module for the constraints per-se (I even suggested it myself before, for slightly different reasons), I still think though your case can be realized in a satisfying manner without this split (which at least would require some refactorings to remove the discussed dependencies from the validators to other HV internal classes).
{quote}
it would all be simpler and more portable splitting the implementation of the bean validation api and any custom constraints. In my opinion conceptually they don't belong in the same module.
{quote}
I'm not so sure about this. The constraints are only one part of the public API provided by Hibernate Validator, there are other things such as the API for programmatic constraint declaration, the fail fast mode, support for boolean constraint composition and so on. These other things depend on HV as engine though, so they wouldn't work using another provider. I kind of like that all these features are part of one API which is provided by one module.
|
