Bugs item #644289, was opened at 2002-11-26 11:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=644289&group_id=22866
Category: JBossMX Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Scott M Stark (starksm) Summary: ClassLoader issue with protected access and manifest refs Initial Comment: When package protected access is used with classes that are loaded by more than one classloader via manifest Class-Path references you can get IllegalAccessErrors when more than one jar references the jar containing the classes due to the use of a UCL per jar. This has been reported in various forms in bugs 565701, 606359, 641740 and is consolidated here with a trival testcase that demonstrates the problem. The org.jboss.test.classloader.test.CircularityUnitTestCase testPackageProtected unit test demonstrates the problem with a repository that contains a login.jar and a usrmgr.jar, both of which reference a cl-util.jar. The contents of the jars is: login.jar +- org/jboss/test/classloader/circularity/support/UserOfLogi nInfo.class +- META-INF/MANIFEST.MF Class-Path: cl-util.jar usrmgr.jar +- org/jboss/test/classloader/circularity/support/UserOfUsr Mgr.class +- META-INF/MANIFEST.MF Class-Path: cl-util.jar cl-util.jar +- org/jboss/test/classloader/circularity/support/LoginInfo.cl ass +- org/jboss/test/classloader/circularity/support/UsrMgr.cla ss +- META-INF/MANIFEST.MF The test first loads the UserOfLoginInfo class using the UCL associated with login.jar, and then loads the UserOfUsrMgr class using the UCL associated with usrmgr.jar. A changePassword method is then invoked on an instance of UserOfUsrMgr and this results in an IllegalAccessError because the LoginInfo class was seen to be loaded from the UCL associated with login.jar while the UsMgr class was loaded from the UCL associated with usrmgr.jar. Although both are in the same package and jar, two different class loaders are involved and so the access check fails. The only workaround at the moment requires moving the common jar to the server/xxx/lib directory so that the UCLs do not see common jar as part of their classes. ---------------------------------------------------------------------- >Comment By: Scott M Stark (starksm) Date: 2002-12-23 23:48 Message: Logged In: YES user_id=175228 This has been fixed in the 3.0 and 3.2 branches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=644289&group_id=22866 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
