BVal under OSGi

[Łukasz Dywicki <lu...@code-house.org>]

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

Re: BVal under OSGi

[Romain Manni-Bucau <rm...@gmail.com>]

Le 16 août 2016 00:43, "Łukasz Dywicki" <lu...@code-house.org> a écrit :
>
> 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.

Never I think and no issue to start with this limitation IMHO.

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

Quick question: Default* are overridable with OSGi*Impl versions. Should be
fine for most cases, no?

If parsers/builders dont use tccl it sounds weird in term of deployment and
some will lead to ClassNotFoundException anyway by class graph browsing I
fear. Are they all really "buggy" in OSGi?

Maybe we should try by some OSGi tests with pax-exam and solve the issues
from there. Wdyt?

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