[ 
https://issues.apache.org/jira/browse/BEANUTILS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738264#action_12738264
 ] 

Franklin Phan edited comment on BEANUTILS-353 at 8/3/09 10:13 AM:
------------------------------------------------------------------

I am trying your suggestion from your first comment. I am seeing an 
inconsistency with the workings of this "per-classloader" feature. I have two 
instances of Tomcat 5.5.27 running on separate machines (one Linux and one 
WinXP). Each Tomcat is set up similarly and runs the same copy of a webapp. Per 
your suggestion, I wrote each webapp a Filter whose init method registers an 
implementation of SqlTimestampConverter that returns a default of null:
{{BeanUtilsBean.getInstance().getConvertUtils().register(new 
SqlTimestampConverter(null), java.sql.Timestamp.class);}}

Using NetBeans Debugger, I can see that during server startup, the init method 
is called for both webapps and a new instance of BeanUtilsBeans (containing the 
corrected SqlTimestampConverter) is stored in the {{valueByClassLoader}} Map in 
ContextClassLoaderLocal. Each converter is mapped by the ContextClassLoader 
gotten from:
{{ClassLoader contextClassLoader = 
Thread.currentThread().getContextClassLoader();}}

So far so good.

Later, when the webapps are called again via a different action, one webapp 
retrieves the same BeanUtilsBeans from the {{valueByClassLoader}} Map while the 
other webapp gets a different ContextClassLoader and creates a second, new 
instance of BeanUtilsBeans with all the default Converters via the 
{{ConvertUtilsBean.deregister}} method and stores it in the 
{{valueByClassLoader}} Map. This new instance of BeanUtilsBeans contains, of 
course, the incorrect SqlTimestampConverter; and {{valueByClassLoader}} Map now 
contains two BeanUtilsBeans. What's causing this discrepant behavior in the 
latter Tomcat/webapp?

      was (Author: fphan):
    I am not understanding how this "per-classloader" feature works. I have two 
instances of Tomcat 5.5.27 running on separate machines (one Linux and one 
WinXP). Each Tomcat are set up similarly and runs the same copy of a webapp. 
Each webapp has a Filter whose init method registers a differently configured 
implementation of SqlTimestampConverter:
{{BeanUtilsBean.getInstance().getConvertUtils().register(new 
SqlTimestampConverter(null), java.sql.Timestamp.class);}}

Using NetBeans Debugger, I can see that during server startup, the init method 
is called for both webapps and a new instance of BeanUtilsBeans (containing the 
corrected SqlTimestampConverter) is stored in the {{valueByClassLoader}} Map in 
ContextClassLoaderLocal--each converter mapped by the ContextClassLoader.

Later, when the webapps are called again via a different action, one webapp 
retrieves the same BeanUtilsBeans from the {{valueByClassLoader}} Map while the 
other webapp gets a different ContextClassLoader and creates a second, new 
instance of BeanUtilsBeans with all the default Converters via the 
{{ConvertUtilsBean.deregister}} method and stores it in the 
{{valueByClassLoader}} Map. This new instance of BeanUtilsBeans contains, of 
course, the incorrect SqlTimestampConverter; and {{valueByClassLoader}} Map now 
contains two BeanUtilsBeans. What's causing this discrepant behavior in the 
latter Tomcat/webapp?
  
> Unable to call isUseDefault() to check whether a default value will be 
> returned
> -------------------------------------------------------------------------------
>
>                 Key: BEANUTILS-353
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-353
>             Project: Commons BeanUtils
>          Issue Type: Bug
>          Components: ConvertUtils & Converters
>    Affects Versions: 1.8.0
>         Environment: WinXP Pro, JDK 1.6.0_14, Tomcat 5.5.27
>            Reporter: Franklin Phan
>
> One can never call isUseDefault() to check on a Converter given the way you 
> have ConverterFacade designed and in ConvertUtilsBean:
> {{
>     private void register(Class clazz, Converter converter) {
>         register(new ConverterFacade(converter), clazz);
>     }
> }}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to