You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Joseph Snyder <j....@oracle.com> on 2012/03/02 21:31:47 UTC
Re: [Discuss] Classloader issue for deltaspike configuration (differences
between Glassfish 3.Jboss AS7 and weblogic 12c)
Gerhard is correct...wls 12C released with 1.1.3SP1. To upgrade to
1.1.4 or 1.1.5 I would have to create a patch. The next release of WLS
should contain 1.1.5.
On 2/20/2012 10:30 AM, Jason Porter wrote:
> 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<rd...@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
Re: [Discuss] Classloader issue for deltaspike configuration (differences
between Glassfish 3.Jboss AS7 and weblogic 12c)
Posted by Joseph Snyder <j....@oracle.com>.
ok I will get to this as soon as I can and then run it regularly.
JJ
On 3/9/2012 8:54 AM, Gerhard Petracek wrote:
> hi joseph,
>
> it would be great if you could run our integration tests with the
> latest snapshot of wls12 on a regular basis e.g. via a ci-build.
> (as mentioned [1] in the wiki, we already have a profile for wls12
> which uses arquillian-wls-remote-12.1.)
>
> regards,
> gerhard
>
> [1]
> https://cwiki.apache.org/confluence/display/DeltaSpike/Temporary+Documentation#TemporaryDocumentation-WebLogic12c
>
>
>
> 2012/3/8 Joseph Snyder <j.j.snyder@oracle.com
> <ma...@oracle.com>>
>
> Ales,
> I believe it is targeted for the end of the year but nothing
> official has been stated.
>
> JJ
>
>
> On 3/2/2012 3:56 PM, Ales Justin wrote:
>
> Joseph, when are you doing next release?
> As we just fixed a bunch of stuff for upcoming 1.1.6.
>
> Sent from my iPad
>
> On Mar 2, 2012, at 21:31, Joseph Snyder<j.j.snyder@oracle.com
> <ma...@oracle.com>> wrote:
>
> Gerhard is correct...wls 12C released with 1.1.3SP1. To
> upgrade to 1.1.4 or 1.1.5 I would have to create a patch.
> The next release of WLS should contain 1.1.5.
>
>
>
> On 2/20/2012 10:30 AM, Jason Porter wrote:
>
> 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
> <ma...@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
>
>
Re: [Discuss] Classloader issue for deltaspike configuration
(differences between Glassfish 3.Jboss AS7 and weblogic 12c)
Posted by Gerhard Petracek <ge...@gmail.com>.
hi joseph,
it would be great if you could run our integration tests with the latest
snapshot of wls12 on a regular basis e.g. via a ci-build.
(as mentioned [1] in the wiki, we already have a profile for wls12 which
uses arquillian-wls-remote-12.1.)
regards,
gerhard
[1]
https://cwiki.apache.org/confluence/display/DeltaSpike/Temporary+Documentation#TemporaryDocumentation-WebLogic12c
2012/3/8 Joseph Snyder <j....@oracle.com>
> Ales,
> I believe it is targeted for the end of the year but nothing official has
> been stated.
>
> JJ
>
>
> On 3/2/2012 3:56 PM, Ales Justin wrote:
>
>> Joseph, when are you doing next release?
>> As we just fixed a bunch of stuff for upcoming 1.1.6.
>>
>> Sent from my iPad
>>
>> On Mar 2, 2012, at 21:31, Joseph Snyder<j....@oracle.com> wrote:
>>
>> Gerhard is correct...wls 12C released with 1.1.3SP1. To upgrade to
>>> 1.1.4 or 1.1.5 I would have to create a patch. The next release of WLS
>>> should contain 1.1.5.
>>>
>>>
>>>
>>> On 2/20/2012 10:30 AM, Jason Porter wrote:
>>>
>>>> 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<http://jsfcorner.blogspot.com/2012/01/codi-on-oracle-weblogic-server-12c.html>
>>>>>
>>>>> --
>>>>> Rudy De Busscher
>>>>> http://www.c4j.be
>>>>>
>>>>
Re: [Discuss] Classloader issue for deltaspike configuration (differences
between Glassfish 3.Jboss AS7 and weblogic 12c)
Posted by Joseph Snyder <j....@oracle.com>.
Ales,
I believe it is targeted for the end of the year but nothing official
has been stated.
JJ
On 3/2/2012 3:56 PM, Ales Justin wrote:
> Joseph, when are you doing next release?
> As we just fixed a bunch of stuff for upcoming 1.1.6.
>
> Sent from my iPad
>
> On Mar 2, 2012, at 21:31, Joseph Snyder<j....@oracle.com> wrote:
>
>> Gerhard is correct...wls 12C released with 1.1.3SP1. To upgrade to 1.1.4 or 1.1.5 I would have to create a patch. The next release of WLS should contain 1.1.5.
>>
>>
>>
>> On 2/20/2012 10:30 AM, Jason Porter wrote:
>>> 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<rd...@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
Re: [Discuss] Classloader issue for deltaspike configuration (differences between Glassfish 3.Jboss AS7 and weblogic 12c)
Posted by Ales Justin <al...@gmail.com>.
Joseph, when are you doing next release?
As we just fixed a bunch of stuff for upcoming 1.1.6.
Sent from my iPad
On Mar 2, 2012, at 21:31, Joseph Snyder <j....@oracle.com> wrote:
> Gerhard is correct...wls 12C released with 1.1.3SP1. To upgrade to 1.1.4 or 1.1.5 I would have to create a patch. The next release of WLS should contain 1.1.5.
>
>
>
> On 2/20/2012 10:30 AM, Jason Porter wrote:
>> 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<rd...@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