<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to bugs</title><link>https://sourceforge.net/p/easymbean/bugs/</link><description>Recent changes to bugs</description><atom:link href="https://sourceforge.net/p/easymbean/bugs/feed.rss" rel="self"/><language>en</language><lastBuildDate>Thu, 05 Feb 2009 18:34:36 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/easymbean/bugs/feed.rss" rel="self" type="application/rss+xml"/><item><title>ThreadSafe</title><link>https://sourceforge.net/p/easymbean/bugs/2/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;This package is not thread-safe at all. Having the statically initialized "factory" from the EasyMBean class means the class will get initialized 1 time in the JVM and that factory contains instance variables that are operated on from within the statically initialized class. So if I run this inside, say, a container like tomcat and 2 users hit different servlets at the same time that create 2 different managed resources the following occurs:&lt;/p&gt;
&lt;p&gt;1. User A hits Servlet A at the same time User B hits Servlet B - resulting in 2 seperate threads within the container.&lt;/p&gt;
&lt;p&gt;2. Thread A accesses ManagedResourceA at roughly the same time Thread B accesses ManagedResourceB, neither of which have been initialized in the JVM yet, so the classloader loads the resources and the constructors are called. &lt;/p&gt;
&lt;p&gt;3. Both ManagedResourceA and ManagedResourceB use the EasyMBean.factory object to register themselves inside the MBeanServer. &lt;/p&gt;
&lt;p&gt;4. The instance variables on MBeanBuilder are now in an unknown state containing information from multiple threads accessing the class at the same time.&lt;/p&gt;
&lt;p&gt;Recommendation:&lt;/p&gt;
&lt;p&gt;I don't see any solid reason why the descriptor variables need to be instance variables at all in the MBeanBuilder. There is no reason that they couldn't be scoped to the method, then no synchronization is necessary and since the data you are using shouldn't need to be accessed again outside of the initial creation of the mbean it begs the question why have instance variables at all on this class?&lt;/p&gt;
&lt;p&gt;If you are sold on the idea of the MBeanBuilder being statically initialized, make it a singleton object and synchronize on a shared lock when updating the instance variables in MBeanBuilder.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">devoid</dc:creator><pubDate>Thu, 05 Feb 2009 18:34:36 -0000</pubDate><guid>https://sourceforge.net4610183d32742827e9626e0ad99392395d232a47</guid></item><item><title>Null Pointer Exception</title><link>https://sourceforge.net/p/easymbean/bugs/1/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I'm getting a null pointer exception as follows:-&lt;/p&gt;
&lt;p&gt;java.lang.NullPointerException&lt;/p&gt;
&lt;p&gt;at org.jmanage.easymbean.impl.MBeanBuilder.getModelMBeanConstructorsInfo(Unknown Source)&lt;/p&gt;
&lt;p&gt;at org.jmanage.easymbean.impl.MBeanBuilder.getModelMBean(Unknown Source)&lt;/p&gt;
&lt;p&gt;at org.jmanage.easymbean.EasyMBean.getMBean(Unknown Source)&lt;/p&gt;
&lt;p&gt;.....&lt;/p&gt;
&lt;p&gt;I've taken a quick look at the source &amp;amp; noticed the following in getModelMBeanConstructorsInfo method:-&lt;/p&gt;
&lt;p&gt;369             try {&lt;br /&gt;
370                 managedConstructor =(ManagedConstructor) constructor.getAnnotation(ManagedConstructor.class);&lt;br /&gt;
371             }&lt;br /&gt;
372             catch(NullPointerException npe) {&lt;br /&gt;
373                 System.out.println("Invalid type for constructor: " + constructor.getName());&lt;br /&gt;
374             }&lt;/p&gt;
&lt;p&gt;It's great that you use a try/catch block there to catch Null Pointer. The most likely cause of a null pointer in that statement would be if constructor was null. However, in that case, the println in the catch block will throw another null pointer!&lt;/p&gt;
&lt;p&gt;Anyway, I'm now going to do some debugging to see if that's the cause of my problems.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Anonymous</dc:creator><pubDate>Wed, 23 May 2007 10:59:25 -0000</pubDate><guid>https://sourceforge.net56afee708b31e737e863095b6888abdf56104fec</guid></item></channel></rss>