You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2001/12/01 05:07:28 UTC

[phoenix] ClassLoader section in environment.xml

Hi,

Heres some thoughts about a possible way to define ClassLoader structure in 
the environment.xml file. Tell us what you think

<classloaders default="*application*">
  <classloader name="foo" parent="*api*">
    <entry location="sar:/some/dir/classes"/>
    <entry location="sar:/some/dir/mypackage.jar"/>
    <entry url="http://www.realityforge.org/some.jar"/>
  </classloader>

  <classloader name="bar" parent="*system*">
    <extension>
      <name>javax.servlet</name>
      <specification-version>2.3</specification-version>
      <vendor-id>org.apache.jakarta</vendor-id>
      <vendor-version>1.2.3.4</vendor-version>
    </extension>
  </classloader>

  <join name="baz">
     <classloader name="foo">
     <classloader name="bar">
  </join>

  <classloader name="common" parent="bar">
    <entry location="sar:/some/more/classes"/>
  </classloader>

</classloaders>

So in this case we have explicitly defined 4 classloaders; foo, bar, baz and 
common. The names of these classloaders are completely arbitrary. You will 
notice that I also refer to other predefined classloaders. These special 
classloaders can not be overiden and are defined by system. They are

o *system* (The System classloader)

o *api* (The classloader for phoenix API - will just contain framework.jar 
and phoenix-client.jar in future but now contains a wealth of other jars)

o *common* (The classloader that is shared between apps and container - empty 
now but will contain things like excalibur classes)

o *application* (Contains contents of SAR-INF/lib/*.jar + SAR-INF/classes. I 
am not sure if this is strictly needed though ...)

The <join/> classloader assumes that each classloader that it is made up of 
has a disjoint set of classes/resources contained in it. So it was the 
"aggregator" ClassLoader I was talking about.	

You will also notice the "default" attribute of <classloaders/> section. This 
specifies the ClassLoader via which the blocks are loaded. The only 
requirement being that one of it's parent classloaders must be "*api*".

So if/when this is implemented what does it mean ? Well we could finally 
implement a spec complaint servlet engine without jumping through loops. See 
below for a sample of how I would do it. We could also support nested 
"applications" like Stephen wanted. Woohoo!

<classloaders default="servlet-container">

  <classloader name="jndi-api" parent="*system*">
    <entry location="sar:SAR-INF/ext/jndi.jar"/>
  </classloader>

  <classloader name="servlet-api" parent="*system*">
    <extension>
      <name>javax.servlet</name>
      <specification-version>2.3</specification-version>
      <vendor-id>org.apache.jakarta</vendor-id>
      <vendor-version>1.2.3.4</vendor-version>
    </extension>
  </classloader>

  <join name="common">
     <classloader name="servlet-api"/>
     <classloader name="jndi-api"/>
  </join>

  <classloader name="servlet-container" parent="common">
    <entry location="sar:SAR-INF/lib/*.jar"/>
    <entry location="sar:SAR-INF/classes/"/>
  </classloader>

</classloaders>

Anyways - thoughts?
 
-- 
Cheers,

Pete

*----------------------------------------------*
| The best defense against logic is ignorance. |
*----------------------------------------------*

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [phoenix] ClassLoader section in environment.xml

Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,

Sorry dude, after reading it back it is not the solve-all suggestion I 
thought it was (even though you never understood it).  It was a good 
suggestion for namespace but it needless used classes to communicate 
that uniqueness.

- Paul

>On Sat, 1 Dec 2001 21:27, Paul Hammant wrote:
>
>>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
>>
>
>Not sure what you mean? Do you mean ask users to use classloader names with a 
>specific format in their blocks. So if we had a block
>
>org.apache.avalon.fooservice.FooBlock
>
>It should use classloader
>
>org.apache.avalon.fooservice.FooClassLoader
>
>???
>
>What happens when multiple Blocks all require the same resources? Or worse 
>require same resources but different versions ? Do we support this or not??
>
>>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.
>>
>
>Parsing sentence ... syntax valid.
>Semantic error: Compiler unable to determine what the hell you are on about 
>
>;)
>
>Pretend I am stupid and explain it to me in those terms.
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [phoenix] ClassLoader section in environment.xml

Posted by Peter Donald <pe...@apache.org>.
On Sat, 1 Dec 2001 21:27, Paul Hammant wrote:
> 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

Not sure what you mean? Do you mean ask users to use classloader names with a 
specific format in their blocks. So if we had a block

org.apache.avalon.fooservice.FooBlock

It should use classloader

org.apache.avalon.fooservice.FooClassLoader

???

What happens when multiple Blocks all require the same resources? Or worse 
require same resources but different versions ? Do we support this or not??

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

Parsing sentence ... syntax valid.
Semantic error: Compiler unable to determine what the hell you are on about 

;)

Pretend I am stupid and explain it to me in those terms.

-- 
Cheers,

Pete

----------------------------------------------------
"The only way to discover the limits of the possible 
is to go beyond them into the impossible." 
                             -Arthur C. Clarke
----------------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [phoenix] ClassLoader section in environment.xml

Posted by Paul Hammant <Pa...@yahoo.com>.
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [phoenix] ClassLoader section in environment.xml

Posted by Peter Donald <pe...@apache.org>.
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?

-- 
Cheers,

Pete

---------------------------------------------
 We shall not cease from exploration, and the 
  end of all our exploring will be to arrive 
 where we started and know the place for the 
        first time -- T.S. Eliot
---------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>