< prev index next >

jdk/test/javax/management/remote/mandatory/loading/TargetMBeanTest.java

Print this page




   9  * This code is distributed in the hope that it will be useful, but WITHOUT
  10  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  11  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  12  * version 2 for more details (a copy is included in the LICENSE file that
  13  * accompanied this code).
  14  *
  15  * You should have received a copy of the GNU General Public License version
  16  * 2 along with this work; if not, write to the Free Software Foundation,
  17  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  18  *
  19  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  20  * or visit www.oracle.com if you need additional information or have any
  21  * questions.
  22  */
  23 
  24 /*
  25  * @test
  26  * @bug 4910428
  27  * @summary Tests target MBean class loader used before JSR 160 loader
  28  * @author Eamonn McManus
  29  * @modules java.management
  30  * @run clean TargetMBeanTest
  31  * @run build TargetMBeanTest
  32  * @run main TargetMBeanTest
  33  */
  34 
  35 /*
  36   The JSR 160 spec says that, when invoking a method (or setting an
  37   attribute or creating) on a target MBean, that MBean's class loader
  38   is used to deserialize parameters.  The problem is that the RMI
  39   connector protocol wraps these parameters as MarshalledObjects.
  40   When you call get() on a MarshalledObject, the context class loader
  41   is used to deserialize, so if we set this to the target MBean's
  42   class loader everything should work.  EXCEPT that MarshalledObject
  43   first tries to load classes using the first class loader it finds in
  44   the caller's stack.  If our JSR 160 implementation is part of J2SE,
  45   it will not find any such class loader (only the system class
  46   loader).  But if it's standalone, then it will find the class loader
  47   of the JSR 160 implementation.  If the class name of a parameter is
  48   known to both the 160 loader and the target MBean loader, then we
  49   will use the wrong loader for deserialization and the attempt to




   9  * This code is distributed in the hope that it will be useful, but WITHOUT
  10  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  11  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  12  * version 2 for more details (a copy is included in the LICENSE file that
  13  * accompanied this code).
  14  *
  15  * You should have received a copy of the GNU General Public License version
  16  * 2 along with this work; if not, write to the Free Software Foundation,
  17  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  18  *
  19  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  20  * or visit www.oracle.com if you need additional information or have any
  21  * questions.
  22  */
  23 
  24 /*
  25  * @test
  26  * @bug 4910428
  27  * @summary Tests target MBean class loader used before JSR 160 loader
  28  * @author Eamonn McManus
  29  * @modules java.management.rmi
  30  * @run clean TargetMBeanTest
  31  * @run build TargetMBeanTest
  32  * @run main TargetMBeanTest
  33  */
  34 
  35 /*
  36   The JSR 160 spec says that, when invoking a method (or setting an
  37   attribute or creating) on a target MBean, that MBean's class loader
  38   is used to deserialize parameters.  The problem is that the RMI
  39   connector protocol wraps these parameters as MarshalledObjects.
  40   When you call get() on a MarshalledObject, the context class loader
  41   is used to deserialize, so if we set this to the target MBean's
  42   class loader everything should work.  EXCEPT that MarshalledObject
  43   first tries to load classes using the first class loader it finds in
  44   the caller's stack.  If our JSR 160 implementation is part of J2SE,
  45   it will not find any such class loader (only the system class
  46   loader).  But if it's standalone, then it will find the class loader
  47   of the JSR 160 implementation.  If the class name of a parameter is
  48   known to both the 160 loader and the target MBean loader, then we
  49   will use the wrong loader for deserialization and the attempt to


< prev index next >