Hey all,
I come here after exchanging couple comments in BVal jira under BVAL-145. My 
main problem are resource lookups which are not working when Thread Context 
Class Loader is used (TCCL). Under OSGi class loading is pretty strict and 
falling back to TCCL is not best way to go. In my case any attempt to create 
validation factory goes just fine, but creates an validator which does nothing 
because there is no mapping between jsr annotations and bval constraints. In 
this particular case TCCL is set to boot loader (AppLoader) of entire program 
which doesn’t know anything about JARs later used in runtime. Same issue is 
reported under BVAL-140 which is open since 10 months.

Romain Manni-Bucau and I had couple ideas how to solve problem, but we didn’t 
find any clear path. My initial pull request 
(https://github.com/apache/bval/pull/2) offered work around, however it was 
messing around class loaders. I know BVal works pretty well under JEE as well 
as in traditional flat classpath applications and I would love to make it 
working under OSGi as well in the way it doesn’t hurt your project and makes 
sense.
One of Romain proposals was to transform ConstraintDefaults into java only and 
remove resource mapping. I don’t know how often these defaults are overriden, 
but this would remove issue completely, cause we would always load defaults 
from BVal classloader.
Other proposal was to pass classloader to validation factory in one of 
bootstrap parameters or use centralized class/resource resolving similar to 
Wicket IClassResolver 
(https://ci.apache.org/projects/wicket/apidocs/org/apache/wicket/application/IClassResolver.html
 
<https://ci.apache.org/projects/wicket/apidocs/org/apache/wicket/application/IClassResolver.html>)
 which could detach resource lookups from direct calls.
Because in every case some bigger change is requires I wanted to bring this 
discussion to dev@ so project team could decide which direction is valid.

For now in trunk there is 12 files which are calling or using class loaders 
directly or indirectly (ie. to get resource bundle):
Reflection.java
ApacheValidatorFactory.java
ConstraintDefaults.java
DefaultMessageInterpolator.java
DefaultValidationProviderResolver.java      
DefaultTraversableResolver.java     
AnnotationProxyBuilder.java
ValidationMappingParser.java
ValidationParser.java
ValidationParserTest.java
BValJndiFactory.java
XMLMetaBeanManager.java


Best regards,
Łukasz Dywicki
--
Apache Karaf Committer & PMC
Twitter: @ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org

Reply via email to