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 <do...@apache.org> on 2001/09/30 11:15:58 UTC
[phoenix] RT: ClassLoader hierarchy
Hi,
Currently Phoenix has a relatively simple ClassLoader mechanism. It has the
following layout
System ClassLoader <--- Kernel ClassLoader
<--- Application ClassLoader (s)
The System ClassLoader includes avalon-framework.jar, phoenix-client.jar and
any other jars included in ${phoenix.home}/lib/ (currently xerces and
excalibur are required).
This works great if you are just writing normal server applications. The
problem arises when you try to write applications that will in turn host
other components. For instance a servlet container requires a very specific
ClassLoader hierarchy for it to work. For instance the base ClassLoader is
meant to only contain a handful of files (including servlet.jar and various
other "common" jar files).
However we can only partially implement that at the moment by placing the
library files into ${phoenix.home}/lib however even that case we can not
remove avalon-framework.jar, phoenix-client.jar, etc as they are required so
that Application and Kernel can talk. So in reality it would be difficult to
implement a fully compliant EJB, Servlet etc application without writing
another ClassLoader (that didn't delegate to top of ClassLoader hierarchy). A
few servlet engines already do this but I would prefer if it was easier in
Phoenix.
My initial thoughts were to create something like
System ClassLoader <--- Common ClassLoader <--- Kernel ClassLoader
<--- Application ClassLoader (s)
where Common ClassLoader contains avalon-framework.jar, phoenix-client.jar,
excalibur etc.
That way the Application could create a ClassLoader that delegated to System
ClassLoader but wasn't pollutted by Avalon specific jars.
However then I thought that this could be bad because some Applications
require that extra elements be added to Common ClassLoader that this wouldn't
work. ie A servlet container would still require that servlet.jar be loaded
by Application ClassLoader (or one of it's parents) and thus you would still
have to stuff the servlet.jar into System ClassLoader for this to work. And
this is not a good thing IMHO.
So then I got to thinking about something Paul said. Maybe we could declare
ClassLoader hierarhy in the server.xml. However because a hierarchial
ClassLoader still wouldn't work we would have to have an Aggregator
ClassLoader that aggregated several ClassLoaders together so we could do
something like
System ClassLoader <--- Common ClassLoader <--- Kernel ClassLoader
<---|
| Application ClassLoader (s)
Servlet ClassLoader <---|
This way we could get access to the unpolluted ClassLoader to work as base
ClassLoader for web application. This would be the same ClassLoader that the
Application used to load the servlet interfaces and thus it would be easy to
provide implementation in Application space.
As a matter of fact this could be extended so that an arbitrary number of
ClassLoaders could be aggregated for application. However this assumes that
each ClassLoader aggregated contains separate namespace. ie The same Class
can not be available in multiple ClassLoaders for this to work.
To support all this we would need to add an extra method to BlockContext to
get named ClassLoader and we would have to enhance server.xml to allow
ClassLoader hierarchys to be configured in it (not sure on format).
Thoughts?
--
Cheers,
Pete
---------------------------------------------------------
Clarke's Third Law: "Any technology distinguishable from
magic is insufficiently advanced".
---------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] RT: ClassLoader hierarchy
Posted by Peter Donald <do...@apache.org>.
On Wed, 7 Nov 2001 10:44, Paul Hammant wrote:
> Peter,
>
> >It doesn't matter what you think. As soon as you do that you are no longer
> > a spec compliant servlet container which could potentially be very bad.
> > It would be worse if you hosted servlets like Cocoon that possibly used a
> > different version of Avalon then your whole setup would not be able to
> > run the Cocoon webapp. Bummer huh ?
>
> OK, We're back to Promotion again then.
eww ;)
> Sar conains two things 1) An spec level API, 2) Implementation of that
> API plus the ability to launch sub-apps (mail lets, ftp lets etc).
>
> (1) is contained entirely in a jar. In assembly.xml it's listed as :
>
> <spec name="Sun-Servlet" version="2.3" jar="SAR-INF/spec/servlet.jar"/>
>
> The phoenix class loader bumps these into the top level as a once off
> transaction. These are not replaceable nor un-installable in a running
> Phoenix.
the problem here is that applications are no longer independent of each
other. We could conceivably cause one app to fail by actions of another app
which I don't really like.
> If you have something that works then go for it
nnot sure. Just thinking about it at this stage ;)
> Peter, please try to fix Jesktop at the same time though.
;)
--
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>
Re: [Excalibur] PriorityQueue & BinaryHeap proposal
Posted by Peter Donald <do...@apache.org>.
On Wed, 14 Nov 2001 00:47, Chad Stansbury wrote:
> I will download your changes and test them. Luckily I have a bunch of
> tests from my own n-ary heap class that I can modify and use to test this
> version. Once I'm finished I'll upload the test driver to this list.
great!
>
> Thanks, Chad
>
> ----- Original Message -----
> From: "Peter Donald" <do...@apache.org>
> To: "Avalon Developers List" <av...@jakarta.apache.org>
> Sent: Tuesday, November 13, 2001 2:54 AM
> Subject: Re: [Excalibur] PriorityQueue & BinaryHeap proposal
>
> > Okay. I added the patch with a few changes. Essentially you had made some
> > methods protected when they were previously private. I changed them back
>
> to
>
> > private.
> >
> > I also readded a few constructors that were in the last version (the ones
> > that took a boolean indicating whether it was a maximum or minimum heap).
> > This was mainly to minimize the change in interface between the two
>
> versions.
>
> > I also added you as an author tag.
> >
> > Anyways could you download it from CVS and make sure I didn't stuff
>
> anything
>
> > up ? ;)
> >
> > Unfortunately we don't have a unit test for the PriorityHeap and we
> > really should have one.
> >
> > On Thu, 8 Nov 2001 11:58, Chad Stansbury wrote:
> > > Attached are the files that I have patched to allow the priority queue,
> > > synchronized priority queue, and binary heap to accept Objects rather
>
> than
>
> > > Comparables. Note that these patches do not retain backwards
> > > compatibility. You will find that the following major implementation
> > > changes were made:
> > >
> > > 1. All references to Comparable have been changed to Object
> > > 2. I have substituted a Comparator for the isMinHeap parameter. The
> > > BinaryHeap now has two constants - MAX_COMPARATOR and MIN_COMPARATOR.
> > > These comparators assume that the elements stored in the heap implement
>
> the
>
> > > Comparable interface. If you don't specify a comparator in the
>
> constructor,
>
> > > it defaults to MIN_COMPARATOR, thereby yielding a min heap. If you
> > > want
>
> a
>
> > > max heap, you specify MAX_COMPARATOR in the constructor. You can also
> > > specify a custom comparator if you don't want to rely on the content's
> > > natural ordering.
> > > 3. I have consolidated the separate percolateDown/Up Min and Max heap
> > > methods. Instead there is now just a single percolateDownHeap and
> > > percolateUpHeap method that utilizes the comparator to determine the
> > > ordering.
> > > 4. I have made 2 performance related changes:
> > > 4a. I have removed a redundant divide and multiply statement in the
>
> while
>
> > > loop for the two percolate methods. This resulted in a 4% speed
>
> increase.
>
> > > 4b. I have changed 'hole * 2' and 'hole / 2' to 'hold << 1' and 'hold
> > > >> 1', respectively. I would have thought the java compiler would
> > > perform this optimization for me, but alas, jdk 1.3.1 does not appear
> > > to do so. Anyhow, this seems to increase the speed of the insert
> > > operation by a non-trivial amount.
> > >
> > > Unfortunately, the new implementation degrades the pop performance
> > > somewhat. I have seen about a 9% performance hit when inserting and
>
> popping
>
> > > 2,000,000 random Integers into the heap (14,971 ms for the old
> > > implementation vs. 16,414 ms using the new implementation). This
> > > performance degradation can be attributed to the additional method call
>
> and
>
> > > cast involved with using a Comparator rather than directly invoking the
> > > element's compareTo method.
> > >
> > > All performance measurements were recording on a 1.4 GHz P4 running
> > > jdk1.3.1_01 on Win2K.
> > >
> > > ----- Original Message -----
> > > From: "Peter Donald" <do...@apache.org>
> > > To: "Avalon Developers List" <av...@jakarta.apache.org>
> > > Sent: Wednesday, November 07, 2001 7:49 AM
> > > Subject: Re: [Excalibur] PriorityQueue & BinaryHeap proposal
> > >
> > > > On Thu, 8 Nov 2001 01:04, Chad Stansbury wrote:
> > > > > Okay - here's the problem. The current BinaryHeap interface
> > > > > expects
>
> a
>
> > > > > Comparable for it's public interface. In order to maintain
>
> backwards
>
> > > > > compatibility I must either:
> > > > >
> > > > > 1. Add new public methods to the BinaryHeap class (e.g.,
>
> insertObject,
>
> > > > > peekObject, popObject) and change the insert, peek, and pop methods
>
> to
>
> > > > > invoke these new methods, or
> > > > > 2. I can create a new BinaryObjectHeap class and have the
> > > > > BinaryHeap
> > >
> > > class
> > >
> > > > > act as a wrapper class.
> > > > >
> > > > > I am also wondering how I would modify the PriorityQueue interface
>
> w/o
>
> > > > > breaking backwards compatibility...
> > > > >
> > > > > Any suggestions would be appreciated.
> > > >
> > > > I am not sure we need to maintain 100% backwards compatability in
> > > > this
> > >
> > > case.
> > >
> > > > peek() and pop() methods in al cases that I use them and have seen
>
> them
>
> > > used
> > >
> > > > will actually need to be cast to something else anyways. Retrieving a
> > > > Comparable from heap is rarely the aim and come to think of it I
> > > > think
>
> it
>
> > > was
> > >
> > > > probably a mistake to return Comparables rather than Objects ;)
> > > >
> > > > For insert there will need to be backwards compatability because
>
> people
>
> > > will
> > >
> > > > use that to pass in comparables. However you should be ab;le to get
> > >
> > > backwards
> > >
> > > > compatability with this by just checking the type passed in (if
> > > > Comparable
> > >
> > > do
> > >
> > > > X, else do Y) and converting parameter to Object.
> > > >
> > > > --
> > > > Cheers,
> > > >
> > > > Pete
> > > >
> > > > --------------------------------------------------------------
> > > > "Science is like sex: sometimes something useful comes out,
> > > > but that is not the reason we are doing it" -- Richard Feynman
> > > > --------------------------------------------------------------
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > >
> > > <ma...@jakarta.apache.org>
> > >
> > > > For additional commands, e-mail:
> > >
> > > <ma...@jakarta.apache.org>
> >
> > --
> > Cheers,
> >
> > Pete
> >
> > ---------------------------------------------------
> > "It is easy to dodge our responsibilities, but we
> > cannot dodge the consequences of dodging our
> > responsibilities." -Josiah Stamp
> > ---------------------------------------------------
> >
> > --
> > To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@jakarta.apache.org>
--
Cheers,
Pete
-----------------------------------------------------------------------
| I thought there was a knob on the TV to turn up the intelligence. |
| There's a knob called "brightness", but it doesn't work. |
-----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Excalibur] PriorityQueue & BinaryHeap proposal
Posted by Chad Stansbury <st...@earthlink.net>.
I will download your changes and test them. Luckily I have a bunch of tests
from my own n-ary heap class that I can modify and use to test this version.
Once I'm finished I'll upload the test driver to this list.
Thanks, Chad
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Tuesday, November 13, 2001 2:54 AM
Subject: Re: [Excalibur] PriorityQueue & BinaryHeap proposal
> Okay. I added the patch with a few changes. Essentially you had made some
> methods protected when they were previously private. I changed them back
to
> private.
>
> I also readded a few constructors that were in the last version (the ones
> that took a boolean indicating whether it was a maximum or minimum heap).
> This was mainly to minimize the change in interface between the two
versions.
>
> I also added you as an author tag.
>
> Anyways could you download it from CVS and make sure I didn't stuff
anything
> up ? ;)
>
> Unfortunately we don't have a unit test for the PriorityHeap and we really
> should have one.
>
> On Thu, 8 Nov 2001 11:58, Chad Stansbury wrote:
> > Attached are the files that I have patched to allow the priority queue,
> > synchronized priority queue, and binary heap to accept Objects rather
than
> > Comparables. Note that these patches do not retain backwards
> > compatibility. You will find that the following major implementation
> > changes were made:
> >
> > 1. All references to Comparable have been changed to Object
> > 2. I have substituted a Comparator for the isMinHeap parameter. The
> > BinaryHeap now has two constants - MAX_COMPARATOR and MIN_COMPARATOR.
> > These comparators assume that the elements stored in the heap implement
the
> > Comparable interface. If you don't specify a comparator in the
constructor,
> > it defaults to MIN_COMPARATOR, thereby yielding a min heap. If you want
a
> > max heap, you specify MAX_COMPARATOR in the constructor. You can also
> > specify a custom comparator if you don't want to rely on the content's
> > natural ordering.
> > 3. I have consolidated the separate percolateDown/Up Min and Max heap
> > methods. Instead there is now just a single percolateDownHeap and
> > percolateUpHeap method that utilizes the comparator to determine the
> > ordering.
> > 4. I have made 2 performance related changes:
> > 4a. I have removed a redundant divide and multiply statement in the
while
> > loop for the two percolate methods. This resulted in a 4% speed
increase.
> > 4b. I have changed 'hole * 2' and 'hole / 2' to 'hold << 1' and 'hold >>
> > 1', respectively. I would have thought the java compiler would perform
> > this optimization for me, but alas, jdk 1.3.1 does not appear to do so.
> > Anyhow, this seems to increase the speed of the insert operation by a
> > non-trivial amount.
> >
> > Unfortunately, the new implementation degrades the pop performance
> > somewhat. I have seen about a 9% performance hit when inserting and
popping
> > 2,000,000 random Integers into the heap (14,971 ms for the old
> > implementation vs. 16,414 ms using the new implementation). This
> > performance degradation can be attributed to the additional method call
and
> > cast involved with using a Comparator rather than directly invoking the
> > element's compareTo method.
> >
> > All performance measurements were recording on a 1.4 GHz P4 running
> > jdk1.3.1_01 on Win2K.
> >
> > ----- Original Message -----
> > From: "Peter Donald" <do...@apache.org>
> > To: "Avalon Developers List" <av...@jakarta.apache.org>
> > Sent: Wednesday, November 07, 2001 7:49 AM
> > Subject: Re: [Excalibur] PriorityQueue & BinaryHeap proposal
> >
> > > On Thu, 8 Nov 2001 01:04, Chad Stansbury wrote:
> > > > Okay - here's the problem. The current BinaryHeap interface expects
a
> > > > Comparable for it's public interface. In order to maintain
backwards
> > > > compatibility I must either:
> > > >
> > > > 1. Add new public methods to the BinaryHeap class (e.g.,
insertObject,
> > > > peekObject, popObject) and change the insert, peek, and pop methods
to
> > > > invoke these new methods, or
> > > > 2. I can create a new BinaryObjectHeap class and have the BinaryHeap
> >
> > class
> >
> > > > act as a wrapper class.
> > > >
> > > > I am also wondering how I would modify the PriorityQueue interface
w/o
> > > > breaking backwards compatibility...
> > > >
> > > > Any suggestions would be appreciated.
> > >
> > > I am not sure we need to maintain 100% backwards compatability in this
> >
> > case.
> >
> > > peek() and pop() methods in al cases that I use them and have seen
them
> >
> > used
> >
> > > will actually need to be cast to something else anyways. Retrieving a
> > > Comparable from heap is rarely the aim and come to think of it I think
it
> >
> > was
> >
> > > probably a mistake to return Comparables rather than Objects ;)
> > >
> > > For insert there will need to be backwards compatability because
people
> >
> > will
> >
> > > use that to pass in comparables. However you should be ab;le to get
> >
> > backwards
> >
> > > compatability with this by just checking the type passed in (if
> > > Comparable
> >
> > do
> >
> > > X, else do Y) and converting parameter to Object.
> > >
> > > --
> > > Cheers,
> > >
> > > Pete
> > >
> > > --------------------------------------------------------------
> > > "Science is like sex: sometimes something useful comes out,
> > > but that is not the reason we are doing it" -- Richard Feynman
> > > --------------------------------------------------------------
> > >
> > > --
> > > To unsubscribe, e-mail:
> >
> > <ma...@jakarta.apache.org>
> >
> > > For additional commands, e-mail:
> >
> > <ma...@jakarta.apache.org>
>
> --
> Cheers,
>
> Pete
>
> ---------------------------------------------------
> "It is easy to dodge our responsibilities, but we
> cannot dodge the consequences of dodging our
> responsibilities." -Josiah Stamp
> ---------------------------------------------------
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Excalibur] PriorityQueue & BinaryHeap proposal
Posted by Peter Donald <do...@apache.org>.
Okay. I added the patch with a few changes. Essentially you had made some
methods protected when they were previously private. I changed them back to
private.
I also readded a few constructors that were in the last version (the ones
that took a boolean indicating whether it was a maximum or minimum heap).
This was mainly to minimize the change in interface between the two versions.
I also added you as an author tag.
Anyways could you download it from CVS and make sure I didn't stuff anything
up ? ;)
Unfortunately we don't have a unit test for the PriorityHeap and we really
should have one.
On Thu, 8 Nov 2001 11:58, Chad Stansbury wrote:
> Attached are the files that I have patched to allow the priority queue,
> synchronized priority queue, and binary heap to accept Objects rather than
> Comparables. Note that these patches do not retain backwards
> compatibility. You will find that the following major implementation
> changes were made:
>
> 1. All references to Comparable have been changed to Object
> 2. I have substituted a Comparator for the isMinHeap parameter. The
> BinaryHeap now has two constants - MAX_COMPARATOR and MIN_COMPARATOR.
> These comparators assume that the elements stored in the heap implement the
> Comparable interface. If you don't specify a comparator in the constructor,
> it defaults to MIN_COMPARATOR, thereby yielding a min heap. If you want a
> max heap, you specify MAX_COMPARATOR in the constructor. You can also
> specify a custom comparator if you don't want to rely on the content's
> natural ordering.
> 3. I have consolidated the separate percolateDown/Up Min and Max heap
> methods. Instead there is now just a single percolateDownHeap and
> percolateUpHeap method that utilizes the comparator to determine the
> ordering.
> 4. I have made 2 performance related changes:
> 4a. I have removed a redundant divide and multiply statement in the while
> loop for the two percolate methods. This resulted in a 4% speed increase.
> 4b. I have changed 'hole * 2' and 'hole / 2' to 'hold << 1' and 'hold >>
> 1', respectively. I would have thought the java compiler would perform
> this optimization for me, but alas, jdk 1.3.1 does not appear to do so.
> Anyhow, this seems to increase the speed of the insert operation by a
> non-trivial amount.
>
> Unfortunately, the new implementation degrades the pop performance
> somewhat. I have seen about a 9% performance hit when inserting and popping
> 2,000,000 random Integers into the heap (14,971 ms for the old
> implementation vs. 16,414 ms using the new implementation). This
> performance degradation can be attributed to the additional method call and
> cast involved with using a Comparator rather than directly invoking the
> element's compareTo method.
>
> All performance measurements were recording on a 1.4 GHz P4 running
> jdk1.3.1_01 on Win2K.
>
> ----- Original Message -----
> From: "Peter Donald" <do...@apache.org>
> To: "Avalon Developers List" <av...@jakarta.apache.org>
> Sent: Wednesday, November 07, 2001 7:49 AM
> Subject: Re: [Excalibur] PriorityQueue & BinaryHeap proposal
>
> > On Thu, 8 Nov 2001 01:04, Chad Stansbury wrote:
> > > Okay - here's the problem. The current BinaryHeap interface expects a
> > > Comparable for it's public interface. In order to maintain backwards
> > > compatibility I must either:
> > >
> > > 1. Add new public methods to the BinaryHeap class (e.g., insertObject,
> > > peekObject, popObject) and change the insert, peek, and pop methods to
> > > invoke these new methods, or
> > > 2. I can create a new BinaryObjectHeap class and have the BinaryHeap
>
> class
>
> > > act as a wrapper class.
> > >
> > > I am also wondering how I would modify the PriorityQueue interface w/o
> > > breaking backwards compatibility...
> > >
> > > Any suggestions would be appreciated.
> >
> > I am not sure we need to maintain 100% backwards compatability in this
>
> case.
>
> > peek() and pop() methods in al cases that I use them and have seen them
>
> used
>
> > will actually need to be cast to something else anyways. Retrieving a
> > Comparable from heap is rarely the aim and come to think of it I think it
>
> was
>
> > probably a mistake to return Comparables rather than Objects ;)
> >
> > For insert there will need to be backwards compatability because people
>
> will
>
> > use that to pass in comparables. However you should be ab;le to get
>
> backwards
>
> > compatability with this by just checking the type passed in (if
> > Comparable
>
> do
>
> > X, else do Y) and converting parameter to Object.
> >
> > --
> > Cheers,
> >
> > Pete
> >
> > --------------------------------------------------------------
> > "Science is like sex: sometimes something useful comes out,
> > but that is not the reason we are doing it" -- Richard Feynman
> > --------------------------------------------------------------
> >
> > --
> > To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@jakarta.apache.org>
--
Cheers,
Pete
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Excalibur] PriorityQueue & BinaryHeap proposal
Posted by Chad Stansbury <st...@earthlink.net>.
Ah, that's good to see. I omitted the 'break backwards-compatibility'
option because I simply don't know who this might impact. Like you mention,
by having the PriorityQueue interface constrain the contents of the queue to
Comparables, it's limiting the implementation possibilities.
Anyhoo, I will go ahead and implement #2 for backwards compatibility
purposes, and also implement a non-backwards compatible version that accepts
and returns Objects. I will then hand these off to you and let you deal
with it.
Thanks, Chad
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Wednesday, November 07, 2001 7:49 AM
Subject: Re: [Excalibur] PriorityQueue & BinaryHeap proposal
> On Thu, 8 Nov 2001 01:04, Chad Stansbury wrote:
> > Okay - here's the problem. The current BinaryHeap interface expects a
> > Comparable for it's public interface. In order to maintain backwards
> > compatibility I must either:
> >
> > 1. Add new public methods to the BinaryHeap class (e.g., insertObject,
> > peekObject, popObject) and change the insert, peek, and pop methods to
> > invoke these new methods, or
> > 2. I can create a new BinaryObjectHeap class and have the BinaryHeap
class
> > act as a wrapper class.
> >
> > I am also wondering how I would modify the PriorityQueue interface w/o
> > breaking backwards compatibility...
> >
> > Any suggestions would be appreciated.
>
> I am not sure we need to maintain 100% backwards compatability in this
case.
> peek() and pop() methods in al cases that I use them and have seen them
used
> will actually need to be cast to something else anyways. Retrieving a
> Comparable from heap is rarely the aim and come to think of it I think it
was
> probably a mistake to return Comparables rather than Objects ;)
>
> For insert there will need to be backwards compatability because people
will
> use that to pass in comparables. However you should be ab;le to get
backwards
> compatability with this by just checking the type passed in (if Comparable
do
> X, else do Y) and converting parameter to Object.
>
> --
> Cheers,
>
> Pete
>
> --------------------------------------------------------------
> "Science is like sex: sometimes something useful comes out,
> but that is not the reason we are doing it" -- Richard Feynman
> --------------------------------------------------------------
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Excalibur] PriorityQueue & BinaryHeap proposal
Posted by Chad Stansbury <st...@earthlink.net>.
Attached are the files that I have patched to allow the priority queue,
synchronized priority queue, and binary heap to accept Objects rather than
Comparables. Note that these patches do not retain backwards compatibility.
You will find that the following major implementation changes were made:
1. All references to Comparable have been changed to Object
2. I have substituted a Comparator for the isMinHeap parameter. The
BinaryHeap now has two constants - MAX_COMPARATOR and MIN_COMPARATOR. These
comparators assume that the elements stored in the heap implement the
Comparable interface. If you don't specify a comparator in the constructor,
it defaults to MIN_COMPARATOR, thereby yielding a min heap. If you want a
max heap, you specify MAX_COMPARATOR in the constructor. You can also
specify a custom comparator if you don't want to rely on the content's
natural ordering.
3. I have consolidated the separate percolateDown/Up Min and Max heap
methods. Instead there is now just a single percolateDownHeap and
percolateUpHeap method that utilizes the comparator to determine the
ordering.
4. I have made 2 performance related changes:
4a. I have removed a redundant divide and multiply statement in the while
loop for the two percolate methods. This resulted in a 4% speed increase.
4b. I have changed 'hole * 2' and 'hole / 2' to 'hold << 1' and 'hold >> 1',
respectively. I would have thought the java compiler would perform this
optimization for me, but alas, jdk 1.3.1 does not appear to do so. Anyhow,
this seems to increase the speed of the insert operation by a non-trivial
amount.
Unfortunately, the new implementation degrades the pop performance somewhat.
I have seen about a 9% performance hit when inserting and popping 2,000,000
random Integers into the heap (14,971 ms for the old implementation vs.
16,414 ms using the new implementation). This performance degradation can
be attributed to the additional method call and cast involved with using a
Comparator rather than directly invoking the element's compareTo method.
All performance measurements were recording on a 1.4 GHz P4 running
jdk1.3.1_01 on Win2K.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Wednesday, November 07, 2001 7:49 AM
Subject: Re: [Excalibur] PriorityQueue & BinaryHeap proposal
> On Thu, 8 Nov 2001 01:04, Chad Stansbury wrote:
> > Okay - here's the problem. The current BinaryHeap interface expects a
> > Comparable for it's public interface. In order to maintain backwards
> > compatibility I must either:
> >
> > 1. Add new public methods to the BinaryHeap class (e.g., insertObject,
> > peekObject, popObject) and change the insert, peek, and pop methods to
> > invoke these new methods, or
> > 2. I can create a new BinaryObjectHeap class and have the BinaryHeap
class
> > act as a wrapper class.
> >
> > I am also wondering how I would modify the PriorityQueue interface w/o
> > breaking backwards compatibility...
> >
> > Any suggestions would be appreciated.
>
> I am not sure we need to maintain 100% backwards compatability in this
case.
> peek() and pop() methods in al cases that I use them and have seen them
used
> will actually need to be cast to something else anyways. Retrieving a
> Comparable from heap is rarely the aim and come to think of it I think it
was
> probably a mistake to return Comparables rather than Objects ;)
>
> For insert there will need to be backwards compatability because people
will
> use that to pass in comparables. However you should be ab;le to get
backwards
> compatability with this by just checking the type passed in (if Comparable
do
> X, else do Y) and converting parameter to Object.
>
> --
> Cheers,
>
> Pete
>
> --------------------------------------------------------------
> "Science is like sex: sometimes something useful comes out,
> but that is not the reason we are doing it" -- Richard Feynman
> --------------------------------------------------------------
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
Re: [Excalibur] PriorityQueue & BinaryHeap proposal
Posted by Peter Donald <do...@apache.org>.
On Thu, 8 Nov 2001 01:04, Chad Stansbury wrote:
> Okay - here's the problem. The current BinaryHeap interface expects a
> Comparable for it's public interface. In order to maintain backwards
> compatibility I must either:
>
> 1. Add new public methods to the BinaryHeap class (e.g., insertObject,
> peekObject, popObject) and change the insert, peek, and pop methods to
> invoke these new methods, or
> 2. I can create a new BinaryObjectHeap class and have the BinaryHeap class
> act as a wrapper class.
>
> I am also wondering how I would modify the PriorityQueue interface w/o
> breaking backwards compatibility...
>
> Any suggestions would be appreciated.
I am not sure we need to maintain 100% backwards compatability in this case.
peek() and pop() methods in al cases that I use them and have seen them used
will actually need to be cast to something else anyways. Retrieving a
Comparable from heap is rarely the aim and come to think of it I think it was
probably a mistake to return Comparables rather than Objects ;)
For insert there will need to be backwards compatability because people will
use that to pass in comparables. However you should be ab;le to get backwards
compatability with this by just checking the type passed in (if Comparable do
X, else do Y) and converting parameter to Object.
--
Cheers,
Pete
--------------------------------------------------------------
"Science is like sex: sometimes something useful comes out,
but that is not the reason we are doing it" -- Richard Feynman
--------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Excalibur] PriorityQueue & BinaryHeap proposal
Posted by Peter Donald <do...@apache.org>.
On Thu, 8 Nov 2001 01:54, Berin Loritsch wrote:
> Chad Stansbury wrote:
> > Okay - here's the problem. The current BinaryHeap interface expects a
> > Comparable for it's public interface. In order to maintain backwards
> > compatibility I must either:
> >
> > 1. Add new public methods to the BinaryHeap class (e.g., insertObject,
> > peekObject, popObject) and change the insert, peek, and pop methods to
> > invoke these new methods, or
> > 2. I can create a new BinaryObjectHeap class and have the BinaryHeap
> > class act as a wrapper class.
> >
> > I am also wondering how I would modify the PriorityQueue interface w/o
> > breaking backwards compatibility...
> >
> > Any suggestions would be appreciated.
>
> Peter, could you give a quick overview of how it is supposed to work?
> BTW, I don't like the insert() when you have pop() and peek(). If you
> are going to use Stack semantics and idioms, then use push() for the
> same purpose.
It is not using "Stack semantics and idioms" but PriorityQueue semantics and
idioms. I guess everyone uses insert() rather than push() because push() has
idea of LIFO which is wrong.
> If we are dealing with a queue, that is primarily a FIFO implementation
> (IOW merely a buffer). That means that if you push the following into
> the queue:
>
> 1 2 3 4 5
>
> You pop the information out of the queue in this order:
>
> 1 2 3 4 5
>
> A Stack works in the opposite direction. In other words, it is a LIFO
> implementation (Last In First Out). So if you push the same information
> on to the Stack, you pop the information out in this order:
>
> 5 4 3 2 1
>
> This is useful in situations where you have to keep track of return
> adresses or hierarchy in configurations, etc.
err I know what a stack is and a queue ... however we are talking about a
*priority* queue here. Basically when you insert something into construct it
will be sorted based on its "priority" relative to other elements. If you
insert the values "5 4 3 2 1" it will act as a stack and if you insert "1
2 3 4 5" it will act as your FIFO queue. But I don't know why you are talking
about LIFO/FIFO as they have little relevence to priority based queues.
Another term for Priority Queues is "Heap"s. That may make things clearer.
> interface Queue {
> void push(Object obj);
> Object pop();
> Object peek();
> void clear();
> }
>
> interface PriorityQueue extends Queue {
> void control(Controller control);
> }
-1
Queue != PriorityQueue and PriorityQueue's traditional interface does not use
push() (for better or worse).
If anything I would rename PriorityQueue.pop() to remove() (as that is what
it really should be). However I chose to keep pop() as thats what they use in
textbooks.
>
> interface Controller {
> void setComparator(Comparator comp);
> int getNextObjectRef();
> void addObjectRef();
> }
seems far more complicated than is really necessary. I can't even fathom why
you would choose to use such an interface.
> If this is not the set of issues the current PriorityQueue was designed to
> handle, then it was probably poorly named....
PriorityQueue was designed as interface to a ... PriorityQueue. It is a very
text-book interface (and BinaryHeap is simplest text book impl about). If you
have issues on naming you should talk with the people who write Computer
Science textbooks ;)
--
Cheers,
Pete
*---------------------------------------------------------*
| Programming today is a race between software engineers |
| striving to build bigger and better idiot-proof |
| programs,and the universe trying to produce bigger and |
| better idiots. So far, the universe is winning. |
| - Richard Cook |
*---------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Excalibur] PriorityQueue & BinaryHeap proposal
Posted by Chad Stansbury <st...@earthlink.net>.
Berin -
PriorityQueue is the commonly used name for this type of functionality
(almost always being implemented using a BinaryHeap). You'll see this
terminology used everywhere (in the C++ STL, in the ObjectSpace JGL, and
most textbooks I've read). See
http://hissa.nist.gov/dads/HTML/priorityque.html.
You seem to be describing some sort of probablistic scheduler, which
involves a random component and is therefore not deterministic. A
PriorityQueue's behavior is deterministic given a certain set of data, and
is very important for this to be the case. Basically a PriorityQueue's
'top' method is always guaranteed to give you the 'max' value for that given
dataset (and if you use a BinaryHeap it will do so in O(1)).
Chad
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Wednesday, November 07, 2001 7:54 AM
Subject: Re: [Excalibur] PriorityQueue & BinaryHeap proposal
> Chad Stansbury wrote:
> >
> > Okay - here's the problem. The current BinaryHeap interface expects a
> > Comparable for it's public interface. In order to maintain backwards
> > compatibility I must either:
> >
> > 1. Add new public methods to the BinaryHeap class (e.g., insertObject,
> > peekObject, popObject) and change the insert, peek, and pop methods to
> > invoke these new methods, or
> > 2. I can create a new BinaryObjectHeap class and have the BinaryHeap
class
> > act as a wrapper class.
> >
> > I am also wondering how I would modify the PriorityQueue interface w/o
> > breaking backwards compatibility...
> >
> > Any suggestions would be appreciated.
>
> Peter, could you give a quick overview of how it is supposed to work?
> BTW, I don't like the insert() when you have pop() and peek(). If you
> are going to use Stack semantics and idioms, then use push() for the
> same purpose.
>
> If we are dealing with a queue, that is primarily a FIFO implementation
> (IOW merely a buffer). That means that if you push the following into
> the queue:
>
> 1 2 3 4 5
>
> You pop the information out of the queue in this order:
>
> 1 2 3 4 5
>
> A Stack works in the opposite direction. In other words, it is a LIFO
> implementation (Last In First Out). So if you push the same information
> on to the Stack, you pop the information out in this order:
>
> 5 4 3 2 1
>
> This is useful in situations where you have to keep track of return
> adresses or hierarchy in configurations, etc.
>
> The Priority Queue should be something like the original FIFO (First In
> First Out) buffer, BUT based on a Controller, the _proportion_ of
priorities
> popped out of the Queue depends on the Controller.
>
> For instance, if we have a group of objects that all implement a
getUserType()
> the Comparitor/Controller would test the User Type. The Controller
decides
> if the user is a PRIORITY_USER or a REGULAR_USER. The proportion of
PRIORITY_USER
> objects to REGULAR_USERs is 60% to 40% then the queue would pop them
accordingly.
>
> That means we should have a reqular Queue (FIFO buffer--can be used for
interface
> of persistent Queue to guarantee delivery of messages...). We should also
have
> a PriorityQueue with a Controller, and the Controller with a Comparator.
The
> Controller decides how the objects are moved through (i.e. proportions,
etc.)
> and the Comparator helps the Controller decide what the Objects are.
>
> With that goal in mind, that would change the interfaces to be like this:
>
> interface Queue {
> void push(Object obj);
> Object pop();
> Object peek();
> void clear();
> }
>
> interface PriorityQueue extends Queue {
> void control(Controller control);
> }
>
> interface Controller {
> void setComparator(Comparator comp);
> int getNextObjectRef();
> void addObjectRef();
> }
>
> The Comparator is in java.util.Comparator
>
>
> Not on the Controller, the API for the ObjectRefs can be played with, but
it is
> simply a way of letting the Controller know what is in the Queue, and a
way for
> the Queue to ask the controller what it next to come out.
>
>
> If this is not the set of issues the current PriorityQueue was designed to
handle,
> then it was probably poorly named....
>
>
> --
>
> "Those who would trade liberty for
> temporary security deserve neither"
> - Benjamin Franklin
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Excalibur] PriorityQueue & BinaryHeap proposal
Posted by Berin Loritsch <bl...@apache.org>.
Chad Stansbury wrote:
>
> Okay - here's the problem. The current BinaryHeap interface expects a
> Comparable for it's public interface. In order to maintain backwards
> compatibility I must either:
>
> 1. Add new public methods to the BinaryHeap class (e.g., insertObject,
> peekObject, popObject) and change the insert, peek, and pop methods to
> invoke these new methods, or
> 2. I can create a new BinaryObjectHeap class and have the BinaryHeap class
> act as a wrapper class.
>
> I am also wondering how I would modify the PriorityQueue interface w/o
> breaking backwards compatibility...
>
> Any suggestions would be appreciated.
Peter, could you give a quick overview of how it is supposed to work?
BTW, I don't like the insert() when you have pop() and peek(). If you
are going to use Stack semantics and idioms, then use push() for the
same purpose.
If we are dealing with a queue, that is primarily a FIFO implementation
(IOW merely a buffer). That means that if you push the following into
the queue:
1 2 3 4 5
You pop the information out of the queue in this order:
1 2 3 4 5
A Stack works in the opposite direction. In other words, it is a LIFO
implementation (Last In First Out). So if you push the same information
on to the Stack, you pop the information out in this order:
5 4 3 2 1
This is useful in situations where you have to keep track of return
adresses or hierarchy in configurations, etc.
The Priority Queue should be something like the original FIFO (First In
First Out) buffer, BUT based on a Controller, the _proportion_ of priorities
popped out of the Queue depends on the Controller.
For instance, if we have a group of objects that all implement a getUserType()
the Comparitor/Controller would test the User Type. The Controller decides
if the user is a PRIORITY_USER or a REGULAR_USER. The proportion of PRIORITY_USER
objects to REGULAR_USERs is 60% to 40% then the queue would pop them accordingly.
That means we should have a reqular Queue (FIFO buffer--can be used for interface
of persistent Queue to guarantee delivery of messages...). We should also have
a PriorityQueue with a Controller, and the Controller with a Comparator. The
Controller decides how the objects are moved through (i.e. proportions, etc.)
and the Comparator helps the Controller decide what the Objects are.
With that goal in mind, that would change the interfaces to be like this:
interface Queue {
void push(Object obj);
Object pop();
Object peek();
void clear();
}
interface PriorityQueue extends Queue {
void control(Controller control);
}
interface Controller {
void setComparator(Comparator comp);
int getNextObjectRef();
void addObjectRef();
}
The Comparator is in java.util.Comparator
Not on the Controller, the API for the ObjectRefs can be played with, but it is
simply a way of letting the Controller know what is in the Queue, and a way for
the Queue to ask the controller what it next to come out.
If this is not the set of issues the current PriorityQueue was designed to handle,
then it was probably poorly named....
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Excalibur] PriorityQueue & BinaryHeap proposal
Posted by Chad Stansbury <st...@earthlink.net>.
Okay - here's the problem. The current BinaryHeap interface expects a
Comparable for it's public interface. In order to maintain backwards
compatibility I must either:
1. Add new public methods to the BinaryHeap class (e.g., insertObject,
peekObject, popObject) and change the insert, peek, and pop methods to
invoke these new methods, or
2. I can create a new BinaryObjectHeap class and have the BinaryHeap class
act as a wrapper class.
I am also wondering how I would modify the PriorityQueue interface w/o
breaking backwards compatibility...
Any suggestions would be appreciated.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Wednesday, November 07, 2001 1:27 AM
Subject: Re: [Excalibur] PriorityQueue & BinaryHeap proposal
> On Wed, 7 Nov 2001 12:31, Chad Stansbury wrote:
> > Disclaimer: I'm new to this list so if I'm out of order, please feel
free
> > to say so...
>
> welcome.
>
> > I've tossed my own binary heap in favor of that provided by the
excalibur
> > lib. However, the 4.0 implementation restricts its usage to Comparable
> > objects. However, I need the ability to add Objects to the heap, and
> > specify a Comparator (ala Java collections). If no one objects, I will
add
> > this as a feature request and provide a patch to do so...
>
> sounds like a good idea.
>
> --
> Cheers,
>
> Pete
>
> -----------------------------------------------
> "Only two things are infinite, the universe and
> human stupidity, and I'm not sure about the
> former." -Albert Einstein
> -----------------------------------------------
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Excalibur] PriorityQueue & BinaryHeap proposal
Posted by Peter Donald <do...@apache.org>.
On Wed, 7 Nov 2001 12:31, Chad Stansbury wrote:
> Disclaimer: I'm new to this list so if I'm out of order, please feel free
> to say so...
welcome.
> I've tossed my own binary heap in favor of that provided by the excalibur
> lib. However, the 4.0 implementation restricts its usage to Comparable
> objects. However, I need the ability to add Objects to the heap, and
> specify a Comparator (ala Java collections). If no one objects, I will add
> this as a feature request and provide a patch to do so...
sounds like a good idea.
--
Cheers,
Pete
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Excalibur] PriorityQueue & BinaryHeap proposal
Posted by Chad Stansbury <st...@earthlink.net>.
Disclaimer: I'm new to this list so if I'm out of order, please feel free to
say so...
I've tossed my own binary heap in favor of that provided by the excalibur
lib. However, the 4.0 implementation restricts its usage to Comparable
objects. However, I need the ability to add Objects to the heap, and
specify a Comparator (ala Java collections). If no one objects, I will add
this as a feature request and provide a patch to do so...
Thanks in Advance,
Chad Stansbury
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] RT: ClassLoader hierarchy
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>It doesn't matter what you think. As soon as you do that you are no longer a
>spec compliant servlet container which could potentially be very bad. It
>would be worse if you hosted servlets like Cocoon that possibly used a
>different version of Avalon then your whole setup would not be able to run
>the Cocoon webapp. Bummer huh ?
>
OK, We're back to Promotion again then.
Sar conains two things 1) An spec level API, 2) Implementation of that
API plus the ability to launch sub-apps (mail lets, ftp lets etc).
(1) is contained entirely in a jar. In assembly.xml it's listed as :
<spec name="Sun-Servlet" version="2.3" jar="SAR-INF/spec/servlet.jar"/>
The phoenix class loader bumps these into the top level as a once off
transaction. These are not replaceable nor un-installable in a running
Phoenix.
I think you may be losing me. I know a fair bit about classloading but
not as much as you. If you have something that works then go for it
Peter, please try to fix Jesktop at the same time though.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] RT: ClassLoader hierarchy
Posted by Peter Donald <do...@apache.org>.
On Tue, 6 Nov 2001 23:21, Paul Hammant wrote:
> Peter
>
> Nice picture.
> But, What is JA doing to PCA and MA. It has two parents? Is that
> aggregation? I think you'll have problems trying to implement that. I
not really. As long as neither of them has the same classes in them.
> think that you are trying to make PCA invisible to MIA. Personally I
> think a minimal set of interfaces from PCA visible in terms of
> classloading to MIA would be acceptable.
It doesn't matter what you think. As soon as you do that you are no longer a
spec compliant servlet container which could potentially be very bad. It
would be worse if you hosted servlets like Cocoon that possibly used a
different version of Avalon then your whole setup would not be able to run
the Cocoon webapp. Bummer huh ?
> Nothing in terms of impl,
> nothing that could be instantiated. Nothing that could be serialized, etc.
>
> I'm all for a K/CAPI/HC separation, but think you don't have it right yet.
perhaps ;)
--
Cheers,
Pete
-------------------------------------------------------
"When we remember we are all mad, the mysteries of life
disappear and life stands explained." -Mark Twain
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] RT: ClassLoader hierarchy
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter
Nice picture.
But, What is JA doing to PCA and MA. It has two parents? Is that
aggregation? I think you'll have problems trying to implement that. I
think that you are trying to make PCA invisible to MIA. Personally I
think a minimal set of interfaces from PCA visible in terms of
classloading to MIA would be acceptable. Nothing in terms of impl,
nothing that could be instantiated. Nothing that could be serialized, etc.
I'm all for a K/CAPI/HC separation, but think you don't have it right yet.
- Paul
>>Sorry bro, but its kinda needed by my graphical mind.
>>
>
>I think best in pictures too ;)
>
>This is what I would like to do if I was going to be creating a Mailet engine.
>
>SC = System ClassLoader
>PCA = Phoenix Client API (phoenix-client.jar, avalon-framework.jar and also
>logkit and excalibur atm)
>PK = Phoenix Kernel/Container implementation
>MA = Mailet API
>JA = Mailet Engine AKA James
>MIA = Mailet Instances Application (set of mailets that form an application)
>
>
>And heres the pretty picture
>
> + <--- PK
> |
> |
>SC + <--- PCA + <--- + <--- JA
> | |
> | |
> + <--- MA + <--- +
> |
> |
> + <--- MIA
>
>
>Now using the following categorization scheme
>
>K = Container/Kernel
>CAPI = Client API
>HC = Hosted Component
>
>If you look at the "Phoenix" container level then the above would breakdown as
>
>K == PK
>CAPI == PCA
>HC == JA
>
>If you look at the "Mailet" container level then
>
>K == JA
>CAPI == MA
>HC == MIA
>
>Does that make it easier to grok ? ;)
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] RT: ClassLoader hierarchy
Posted by Peter Donald <do...@apache.org>.
On Tue, 6 Nov 2001 20:32, Paul Hammant wrote:
> Peter,
>
> >>For the sake of example - can we talk in terms of Jesktop (my bizarre
> >>GUI app hoster). Jesktop hosts GUI apps that need Swing, some
> >>DesktopKernel access and some "Frimble" access for abstraction of
> >>Windowlike containment.
> >
> >What we are talking about is the following. Almost all container based
> >systems define ClassLoader pattern using the following model
> >
> >System ClassLoader <--- Client API ClassLoader <--- + --- Container
> >
> >
> > + --- Component1
> >
> >
> > + --- Component2
> >
> >
> > + --- Component3
> >
> >
> > + --- Component4
>
> And in the context of my example, Container is Phoenix Impl & Excalibur
> etc, Component 1,2,3,4 are Jesktop JAMES, DB & Ftpserver?
The above diagram holds for any container style API. In the specific instance
of the Phoenix container then it would be as you indicated.
> The diagram above is too simple for me Peter. I think you hinting that
> this pattern exists many times in a tree. At top level for Phoenix, and
> lower down for Phoenix App.
Sorta. It happens in implementations of most Container style APIs. So if we
had an immaginary Meeplet API. It would probably require a separate
ClassLoader for the actual Meeplet API (ie client API), another ClassLoader
for the Meeplet Container and separate ClassLoaders for every Meeplet
application. Now replace Meeplet with Servlet or Mailet or Block or whatever
and the above sentence should still make sense.
Now I am saying that the pattern *should* exist at multiple places in a
Phoenix ClassLoader tree - unfortunately it doesn't atm.
The reason is that we still use hierarchial ClassLoader. Any application
hosted in Phoenix uses something like
System <--- Phoenix API <--- .sar ClassLoader
Currently "Phoenix API" includes excalibur, phoenix-client, framework and
logkit and anything in ${phoenix.home}/lib. In the future the "Phoenix API"
will be reduced to framework + phoenix-client.
Now if I wanted to implement a Servlet engine then presumably the .sar
ClassLoader would be the "Servlet Container" ClassLoader for the
servlet engine. Currently it is not possible to specify the "Servlet API"
ClassLoader that just contains servlet.jar and is a parent of the
.sar/"Servlet Container" ClassLoader. However this is reqiuired by the
servlet spec.
> In places. But I really need to see a big picture tree with named nodes.
If only there was a web-enabled whiteboard that we could use ;)
> Sorry bro, but its kinda needed by my graphical mind.
I think best in pictures too ;)
This is what I would like to do if I was going to be creating a Mailet engine.
SC = System ClassLoader
PCA = Phoenix Client API (phoenix-client.jar, avalon-framework.jar and also
logkit and excalibur atm)
PK = Phoenix Kernel/Container implementation
MA = Mailet API
JA = Mailet Engine AKA James
MIA = Mailet Instances Application (set of mailets that form an application)
And heres the pretty picture
+ <--- PK
|
|
SC + <--- PCA + <--- + <--- JA
| |
| |
+ <--- MA + <--- +
|
|
+ <--- MIA
Now using the following categorization scheme
K = Container/Kernel
CAPI = Client API
HC = Hosted Component
If you look at the "Phoenix" container level then the above would breakdown as
K == PK
CAPI == PCA
HC == JA
If you look at the "Mailet" container level then
K == JA
CAPI == MA
HC == MIA
Does that make it easier to grok ? ;)
--
Cheers,
Pete
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] RT: ClassLoader hierarchy
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>For the sake of example - can we talk in terms of Jesktop (my bizarre
>>GUI app hoster). Jesktop hosts GUI apps that need Swing, some
>>DesktopKernel access and some "Frimble" access for abstraction of
>>Windowlike containment.
>>
>
>What we are talking about is the following. Almost all container based
>systems define ClassLoader pattern using the following model
>
>System ClassLoader <--- Client API ClassLoader <--- + --- Container
> |
> |
> + --- Component1
> |
> |
> + --- Component2
> |
> |
> + --- Component3
> |
> |
> + --- Component4
>
>
And in the context of my example, Container is Phoenix Impl & Excalibur
etc, Component 1,2,3,4 are Jesktop JAMES, DB & Ftpserver?
The diagram above is too simple for me Peter. I think you hinting that
this pattern exists many times in a tree. At top level for Phoenix, and
lower down for Phoenix App.
>The client API contains the essential interfaces needed for the components to
>talk to the Container. In the case of servlets, servlet.jar would be in
>client API ClassLoader, catalina.jar in container classloader, and
>turbine.jar, cocoon.jar, velocity would each be in separate classloaders.
>
>Phoenix itself follows above model. Eventually the client API will be made up
>of just the phoenix-client.jar and avalon-framework.jar libraries. The
>container is in separate ClassLoader from all the different .sar files.
>
>It has been a while since I looked at jesktop but from what I recall the
>Client API ClassLoader would contain classes for Frimble, DesktopAware,
>ConfigletAware etc (or whatever they are called).
>
>However the problem arises because Phoenix follows this model. Usually you
>use phoenix to build the "container" part of another application (be it
>James: the Mailet container, Jesktop the ...frimble???... container). Thus we
>need some way to inject the Client API ClassLoader for hosted apps into the
>equation so that it is a parent ClassLoader of the ClassLoader via which
>blocks are loaded.
>
Small point: Jesktop's hosted client API is in in simplest form the who
of Swing. Some Jesktop apps require access to a Frimble Factory.
>That any clearer ? ;)
>
In places. But I really need to see a big picture tree with named nodes.
System Class Loader
Phoenix Client API (phoenix-client.jar and avalon-framework.jar) (PCA)
Phoenix Impl (PI)
Phoenix Hosted App Client API (PHA CAPI)
Phoenix Hosted App Impl (PHA I)
Phoenix Hosted App Hosted App (PHA A1, PHA A2 etc)
Sorry bro, but its kinda needed by my graphical mind.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] RT: ClassLoader hierarchy
Posted by Peter Donald <do...@apache.org>.
On Tue, 6 Nov 2001 11:30, Paul Hammant wrote:
> Peter
>
> I'll reply to other points more fully in the morning, but for now (given
> this paragraph is what I think is your central wish)...
;)
> >Essentially what I want to be able to do is to create a
> >servlet/mailet/whateverlet server that abides by all the rules but does
> > not need to resort to ugly classloader hacks to get working. Not sure -
> > may need more gestation time ;)
>
> For the sake of example - can we talk in terms of Jesktop (my bizarre
> GUI app hoster). Jesktop hosts GUI apps that need Swing, some
> DesktopKernel access and some "Frimble" access for abstraction of
> Windowlike containment.
What we are talking about is the following. Almost all container based
systems define ClassLoader pattern using the following model
System ClassLoader <--- Client API ClassLoader <--- + --- Container
|
|
+ --- Component1
|
|
+ --- Component2
|
|
+ --- Component3
|
|
+ --- Component4
The client API contains the essential interfaces needed for the components to
talk to the Container. In the case of servlets, servlet.jar would be in
client API ClassLoader, catalina.jar in container classloader, and
turbine.jar, cocoon.jar, velocity would each be in separate classloaders.
Phoenix itself follows above model. Eventually the client API will be made up
of just the phoenix-client.jar and avalon-framework.jar libraries. The
container is in separate ClassLoader from all the different .sar files.
It has been a while since I looked at jesktop but from what I recall the
Client API ClassLoader would contain classes for Frimble, DesktopAware,
ConfigletAware etc (or whatever they are called).
However the problem arises because Phoenix follows this model. Usually you
use phoenix to build the "container" part of another application (be it
James: the Mailet container, Jesktop the ...frimble???... container). Thus we
need some way to inject the Client API ClassLoader for hosted apps into the
equation so that it is a parent ClassLoader of the ClassLoader via which
blocks are loaded.
That any clearer ? ;)
--
Cheers,
Pete
------------------------------------
The two secrets to success:
1- Don't tell anyone everything.
------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] RT: ClassLoader hierarchy
Posted by Paul Hammant <Pa...@yahoo.com>.
Ulrich,
>>For the sake of example - can we talk in terms of Jesktop (my bizarre
>>GUI app hoster). Jesktop hosts GUI apps that need Swing, some
>>DesktopKernel access and some "Frimble" access for abstraction of
>>Windowlike containment.
>>
>
>Sorry for this potentially dumb question: is Jesktop the way to
>integrate GUI apps into an Avalon setup? We have several GUI apps, but
>they are running seperately from our Avalon-based backend services.
>
It's a way. Jesktop is controvercial. Very in fact. With Rana's
FtpServer we have an admin console that works in two ways : 1)
standalone executable jar 2) Jesktop dependant app. Both are the same
jar, and use RMI to interoperate with the server. Jesktop supports hot
app installation and de-instalation, but is not ideal for a Phoenix
instance you intend to run for days un-interrupted. For me its more
about a PDA OS.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] RT: ClassLoader hierarchy
Posted by Ulrich Mayring <ul...@denic.de>.
Paul Hammant wrote:
>
> For the sake of example - can we talk in terms of Jesktop (my bizarre
> GUI app hoster). Jesktop hosts GUI apps that need Swing, some
> DesktopKernel access and some "Frimble" access for abstraction of
> Windowlike containment.
Sorry for this potentially dumb question: is Jesktop the way to
integrate GUI apps into an Avalon setup? We have several GUI apps, but
they are running seperately from our Avalon-based backend services.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] RT: ClassLoader hierarchy
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter
I'll reply to other points more fully in the morning, but for now (given
this paragraph is what I think is your central wish)...
>Essentially what I want to be able to do is to create a
>servlet/mailet/whateverlet server that abides by all the rules but does not
>need to resort to ugly classloader hacks to get working. Not sure - may need
>more gestation time ;)
>
For the sake of example - can we talk in terms of Jesktop (my bizarre
GUI app hoster). Jesktop hosts GUI apps that need Swing, some
DesktopKernel access and some "Frimble" access for abstraction of
Windowlike containment.
To all intents and purposes, classloaders look like this at present
SysClassLoader <---- Phoenix stuff and Jesktop's jars <---------
BeanShell (hosted app)
|
|----- TextPad
|
|-----
SwingSet Demo
Jesktop and Phoenix should have it's kernel operations running in a
different *visible* classloader to the hosted applications. Like so:
|-----
Jesktop Impl
|
|-----
Phoenix Impl + Excalibur etc.
|
SysClassLoader <---- Phoenix & Jesktop API plus nano-Kernel <---------
BeanShell (hosted app)
|
|----- TextPad
|
|-----
SwingSet Demo
OK, because at present, Jesktop is hosting applications just *fine*, and
security is acheived through proxies and access modifers (not ideal).
Is that what we're talking about?
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] RT: ClassLoader hierarchy
Posted by Peter Donald <do...@apache.org>.
On Tue, 6 Nov 2001 03:55, Paul Hammant wrote:
> Peter,
>
> Finally! This is what you wanted considered conversation on?
yep ;)
> There are so many ways to answer this. So many choices that mean good
> and bad news for different parties.
>
> 1) WAR should not not able to see or instantiate excalibur (etc) classes
> by default. It's a security issue and I think everyone agrees that.
> Given that Jo! (or Tomcat n years from now) could host Cocoon that
> needs Excalibur (etc) then WAR files as at present must be able to bring
> their own jars that clash with dopplegangers elsewhee in the VM
> (different branch).
yep. Once the deprecated methods are removed from BlockContext this should be
possible.
> 2) What can the IoC pattern do for us here? Could a Phoenix app that
> needs Excalibur classes be given a handle to a suitable classloader by
> asking for it through ComponentManager? This sounds great but I don't
> think it can work at all. All dependancies are resolved at load time
> via a zillion findClass() calls. If one is missing (interface or class)
> it will barf in a very unhelpful way.
I would have any jars that need it declare a dependency on Excalibur jar via
standard 1.3 Extensions mechanism.
> 5) Another IoC solution. Could Phoenix apps be able to see everything
> as at present (in CL terms). Could they also go back to some
> componentManager or BlockContext supplied thing and ask for a naked hook
> to the system class loader (is that not called primordial now?) I.e
> Phoenix design recognises that Phoenix hosted apps may want to host
> multiple sub apps that are Pheonix/Avalon/Excalibur/Logkit unaware.
> Either the block can ask for a single CL that has a parent of the
> primordial, and with that itself makes multiple classloaders for it's
> hosted applications. It is not so hard for an app to do this....
> Jesktop does. Or it can be more of a factory and generate new ones on
> request. I'd really prefer the former or a facility for both.
System classloader can still be grabbed from
ClassLoader.getSystemClassLoader(). However the real issue here is for
something like mailet/servlet APIs.
The blocks have to have the Servlet/Mailet interfaces in their classloader.
However the specs dictate that an actual servlet must not be able to see the
container implementation classes.
Hence the servlet classes have to be in a parent classloader to the one in
which the blocks are loaded from and the contained servlets etc have have
their parent classloader set to that classloader aswell.
> 6) Bridging. We're not addressing that in this thread huh? When I get
> more used to BCEL I think I might be able to make the perfect version
> tolerate proxy style bridge for SAR to SAR connecting.
yep. We may be able to get away with jdk1.3 proxies unless speed becomes an
issue.
> 7) Hierarchcy in server.xml. Relaing to (5) above. I think this should
> not be so statically defined.
Can you say where you would want it to be dynamic. I haven't seen any
applications that would have a dynamic CL.
> If it is anywhere it is in assembly.xml
> and a component that can be delivered through compose(..).
I disagree. Assembly.xml is for configuring peer relationships between
components. Server.xml is for setting up the "environment" in which the
application executes.
> In summary, I think we could have a service called :
>
> NonPhoenixClassLoaderEnvironment {
> ClassLoader getNonPhoenixClassLoader();
> }
>
> Phoenix could provide a default implementation of that but other coders
> could provide alternatives (possibly even chained ones).
Services wont do IMO because the blocks them selves need to be loaded from
these ClassLoaders in very specific hierarchies.
Essentially what I want to be able to do is to create a
servlet/mailet/whateverlet server that abides by all the rules but does not
need to resort to ugly classloader hacks to get working. Not sure - may need
more gestation time ;)
--
Cheers,
Pete
---------------------------------------------------
"Therefore it can be said that victorious warriors
win first, and then go to battle, while defeated
warriors go to battle first, and then seek to win."
- Sun Tzu, the Art Of War
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [phoenix] RT: ClassLoader hierarchy
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
Finally! This is what you wanted considered conversation on?
There are so many ways to answer this. So many choices that mean good
and bad news for different parties.
1) WAR should not not able to see or instantiate excalibur (etc) classes
by default. It's a security issue and I think everyone agrees that.
Given that Jo! (or Tomcat n years from now) could host Cocoon that
needs Excalibur (etc) then WAR files as at present must be able to bring
their own jars that clash with dopplegangers elsewhee in the VM
(different branch).
2) What can the IoC pattern do for us here? Could a Phoenix app that
needs Excalibur classes be given a handle to a suitable classloader by
asking for it through ComponentManager? This sounds great but I don't
think it can work at all. All dependancies are resolved at load time
via a zillion findClass() calls. If one is missing (interface or class)
it will barf in a very unhelpful way.
3) Home truths. Applications (any) that make an assumption about the
parent classloader (being the system one) suck. That is one of three
issues with Tomcat running on Phoenix at the present (look back in this
list for "StandardClassLoader"). This is a bit of a crux and I'm
skimming over it.
4) Aggregation Classloader. Hmmm, not sure that is right anymore.
5) Another IoC solution. Could Phoenix apps be able to see everything
as at present (in CL terms). Could they also go back to some
componentManager or BlockContext supplied thing and ask for a naked hook
to the system class loader (is that not called primordial now?) I.e
Phoenix design recognises that Phoenix hosted apps may want to host
multiple sub apps that are Pheonix/Avalon/Excalibur/Logkit unaware.
Either the block can ask for a single CL that has a parent of the
primordial, and with that itself makes multiple classloaders for it's
hosted applications. It is not so hard for an app to do this....
Jesktop does. Or it can be more of a factory and generate new ones on
request. I'd really prefer the former or a facility for both.
6) Bridging. We're not addressing that in this thread huh? When I get
more used to BCEL I think I might be able to make the perfect version
tolerate proxy style bridge for SAR to SAR connecting.
7) Hierarchcy in server.xml. Relaing to (5) above. I think this should
not be so statically defined. If it is anywhere it is in assembly.xml
and a component that can be delivered through compose(..).
In summary, I think we could have a service called :
NonPhoenixClassLoaderEnvironment {
ClassLoader getNonPhoenixClassLoader();
}
Phoenix could provide a default implementation of that but other coders
could provide alternatives (possibly even chained ones).
Regards,
- Paul H
>Currently Phoenix has a relatively simple ClassLoader mechanism. It has the
>following layout
>
>System ClassLoader <--- Kernel ClassLoader
> <--- Application ClassLoader (s)
>
>The System ClassLoader includes avalon-framework.jar, phoenix-client.jar and
>any other jars included in ${phoenix.home}/lib/ (currently xerces and
>excalibur are required).
>
>This works great if you are just writing normal server applications. The
>problem arises when you try to write applications that will in turn host
>other components. For instance a servlet container requires a very specific
>ClassLoader hierarchy for it to work. For instance the base ClassLoader is
>meant to only contain a handful of files (including servlet.jar and various
>other "common" jar files).
>
>However we can only partially implement that at the moment by placing the
>library files into ${phoenix.home}/lib however even that case we can not
>remove avalon-framework.jar, phoenix-client.jar, etc as they are required so
>that Application and Kernel can talk. So in reality it would be difficult to
>implement a fully compliant EJB, Servlet etc application without writing
>another ClassLoader (that didn't delegate to top of ClassLoader hierarchy). A
>few servlet engines already do this but I would prefer if it was easier in
>Phoenix.
>
>My initial thoughts were to create something like
>
>System ClassLoader <--- Common ClassLoader <--- Kernel ClassLoader
> <--- Application ClassLoader (s)
>
>where Common ClassLoader contains avalon-framework.jar, phoenix-client.jar,
>excalibur etc.
>
>That way the Application could create a ClassLoader that delegated to System
>ClassLoader but wasn't pollutted by Avalon specific jars.
>
>
>However then I thought that this could be bad because some Applications
>require that extra elements be added to Common ClassLoader that this wouldn't
>work. ie A servlet container would still require that servlet.jar be loaded
>by Application ClassLoader (or one of it's parents) and thus you would still
>have to stuff the servlet.jar into System ClassLoader for this to work. And
>this is not a good thing IMHO.
>
>So then I got to thinking about something Paul said. Maybe we could declare
>ClassLoader hierarhy in the server.xml. However because a hierarchial
>ClassLoader still wouldn't work we would have to have an Aggregator
>ClassLoader that aggregated several ClassLoaders together so we could do
>something like
>
>System ClassLoader <--- Common ClassLoader <--- Kernel ClassLoader
> <---|
> | Application ClassLoader (s)
> Servlet ClassLoader <---|
>
>This way we could get access to the unpolluted ClassLoader to work as base
>ClassLoader for web application. This would be the same ClassLoader that the
>Application used to load the servlet interfaces and thus it would be easy to
>provide implementation in Application space.
>
>As a matter of fact this could be extended so that an arbitrary number of
>ClassLoaders could be aggregated for application. However this assumes that
>each ClassLoader aggregated contains separate namespace. ie The same Class
>can not be available in multiple ClassLoaders for this to work.
>
>To support all this we would need to add an extra method to BlockContext to
>get named ClassLoader and we would have to enhance server.xml to allow
>ClassLoader hierarchys to be configured in it (not sure on format).
>
>Thoughts?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>