geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: svn commit: r1160106 - /geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java
Date Wed, 24 Aug 2011 21:23:46 GMT
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, dblevins@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
> 


Mime
View raw message