> -----Original Message----- > From: Stephen McConnell [mailto:[EMAIL PROTECTED] > Sent: Monday, December 22, 2003 2:54 PM > > Olaf: > > I would have thought that your classloader would need to be applied > at the bottom of the stack (not the top).
Yes, ultimately I would like to be able to just let my deployment jars be loaded by the aspectwerkz classloader. However, in trying to just get anything working I stuffed it into every method/constructor that would take it. > I.e. in DefaultClassLoaderModel > you can see the following line that creates the classloader for a > container: > > m_classLoader = > new URLClassLoader( m_urls, context.getClassLoader() ); Yes, I noticed this line. But somehow context.getClassLoader() would NOT return the classloader I passed in via InitialContext. IIRC, running everything through a debugger revealed the classloader to be assigned to my container the classloader defined in DefaultSystemContext, i.e. one of m_system = SystemContext.class.getClassLoader(); m_common = Logger.class.getClassLoader(); Just to make sure that I didn't make a mistake: this is how it's supposed to be, right? Deployment jars are not loaded by the classloader passed in the initial context? > > If the <classloader> defintion was extended to include an attribute > declaring > the type of classloader, then that classloader could be assigned > as the new > classloader. > Here, are you referring to the current state of affairs, i.e. is there a feature like <classloader class|type|whatever="package.WeavingClassLoader"> ... </classloader> which I could use now? Or are you referring to a possible future extension? > (but keep in mind that I know zero about aspectwerkz) > Me neither, but it sounds like fun to get both of 'em - merlin and aspectwerkz - working. Take care, Olaf --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
