On Aug 22, 2011, at 4:51 PM, David Blevins wrote:
> Looked into it a bit.
>
> Most the BVal tests seem to be failing due to classLoader.getResource() calls
> in Apache BVal looking for schemas. Probably there's some way we could work
> around that as we already have logic for this in BValModuleBuilderExtension.
>
> There is one failure however that will not pass with
> BundleResourceHelper.searchWiredBundles=false ... at least not the way it's
> implemented. ValidationProviderResolverTest is implementing its own provider
> search and verifying it works. Better said they're executing:
>
> classloader.getResources("META-INF/services/" +
> ValidationProvider.class.getName());
>
> And verifying that there is at least one provider found. Our version of that
> API has been extended to support more OSGi friendly search mechanisms -- the
> code Rick wrote.
>
> The options as I see them:
>
> 1. challenge the test
Can't say I recall the spec well enough to evaluate that.
> 2. Don't use BundleResourceHelper.searchWiredBundles=false and live with the
> performance we have
Yep. Kind of nice to be in that situation. :) I just ran measurements to be
sure... like searchWiredBundles=false is knocking 4-5 seconds of my startup on
a Linux VM w/ 2 GB RAM, and 2 cores (18-13). So, would be kind of nice if we
could find a way to avoid searchWiredBundles. But we can live with it, also...
Also, don't know what issues might be raised by a full TCK run...
> 3. Make the BundleResourceHelper.searchWiredBundles functionality more
> configurable so validation API can be exempt from limited search
> 4. Physically add a
> META-INF/services/javax.validation.spi.ValidationProvider file to apps
> 5. Somehow intercept calls to getResources(foo) and do like we did with the
> ServiceLoader searching of OWB and supply known implementations up front.
> Not sure if that is even possible in this situation.
>
> Open to ideas.
Me too... I guess 4 is a possibility. Don't think I'd want to add the
complexity for 3) or 5)
--kevan
