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 wrote: -
To: Commons Users List
From: Niall Pemberton
Date: 05/24/2011 08:00PM
Subject: Re: [beanutils] Issue with ContextClassLoaderLocal class.
On Tue, May 24, 2011 at 1:55 PM, Rammohan Natarajan
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-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
