2362N/A * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved. 0N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A * This code is free software; you can redistribute it and/or modify it 0N/A * under the terms of the GNU General Public License version 2 only, as 0N/A * published by the Free Software Foundation. 0N/A * This code is distributed in the hope that it will be useful, but WITHOUT 0N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A * version 2 for more details (a copy is included in the LICENSE file that 0N/A * accompanied this code). 0N/A * You should have received a copy of the GNU General Public License version 0N/A * 2 along with this work; if not, write to the Free Software Foundation, 0N/A * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 2362N/A * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 2362N/A * or visit www.oracle.com if you need additional information or have any 0N/A * @summary Tests target MBean class loader used before JSR 160 loader 0N/A * @author Eamonn McManus 0N/A * @run clean TargetMBeanTest 0N/A * @run build TargetMBeanTest 0N/A * @run main TargetMBeanTest 0N/A The JSR 160 spec says that, when invoking a method (or setting an 0N/A attribute or creating) on a target MBean, that MBean's class loader 0N/A is used to deserialize parameters. The problem is that the RMI 0N/A connector protocol wraps these parameters as MarshalledObjects. 0N/A When you call get() on a MarshalledObject, the context class loader 0N/A is used to deserialize, so if we set this to the target MBean's 0N/A class loader everything should work. EXCEPT that MarshalledObject 0N/A first tries to load classes using the first class loader it finds in 0N/A the caller's stack. If our JSR 160 implementation is part of J2SE, 0N/A it will not find any such class loader (only the system class 0N/A loader). But if it's standalone, then it will find the class loader 0N/A of the JSR 160 implementation. If the class name of a parameter is 0N/A known to both the 160 loader and the target MBean loader, then we 0N/A will use the wrong loader for deserialization and the attempt to 0N/A invoke the target MBean with the deserialized object will fail. 0N/A We test this as follows. We fabricate an MLet that has the same set 0N/A of URLs as the 160 class loader, which we assume is the system class 0N/A loader (or at least, it is a URLClassLoader). This MLet is 0N/A therefore a "shadow class loader" -- for every class name known to 0N/A the 160 class loader, it can load the same name, but the result is 0N/A not the same class, since it has not been loaded by the same loader. 0N/A Then, we use the MLet to create an RMIConnectorServer MBean. This 0N/A MBean is an instance of "shadow RMIConnectorServer", and its 0N/A constructor has a parameter of type "shadow JMXServiceURL". If the 0N/A constructor is invoked with "real JMXServiceURL" it will fail. 0N/A While we are at it, we also test that the behaviour is correct for 0N/A the JMXMP protocol, if that optional protocol is present. 0N/A "before JMX Remote API class loader");
0N/A "class loader, this test is irrelevant");
0N/A "JMXServiceURL not shadow");