You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scm@geronimo.apache.org by db...@apache.org on 2011/08/22 06:45:07 UTC
svn commit: r1160106 -
/geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java
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
Modified: geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java?rev=1160106&r1=1160105&r2=1160106&view=diff
==============================================================================
--- geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java (original)
+++ geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java Mon Aug 22 04:45:07 2011
@@ -33,6 +33,7 @@ import org.apache.openejb.cdi.CdiResourc
import org.apache.openejb.cdi.CdiScanner;
import org.apache.openejb.cdi.OpenEJBLifecycle;
import org.apache.openejb.cdi.OpenEJBTransactionService;
+import org.apache.openejb.cdi.OptimizedLoaderService;
import org.apache.openejb.cdi.StartupObject;
import org.apache.openejb.loader.SystemInstance;
import org.apache.webbeans.config.OpenWebBeansConfiguration;
@@ -43,6 +44,7 @@ import org.apache.webbeans.spi.Container
import org.apache.webbeans.spi.ContextsService;
import org.apache.webbeans.spi.ConversationService;
import org.apache.webbeans.spi.JNDIService;
+import org.apache.webbeans.spi.LoaderService;
import org.apache.webbeans.spi.ResourceInjectionService;
import org.apache.webbeans.spi.ScannerService;
import org.apache.webbeans.spi.SecurityService;
@@ -52,7 +54,7 @@ import org.apache.webbeans.spi.adaptor.E
import org.apache.webbeans.util.WebBeansUtil;
/**
- * @version $Rev: 698441 $ $Date: 2008-09-24 00:10:08 -0700 (Wed, 24 Sep 2008) $
+ * @version $Rev$ $Date$
*/
public class OpenWebBeansWebInitializer {
@@ -75,7 +77,8 @@ public class OpenWebBeansWebInitializer
services.put(TransactionService.class, new OpenEJBTransactionService());
services.put(JNDIService.class, new NoopJndiService());
services.put(ELAdaptor.class, new EL22Adaptor());
-
+ services.put(LoaderService.class, new OptimizedLoaderService());
+
if (startup != null && startup instanceof StartupObject){
ClassLoader cl=((StartupObject)startup).getAppContext().getClassLoader();
Re: svn commit: r1160106 - /geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java
Posted by Kevan Miller <ke...@gmail.com>.
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
Re: svn commit: r1160106 - /geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java
Posted by David Jencks <da...@yahoo.com>.
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
>
Re: svn commit: r1160106 - /geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java
Posted by David Blevins <da...@gmail.com>.
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
Re: svn commit: r1160106 - /geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/cdi/OpenWebBeansWebInitializer.java
Posted by Kevan Miller <ke...@gmail.com>.
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?
--kevan