[
https://issues.apache.org/jira/browse/BVAL-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417979#comment-15417979
]
Łukasz Dywicki commented on BVAL-145:
-------------------------------------
This could work - keeping defaults in Java and load eventual overrides from
TCCL but I'm not sure if it's a right direction, because we will mix things -
defaults in Java plus overrides in property file. I understand need for having
configuration to map JSR annotations to BVal validator instances but I ask
myself how often JSR constraints are defined without validators? Even for XML
configuration there is element to provide constraint validator (or additional
validators to constraints defined in JSR).
I did walk over code and I think I've found way to make it better (less hacky)
- create extended ApacheValidatorFactory which will contain osgi specific logic
to surround classloader handling. An alternative could be introducing
classloader property (to
org.apache.bval.jsr.ApacheValidatorConfiguration.Properties), however this is
extending spec into direction it will rather never go. Also it will be
problematic from XML configuration point of view.
What did work for wicket was simple SPI interface called ClassResolver for
class/resource loading (to not stick with classloaders directly) which could be
overriden during bootstrap.
However all of these are pushing back some manual steps to OSGi. This is kinda
sad because I managed to get "spec" working out of the box with my custom JSR
integration (see
https://github.com/Code-House/karaf-validation/tree/master/resolver/src/main/java/org/code_house/validation/resolver)
with both bval and hibernate validator but bval doesn't work due to error in
ConstraintDefaults resource lookup.
My pseudo code now looks like this;
{code:lang=java}
ValidationProviderResolver service = ... // OsgiValidationProviderResolver
simply collects registered ValidationProvider service s
Configuration<?> configuration = Validation.byDefaultProvider()
.providerResolver(service)
.configure();
// create validator factory and validators as normal
Validator validator = configuration.buildValidatorFactory().getValidator();
{code}
These are just ideas I have which could still work with current state of
ConstraintDefaults. Anyway, maybe it is better to move this discussion to dev
and continue there.
> BVal bundle fails to load resources under OSGi
> ----------------------------------------------
>
> Key: BVAL-145
> URL: https://issues.apache.org/jira/browse/BVAL-145
> Project: BVal
> Issue Type: Bug
> Components: jsr303
> Affects Versions: 1.1.1
> Environment: Karaf 4.0.5
> Reporter: Łukasz Dywicki
>
> Current logic of resource lookups in bval rely on context class loader and
> when it is not present it fallbacks to classloader which loaded bval. This
> works perfectly fine for most of cases, but fails under OSGi because TCCL in
> many cases is set to boot loader which contains no information about running
> modules. For this reason bval fails to load jsr303 mappings and always
> returns empty validation result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
