On 2002.03.02 04:41:37 -0500 Jason Dillon wrote: > Why do we attempt to install an MBean before its dependencies have been > met? Looks like install hapens before create, and create is where > depends logic begins. It seems like a better choice would be to check > for depends before installing, or rather before attempting to > instantiate the mbean object, as it might not have all of the required > classes loaded. > > I had to put explict archive refs back in jboss-service.xml to test > netboot and ran into this problem... where hsqldb-default-service.xml > depends on beans in jbosscx.sar. Since this is the only place where > org.jboss.resource.* classes are, anything that references them will > need to load after it does.
In general, that won't help. It happens in this case that jbosscx.sar defines an mbean that DefaultDS needs, so deployment would wait, but if put the ConnectionFactoryLoader class somewhere else there'd be no way to look for it using depends. Marc wanted to use the MBeanClassLoader to keep track of class dependencies and wait if a class was not found when you tried to "install" it. I'm not sure how far he got with this. Looking for depends elements before the mbean is available also means you either have to parse the xml twice or parse it into a holding structure and then later transfer it to the mbean itself. I guess the latter might be possible using xmbean interceptors, but I'm not convinced it will buy us anything. david jencks > > Short term solution would be to put those common resource files into > lib/ but I think that the depends logic might need to be done a little > sooner to avoid such strange behavior. > > --jason > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
