Olaf Bergner wrote:

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



Yep.


Deployment jars are not loaded by the classloader passed in the
initial context?


Nope. The classloader supplied to the intial context is used as the root classloader when constructing the kernel api, spi and impl classloaders. The kernel api loader is then used as the parent for the root application container classloader. Subcontainer each receive a new classloader created using the containing containers classloader as the parent classloader.

I.e.: Parent/child classloader relationships.


RootClassLoader (from InitialContext) ^ | | MerlinAPIClassLoader |------------------------------| | | MerlinSPIClassLoader RootApplicationClassLoader | | | |-----------------------|---- | | | | BlockClassLoader-1 BlockClassLoader-1 | | | |------------------------ | | | BlockClassLoader-1.1 | | |-----------------------------| | | MerlinImplClassLoader FacilitiesClassLoader | |-----------------------| | | FacilitiesClassLoader-1 FacilitiesClassLoader-2 | |------------------------ |


NB.1 Faciities are not yet fully in place. NB.2 All of the above are URLClassLoader instances



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?


No.


Or are you referring to a possible future extension?


Yes.





(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.


Sure.


Cheers, Steve.


Take care,


Olaf


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]





--


Stephen J. McConnell
mailto:[EMAIL PROTECTED]

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/                               |
|------------------------------------------------|





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to