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
|
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 *
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
|