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

Reply via email to