Peter,

This and the other email.  I like a lot.  I think you'll have trouble 
with <join>, but you knew I'd say that ;-)

The multiple "foo" scenario, which is a real namespace issue, could it 
not be address java-package style? :

    org.apache.avalon.fooservice.FooClassLoaderNode

We could actually have an interface called ClassLoaderNode that a real 
class could impl. It has in it some getters that pheonix could use for 
semi-hard coded checking against the assembly manifest? ... similar to 
<required> functionality of manifest.  It is class loaded by full class 
name via the getClassLoader() as you described.

Regards,

- Paul H

>Hi,
>
>One thing I forgot to mention was how Blocks aquire the ClassLoaders. I 
>propose that we add another method to BlockContext interface, namely
>
>ClassLoader getClassLoader(String name)
>
>This raises an interesting question though. How should a Block declare that 
>it needs a ClassLoader named "foo" and "foo" must contain classes X, Y and Z? 
>Should it declare that?
>
>My initial though was that you could add another section to the BlockInfo 
>file like
>
><classloaders>
>  <classloader name="foo">
>     <description>
>        This ClassLoader must contain classes X, Y and Z. It is 
>       part of the foo API and we use it to do "Something".
>     </description>
>      <required classname="com.biz.ClassToCheckFor"/>
>  </classloader>
></classloaders>
>
>Then I realized - what would happen if 2 Blocks declared that they depended 
>on ClassLoaders named "foo" but which had different contents. So in this case 
>it would be required that you map the application-wide name into a 
>block-local name ... which seems like overkill/flexability syndrome. 
>
>So options that I could think of are;
>1. ignore the issue and make it a requirement that Block writers document it 
>so that assemblers can build it
>2. have basic structures in blockinfo but keep names global
>3. Same as 3 but we map classloader names from global namespace to 
>application local namespace.
>
>Thoughts?
>




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

Reply via email to