You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by wa...@post.ch on 2004/07/12 15:59:34 UTC
leveraging Orderer
Removing the dependency on Werkz (see issue HIVEMIND-6) mainly
encompassed rewriting oah.order.Orderer. While refactoring this class I
noticed that it is not related to (i.e. doesn't use) the oah.Orderable
interface. I think this could be redeemed by a further refactoring.
Also I was thinking if it would make sense to leverage Orderer by
providing it as a HiveMind service.
Orderer is currently used to order two kinds of objects in HiveMind:
SymbolSourceContribution and ServiceInterceptorContribution objects.
The former is a class implementing Orderable and the latter is an
interface *not* extending Orderable.
The interface of the Orderer class is given by the methods:
public void add(Object object, String name, String prereqs,
String postreqs);
public List getOrderedObjects();
This means a client can't directly pass Orderable instances to the
Orderer. Instead the details of the object is passed and Orderer then
uses a local object to encapsulate these details again.
IMO it would thus make sense to move the Orderable interface into the
oah.order package and use it as the single parameter to the add method
of Orderer. I.e.
public void add(Orderable object);
A benefit from this refactoring would be that the "intermediate"
non-public class ObjectOrdering could be dropped. Of course the client
ordering ServiceInterceptorContribution instances would have to use an
adapter (e.g. an anonymous class) to be compatible with the new
interface.
Splitting Orderer into Orderer and OrdererImpl would let us publish it
as a service.
Thoughts?
Cheers,
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: leveraging Orderer
Posted by Howard Lewis Ship <hl...@gmail.com>.
This kind of ordering is based on dependency lists. Each object has a
name, a list of its prerequisistes (objects that must come before it
in the list) and postrequisistes (objects that must come after).
This is used, for example, to set the order in which interceptors are
applied to a service.
HiveMind used to rely on a numeric order, which was less than ideal.
This approach is more flexible, if somewhat more verbose, since
contributions can (it being HiveMind) come from all sorts of
unexpected locations.
On Mon, 12 Jul 2004 10:12:34 -0400, James Carman
<ja...@carmanconsulting.com> wrote:
> I'm not exactly familiar with the internal workings here, but from the names
> of these classes and what you are saying, are we just trying to order some
> objects in a collection of some sort? And, this collection needs to be able
> to maintain the proper ordering as "things" are inserted into it? Then, why
> can't you use a java.util.SortedSet along with some Comparator
> implementations? Is there some weird requirement here that I'm missing?
>
>
>
> -----Original Message-----
> From: wannhedenk@post.ch [mailto:wannhedenk@post.ch]
> Sent: Monday, July 12, 2004 10:00 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: leveraging Orderer
>
> Removing the dependency on Werkz (see issue HIVEMIND-6) mainly
> encompassed rewriting oah.order.Orderer. While refactoring this class I
> noticed that it is not related to (i.e. doesn't use) the oah.Orderable
> interface. I think this could be redeemed by a further refactoring.
> Also I was thinking if it would make sense to leverage Orderer by
> providing it as a HiveMind service.
>
> Orderer is currently used to order two kinds of objects in HiveMind:
> SymbolSourceContribution and ServiceInterceptorContribution objects.
> The former is a class implementing Orderable and the latter is an
> interface *not* extending Orderable.
>
> The interface of the Orderer class is given by the methods:
>
> public void add(Object object, String name, String prereqs,
> String postreqs);
> public List getOrderedObjects();
>
> This means a client can't directly pass Orderable instances to the
> Orderer. Instead the details of the object is passed and Orderer then
> uses a local object to encapsulate these details again.
>
> IMO it would thus make sense to move the Orderable interface into the
> oah.order package and use it as the single parameter to the add method
> of Orderer. I.e.
>
> public void add(Orderable object);
>
> A benefit from this refactoring would be that the "intermediate"
> non-public class ObjectOrdering could be dropped. Of course the client
> ordering ServiceInterceptorContribution instances would have to use an
> adapter (e.g. an anonymous class) to be compatible with the new
> interface.
>
> Splitting Orderer into Orderer and OrdererImpl would let us publish it
> as a service.
>
> Thoughts?
>
> Cheers,
>
> --knut
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: leveraging Orderer
Posted by James Carman <ja...@carmanconsulting.com>.
I'm not exactly familiar with the internal workings here, but from the names
of these classes and what you are saying, are we just trying to order some
objects in a collection of some sort? And, this collection needs to be able
to maintain the proper ordering as "things" are inserted into it? Then, why
can't you use a java.util.SortedSet along with some Comparator
implementations? Is there some weird requirement here that I'm missing?
-----Original Message-----
From: wannhedenk@post.ch [mailto:wannhedenk@post.ch]
Sent: Monday, July 12, 2004 10:00 AM
To: hivemind-dev@jakarta.apache.org
Subject: leveraging Orderer
Removing the dependency on Werkz (see issue HIVEMIND-6) mainly
encompassed rewriting oah.order.Orderer. While refactoring this class I
noticed that it is not related to (i.e. doesn't use) the oah.Orderable
interface. I think this could be redeemed by a further refactoring.
Also I was thinking if it would make sense to leverage Orderer by
providing it as a HiveMind service.
Orderer is currently used to order two kinds of objects in HiveMind:
SymbolSourceContribution and ServiceInterceptorContribution objects.
The former is a class implementing Orderable and the latter is an
interface *not* extending Orderable.
The interface of the Orderer class is given by the methods:
public void add(Object object, String name, String prereqs,
String postreqs);
public List getOrderedObjects();
This means a client can't directly pass Orderable instances to the
Orderer. Instead the details of the object is passed and Orderer then
uses a local object to encapsulate these details again.
IMO it would thus make sense to move the Orderable interface into the
oah.order package and use it as the single parameter to the add method
of Orderer. I.e.
public void add(Orderable object);
A benefit from this refactoring would be that the "intermediate"
non-public class ObjectOrdering could be dropped. Of course the client
ordering ServiceInterceptorContribution instances would have to use an
adapter (e.g. an anonymous class) to be compatible with the new
interface.
Splitting Orderer into Orderer and OrdererImpl would let us publish it
as a service.
Thoughts?
Cheers,
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org