geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: svn commit: r1160106 - /geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java
Date Mon, 22 Aug 2011 22:42:15 GMT

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
Mime
View raw message