This issue has already received a lot of discussion at https://hibernate.onjira.com/browse/BVTCK-11 but it looks like no one followed up enough to force them to exclude the test. I think we should. I'll try to find the proposed solution and comment....
thanks david jencks On Aug 22, 2011, at 1:51 PM, David Blevins wrote: > > On Aug 22, 2011, at 9:25 AM, Kevan Miller wrote: > >> >> On Aug 22, 2011, at 12:45 AM, dblev...@apache.org wrote: >> >>> Author: dblevins >>> Date: Mon Aug 22 04:45:07 2011 >>> New Revision: 1160106 >>> >>> URL: http://svn.apache.org/viewvc?rev=1160106&view=rev >>> Log: >>> GERONIMO-6117: OpenWebBeansPlugin load optimization >>> >>> Modified: >>> >>> geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java >> >> >> Cool. With this change and setting >> BundleResourceHelper.searchWiredBundles=false (e.g. >> GERONIMO_OPTS=-Dorg.apache.xbean.osgi.bundle.util.BundleResourceHelper.searchWiredBundles=false >> ./geronimo run), my server starts without a problem and startup is pretty >> good. Tthe timed portion (so doesn't count the initial karaf loading) is >> 9-10 seconds: >> >> ... >> Module 63/63 org.apache.geronimo.configs/wink-deployer/3.0-SNAPSHOT/car >> started in .015s >> Startup completed in 9.105s seconds >> Listening on Ports: >> ... >> >> Which is great, given that we're not doing any lazy startup. However, I'm >> seeing some bean-validation tck failures with searchWiredBundles=false (jcdi >> tck looks fine and I didn't try any other tck tests). Anybody able to take a >> look at this? > > 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 > 2. Don't use BundleResourceHelper.searchWiredBundles=false and live with the > performance we have > 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. > > -David >
