deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: [Discuss] Classloader issue for deltaspike configuration (differences between Glassfish 3.Jboss AS7 and weblogic 12c)
Date Mon, 20 Feb 2012 15:30:23 GMT
Slightly non related, but which version of weld is WebLogic using? Are they using 1.1.3? 

JJ: if that's the case, what would it take to upgrade to 1.1.5? We'd discussed only supporting
Weld 1.1.4 and higher. 

Sent from my iPhone

On Feb 20, 2012, at 7:56, Rudy De Busscher <rdebusscher@gmail.com> wrote:

> Hi all,
> 
> There are problems with the configuration of DeltaSpike on weblogic 12c.
> 
> When a web application is deployed that contains deltaspike as jars, the
> configuration is not performed properly.
> - *ServiceLoader.load(ConfigSourceProvider.class); *
>   => doesn't find the service configuration file in the jar
> - *ClassLoader cl = ClassUtils.getClassLoader(this);  // The context class
> loader
>  Enumeration<URL> propertyFileUrls = cl.getResources(PROPERTY_FILE_NAME);*
>   => doesn't find the apache-deltaspike.properties file
> 
> A possible solution is to unjar the deltaspike jar files into the classes
> directory as described here for CODI (1)
> 
> Debugging the system today revealed that during the execution of the CDI
> extensions (that is where we touch the configuration for the first time)
> the context classloader
> (*Thread.currentThread().getContextClassLoader();*) isn't the web-app
> class loader but his parent (which exists for the
> application as a whole)
> 
> But ClassUtils.class.getClassLoader(); (or any other class from deltaspike)
> points at that time to the web-app classloader which can see for instance
> the apache-deltaspike.properties file.
> 
> On GlassFish 3 and JBoss AS 7, the Context class loader
> and ClassUtils.class.getClassLoader() points to the same when the
> Extensions are processed.
> 
> *So my proposition is the following:*
> 
> a) Change in org.apache.deltaspike.core.api.config.ConfigResolver
> *ServiceLoader.load(ConfigSourceProvider.class,
> ConfigResolver.class.getClassLoader());*  instead of *
> ServiceLoader.load(ConfigSourceProvider.class);*
> 
> Then serviceLoader will use the web-app classloader on all 3 app servers.
> 
> b) Change how resources are found; here we have several options
> 1) Change org.apache.deltaspike.core.util.ClassUtils#getClassLoader that it
> returns o.getClass().getClassLoader(); when parameter o is not null.
> 
> 2) Create a specific method that returns resources, something like
> *public List<URL> findResources(Object o, String fileName)*
> *{*
> *        ClassLoader cl = o.getClass().getClassLoader();*
> *        try*
> *        {*
> *            Enumeration<URL> propertyFileUrls = cl.getResources(fileName);*
> *   .....*
> *}*
> 3) Create a specific method that returns resources that first tries the
> context class loader, and if that doesn't find anything, tries the
> classLoader of the object passed as parameter.
> 
> 
> If we can agree, I create a JIRA ticket for it.
> 
> Regards
> Rudy
> 
> 
> (1) =
> http://jsfcorner.blogspot.com/2012/01/codi-on-oracle-weblogic-server-12c.html
> 
> -- 
> Rudy De Busscher
> http://www.c4j.be

Mime
View raw message