[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-user
Subject:    Re: [beanutils] Issue with ContextClassLoaderLocal class.
From:       Rammohan Natarajan <rammohan.natarajan () tcs ! com>
Date:       2011-05-25 7:56:33
Message-ID: OFC51EC625.07B0769D-ON6525789B.002B946C-6525789B.002B9470 () tcs ! com
[Download RAW message or body]

Thanks for the responses.
 
I had been thinking along those lines that the registration should be done
within the parsing module. But I am a bit curious as to know the root cause
of this problem. Is my application design flawed in registering all custom
converters during application startup or is it a result of some limitation of
beanutils?
And also how it manages to work properly in WebSphere?
 
Thanks.

-----Niall Pemberton <niall.pemberton@gmail.com> wrote: -----


To: Commons Users List <user@commons.apache.org>
From: Niall Pemberton <niall.pemberton@gmail.com>
Date: 05/24/2011 08:00PM
Subject: Re: [beanutils] Issue with ContextClassLoaderLocal class.

On Tue, May 24, 2011 at 1:55 PM, Rammohan Natarajan
<rammohan.natarajan@tcs.com> wrote:
> Hi,
> 
> We are working on migrating a J2EE application from WAS6.1 to JBoss EAP 5.0. For \
> unmarshalling of some custom XML we make use of commons-beanutils-1.8.3 within this \
> application; and in the process, we have defined a custom type converter for one of \
> the XML tags. The registration of this converter happens in one EJB module within \
> our EAR, whereas theactual XML parsing occurs in another EJB module within the same \
> EAR. The org.apache.commons.beanutils.ContextClassLoaderLocal class ties 'global' \
> variables to a classloader instance in a map to ensure data isolation even if the \
> variable is referenced by multiple components running within a container. Here is \
> the relevant code snippet from its get() method: 
> ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
> if (contextClassLoader != null)
> {
> Object value = valueByClassLoader.get(contextClassLoader);
> if ((value == null) && !valueByClassLoader.containsKey(contextClassLoader))
> {
> value = initialValue();
> valueByClassLoader.put(contextClassLoader, value);
> }
> return value;
> }
> 
> After all that background information, here is the problem:
> During the converter registration process, a BeanUtilsBean instance is maintained \
> in the ContextClassLoaderLocal map against the classloader of the registration EJB \
> module. During the parsing process, this map is queried to retreive the same \
> BeanUtilsBean instance, using the classloader of the parsing EJB module as the key. \
> In Websphere Application server, the classloader instance for the registration \
> module and the parser module are both same; the correct BeanUtilsBean instance is \
> retreived and processing proceeds as expected. However, in JBoss EAP 5.0, the two \
> classloader instances are different so that the parser module fails to retreive the \
> value from the map. Is this a problem with beanutils' design or an issue with \
> JBoss?

I think you need to register the converter in the module its used in -
i.e. your parsing EJB module

Niall

> Please let me know if I am missing something or if additional details are required.
> Thanks in advance.
> N.Rammohan.
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you




---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]