You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Jonathan Hawkes <jh...@adsnm.com> on 2003/11/18 15:32:59 UTC
[proposal] IoC type 3.14 extension to the Avalon Framework
Greetings citizens of Avalon!
My name is Jonathan Hawkes. I'm an Avalon enthusiast, an Avalon Developers' List lurker, and a brand-spanking new IoC type 3 convert.
There has been a lot of discussion on IoC types recently, and I am grateful because it has stimulated my thinking and hopefully sparked a couple of decent (though I dare not pretend original) ideas.
I just finished reading Berin's note concerning IoC types and a super-duper container (presumably Merlin) that would support as many types as possible. I also just combed over some of the docs for PicoContainer; and like Avalon, some of the concepts tickled my fancy. Immediately, I began to see advantages of each discipline and wondered if the two schools couldn't be reconciled somewhat.
Consider the following...
public interface HelloService {
void printHelloWorld() throws IOException;
}
public class HelloServiceFrameworkImpl
implements HelloService,
LogEnabled,
Serviceable,
Configurable,
Initializable,
Disposable {
private Logger logger;
private ServiceManager sm;
private Configuration printerConfig;
private PrinterSelector printerSelector;
private Printer printer;
public void enableLogging(Logger logger) {
this.logger = logger;
logger.info("Logger acquired");
}
public void service(ServiceManager sm)
throws ServiceException {
this.sm = sm;
printerSelector = sm.lookup(PrinterSelector.ROLE);
logger.info("PrinterSelector acquired");
}
public void configure(Configuration config)
throws ConfigurationException {
printerConfig = config;
logger.info("Configuration acquired");
}
public void initialize()
throws Exception {
printer = (Printer) printerSelector.select(config);
logger.info("Printer selected");
}
public void printHelloWorld()
throws IOException {
printer.print("Hello world!");
}
public void dispose() {
printerSelector.release(printer);
sm.release(printerSelector);
}
}
public class HelloServiceIoC3Impl
implements HelloService {
Printer printer;
public HelloServiceImpl(Logger logger,
PrinterSelector printerSelector,
Configuration printerConfig) {
logger.info("Acquired Logger, PrinterSelector, Configuration");
printer = (Printer) printerSelector.select(printerConfig);
}
public void printHelloWorld()
throws IOException {
printer.print("Hello world!");
}
}
I hope that the example needs little explanation (it is a bit contrived, I admit). HelloServiceFrameworkImpl would be the current Avalon framework implementation. HelloServiceIoC3Impl would be a variant of an IoC type 3 implementation.
In the IoC type 3 variant, the constructor serves several functions.
1. It automatically publishes dependencies
2. It automatically resolves dependencies
3. It replaces LogEnabled, Serviceable, Configurable, and Initializable
Now, just a couple of days ago, I didn't think that this was such a good idea. For one, with no ServiceManager, there is also no ServiceManager.release(). Also, what if I want to resolve components dynamically?
What I am proposing is an Avalon/IoC type 3 fusion. Call it IoC type 3.14. :)
All Avalon framework containers must be able to assign a Logger, a ServiceManager, and a Configuration to a component that implements LogEnabled, Serviceable, and Configurable respectively. An IoC type 3 component in Avalon would be able to receive these entities as well. But it could receive a Logger through its constructor instead of the LogEnabled interface. And if a component so declared, it could receive a ServiceManager through its constructor, allowing the component to dynamically resolve dependencies. Configuration and Context objects could be resolved as well.
I call my proposal IoC type 3.14 because it places further restrictions on IoC type 3. For one, the constructor MAY NOT declare any implementation classes. Each argument in the constructor should satisfy a role and represent a component (or service) interface. Multiple arguments fulfilling the same role are not allowed. Essentially, this would make the two following implementations identical.
public class Impl1
implements Serviceable {
private Service1 service1;
private Service2 service2;
public void service(ServiceManager sm)
throws ServiceException {
service1 = (Service1) sm.lookup(Service1.ROLE);
service2 = (Service2) sm.lookup(Service2.ROLE);
}
}
public class Impl2 {
private Service1 service1;
private Service2 service2;
public Impl2(Service1 service1, Service2 service2) {
this.service1 = service1;
this.service2 = service2;
}
}
NOTE: This should also be acceptable
public class Impl3 {
private Service1 service1;
private Service2 service2;
private ServiceManager sm;
public Impl3(Service1 service1, Service2 service2,
ServiceManager sm) {
this.service1 = service1;
this.service2 = service2;
this.sm = sm;
}
}
NOTE: And this too
public class Impl4 {
private Service1 service1;
private Service2 service2;
public Impl4(ServiceManager sm)
throws ServiceException {
service1 = (Service1) sm.lookup(Service1.ROLE);
service2 = (Service2) sm.lookup(Service2.ROLE);
}
}
Containers must be able to resolve all dependencies in the constructor's argument set (which must be a true set) or otherwise must deal with the failure as if an exception was thrown from the Serviceable.service() method. Furthermore, the component constructor should not have to deal with null references. Any null reference propagated to the constructor is considered a container implementation error. The order in which arguments (roles) are defined in the constructor is unimportant. Strictly conforming components have a sole constructor.
A type 3.14 IoC component must not expect any concrete classes. This allows the container to switch out service implementations at will.
Services obtained through the component constructor cannot be released in the usual fashion. However, creative solutions are possible. A service implementation could be forced to be thread-safe by having the component interface extend ThreadSafe... Or a service that would be potentially applicable to pooling might define its own release() method to release the component reference... Or for component X that is pooled, an XPool service might be established. These are not proposed best-practices, just some possible ideas.
Okay, to sum up, I propose a constriction of IoC 3 that will be termed IoC 3.14. The constructor of an IoC type 3.14 component demands only interface parameter types (and each one unique). It may throw an exception of any type.
Furthermore, I propose expanding the Avalon framework specification to support IoC 3.14. An Avalon compatible IoC 3.14 component can expect the container to always to able to resolve a Logger, Context, ServiceManager, and Configuration. This proposal suggests no alternative for lifecycle methods. All current Avalon framework interfaces should continue to be supported in addition to the IoC 3.14 specification. Existing framework interfaces, if used in conjunction with this proposal, should have an overriding event.
If you've made it this far, congratulations! It's late and I'm writing and brainstorming at the same time. Your comments, criticisms, suggestions are most welcome.
Thanks!
Jonathan Hawkes
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 19 November 2003 23:05, Jonathan Hawkes wrote:
> I'll take a look at JingDAO. I just checked out Magic in the Avalon
> sandbox, though It only has one class right now (Avalon2PicoAdapter.java),
> but it effectively proxies Avalon Framework calls to an IoC type 3
> component. It actually (almost) conforms to the Avalon PI proposal! Do
> great minds think alike or what? :)
Apparently less than great minds do that as well, he he ;o)
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Jonathan Hawkes <jh...@adsnm.com>.
----- Original Message -----
From: "J Aaron Farr" <fa...@apache.org>
To: "Avalon Developers List" <de...@avalon.apache.org>
Sent: Tuesday, November 18, 2003 2:49 PM
Subject: Re: [proposal] IoC type 3.14 extension to the Avalon Framework
> Sorry to jump into the thread so late, but I wanted to add a couple of
> thoughts:
>
> - I like the idea of 'Avalon PI' -- I think it's something we should
explore.
> As Berin mentioned in another thread, we could do this in Fortress without
too
> much trouble. We could also do it in Merlin, but last I looked at that
> section of code it wasn't very flexible (could be wrong now though).
>
> - A couple of people have already worked on the bridge between Avalon and
Pico
> components:
> Leo Simons in our very own Avalon Sandbox: avalon-sandbox/magic
> Plug for my JingDAO framework which uses Picocontainer to handle Avalon,
> Pico, and java bean components: http://jingdao.sf.net
> I'm sure there are others.
I'll take a look at JingDAO. I just checked out Magic in the Avalon
sandbox, though It only has one class right now (Avalon2PicoAdapter.java),
but it effectively proxies Avalon Framework calls to an IoC type 3
component. It actually (almost) conforms to the Avalon PI proposal! Do
great minds think alike or what? :)
>
> - We need JIRA, or at least a roadmap, in order to keep these proposals
from
> getting lost while still actually releasing products.
I couldn't agree more.
>
> ---
> jaaron <http://jadetower.org>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by J Aaron Farr <fa...@apache.org>.
Sorry to jump into the thread so late, but I wanted to add a couple of
thoughts:
- I like the idea of 'Avalon PI' -- I think it's something we should explore.
As Berin mentioned in another thread, we could do this in Fortress without too
much trouble. We could also do it in Merlin, but last I looked at that
section of code it wasn't very flexible (could be wrong now though).
- A couple of people have already worked on the bridge between Avalon and Pico
components:
Leo Simons in our very own Avalon Sandbox: avalon-sandbox/magic
Plug for my JingDAO framework which uses Picocontainer to handle Avalon,
Pico, and java bean components: http://jingdao.sf.net
I'm sure there are others.
- We need JIRA, or at least a roadmap, in order to keep these proposals from
getting lost while still actually releasing products. We need to get a solid
list of critial features for Merlin 3.0, 3.1, ... and Fortress 1.1, 1.2, etc.
We also need, as Leo pointed out, better use of CVS in order to realistically
work on some of these ideas. I say this because I would really like to see
this proposal and the many other great ideas brought up in the mailing list
reach fruition.
---
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Jonathan Hawkes <jh...@adsnm.com>.
And that's one of the advantages to Avalon PI. An Avalon PI compliant
container would have to be able to furnish a Logger, ServiceManager, etc.
But there is no such component requirement to ask for them. Conceptually,
an Avalon PI component that did not make use of Avalon Framework specific
interfaces could be dropped into Pico, and a Pico component that followed
the additional restrictions specified by Avalon PI could be dropped into an
Avalon PI container.
----- Original Message -----
From: "Eric Pugh" <ep...@upstate.com>
To: "'Avalon Developers List'" <de...@avalon.apache.org>
Sent: Tuesday, November 18, 2003 9:18 AM
Subject: RE: [proposal] IoC type 3.14 extension to the Avalon Framework
> I gotta says, the requirement to use other people's interfaces is a huge
> roadblock.. I don't wanna (said like a child :-)) use other peoples
> interfaces, I want to use mine! Hence the appeal of the constructor
> approach or the very introspection/reflection approaches...
>
> Eric
>
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Tuesday, November 18, 2003 4:21 PM
> > To: Avalon Developers List
> > Subject: Re: [proposal] IoC type 3.14 extension to the Avalon
> > Framework
> >
> >
> > Ulrich Mayring wrote:
> >
> > > Jonathan Hawkes wrote:
> > >
> > >> Did you even read the rest of the message? I'm not
> > pushing a type 3
> > >> replacement. You could continue to write components as
> > you wish. Please
> > >> see the original message and do me the courtesy of reading
> > it. I'm not
> > >> trying to spark an argument over which way is best.
> > >
> > >
> > > Sorry to be unclear, I'll try again. I wanted to communicate that I
> > > don't see the need for type 3 and therefore your proposal.
> > This does not
> > > mean that I would -1 it, if I were a committer. It just
> > means that I
> > > don't need it and haven't understood why others do :)
> >
> > Easy:
> >
> > There are developers who simply refuse to use other people's
> > interfaces
> > (shocking but true), and to support folks who suffer from NIH syndrome
> > (Not Invented Here), the constructor mechanism what was come up from.
> >
> > It has everything to do with development style, and what some
> > developers
> > think is easy others think is a pain.
> >
> > That's why I really don't care what method is used to
> > accomplish IoC as
> > long as it is supported.
> >
> >
> > --
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety
> > deserve neither liberty nor safety."
> > - Benjamin Franklin
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> > For additional commands, e-mail: dev-help@avalon.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Eric Pugh <ep...@upstate.com>.
I gotta says, the requirement to use other people's interfaces is a huge
roadblock.. I don't wanna (said like a child :-)) use other peoples
interfaces, I want to use mine! Hence the appeal of the constructor
approach or the very introspection/reflection approaches...
Eric
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Tuesday, November 18, 2003 4:21 PM
> To: Avalon Developers List
> Subject: Re: [proposal] IoC type 3.14 extension to the Avalon
> Framework
>
>
> Ulrich Mayring wrote:
>
> > Jonathan Hawkes wrote:
> >
> >> Did you even read the rest of the message? I'm not
> pushing a type 3
> >> replacement. You could continue to write components as
> you wish. Please
> >> see the original message and do me the courtesy of reading
> it. I'm not
> >> trying to spark an argument over which way is best.
> >
> >
> > Sorry to be unclear, I'll try again. I wanted to communicate that I
> > don't see the need for type 3 and therefore your proposal.
> This does not
> > mean that I would -1 it, if I were a committer. It just
> means that I
> > don't need it and haven't understood why others do :)
>
> Easy:
>
> There are developers who simply refuse to use other people's
> interfaces
> (shocking but true), and to support folks who suffer from NIH syndrome
> (Not Invented Here), the constructor mechanism what was come up from.
>
> It has everything to do with development style, and what some
> developers
> think is easy others think is a pain.
>
> That's why I really don't care what method is used to
> accomplish IoC as
> long as it is supported.
>
>
> --
>
> "They that give up essential liberty to obtain a little
> temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Berin Loritsch <bl...@apache.org>.
Ulrich Mayring wrote:
> Jonathan Hawkes wrote:
>
>> Did you even read the rest of the message? I'm not pushing a type 3
>> replacement. You could continue to write components as you wish. Please
>> see the original message and do me the courtesy of reading it. I'm not
>> trying to spark an argument over which way is best.
>
>
> Sorry to be unclear, I'll try again. I wanted to communicate that I
> don't see the need for type 3 and therefore your proposal. This does not
> mean that I would -1 it, if I were a committer. It just means that I
> don't need it and haven't understood why others do :)
Easy:
There are developers who simply refuse to use other people's interfaces
(shocking but true), and to support folks who suffer from NIH syndrome
(Not Invented Here), the constructor mechanism what was come up from.
It has everything to do with development style, and what some developers
think is easy others think is a pain.
That's why I really don't care what method is used to accomplish IoC as
long as it is supported.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Jonathan Hawkes <jh...@adsnm.com>.
Variety is the spice of life :)
----- Original Message -----
From: "Ulrich Mayring" <ul...@denic.de>
To: <de...@avalon.apache.org>
Sent: Tuesday, November 18, 2003 8:11 AM
Subject: Re: [proposal] IoC type 3.14 extension to the Avalon Framework
> Jonathan Hawkes wrote:
> > Did you even read the rest of the message? I'm not pushing a type 3
> > replacement. You could continue to write components as you wish.
Please
> > see the original message and do me the courtesy of reading it. I'm not
> > trying to spark an argument over which way is best.
>
> Sorry to be unclear, I'll try again. I wanted to communicate that I
> don't see the need for type 3 and therefore your proposal. This does not
> mean that I would -1 it, if I were a committer. It just means that I
> don't need it and haven't understood why others do :)
>
> cheers,
>
> Ulrich
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Leo Simons <le...@apache.org>.
Ulrich Mayring wrote:
> Sorry to be unclear, I'll try again. I wanted to communicate that I
> don't see the need for type 3 and therefore your proposal. This does not
> mean that I would -1 it, if I were a committer. It just means that I
> don't need it and haven't understood why others do :)
one way to view things....there is no *need* for type 3: all components
you could write using type 3, you can write using avalon-framework
semantics, simply because the semantics supported by avalon-framework
are a superset of type 3 IoC.
There are, however, various reasons one might prefer the type 3
semantics; those have been detailed in various places and e-mails. Most
of those reasons contain a value assessment; semantic preferences
usually do. Compare it to the age-old debate-for-access-modifiers, for
example.
The thing everyone should try and understand is that different contexts,
developer preferences, use cases, IDEs....are all factors which can
influence the value assessment.
From there, you may begin to see that there is, if not a "need", at
least a reasonable "desire" for type 3 semantics.
cheers!
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Ulrich Mayring <ul...@denic.de>.
Jonathan Hawkes wrote:
> Did you even read the rest of the message? I'm not pushing a type 3
> replacement. You could continue to write components as you wish. Please
> see the original message and do me the courtesy of reading it. I'm not
> trying to spark an argument over which way is best.
Sorry to be unclear, I'll try again. I wanted to communicate that I
don't see the need for type 3 and therefore your proposal. This does not
mean that I would -1 it, if I were a committer. It just means that I
don't need it and haven't understood why others do :)
cheers,
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Jonathan Hawkes <jh...@adsnm.com>.
Yes, but PI is more clear.
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Avalon Developers List" <de...@avalon.apache.org>
Sent: Tuesday, November 18, 2003 8:22 AM
Subject: Re: [proposal] IoC type 3.14 extension to the Avalon Framework
> Jonathan Hawkes wrote:
>
> > I like that :) Avalon PI
> >
>
> Isn't that what you were going for with IoC Type 3.14?
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Berin Loritsch <bl...@apache.org>.
Jonathan Hawkes wrote:
> I like that :) Avalon PI
>
Isn't that what you were going for with IoC Type 3.14?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Jonathan Hawkes <jh...@adsnm.com>.
I like that :) Avalon PI
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Avalon Developers List" <de...@avalon.apache.org>
Sent: Tuesday, November 18, 2003 8:04 AM
Subject: Re: [proposal] IoC type 3.14 extension to the Avalon Framework
> Jonathan Hawkes wrote:
>
> > Did you even read the rest of the message? I'm not pushing a type 3
> > replacement. You could continue to write components as you wish.
Please
> > see the original message and do me the courtesy of reading it. I'm not
> > trying to spark an argument over which way is best.
> >
>
> Which is why the "IoC type Who Cares" RT would be best. It allows
enterprsing
> folks to try something new, while still working with the tried and true.
>
> Since I like names better than numbers (I couldn't tell you what the
difference
> is between IoC type 1, type 2, or type 3 simply from its identifier), I
guess
> you could call your proposal Avalon PI.
>
> Also, if we have an infrastructure that is flexible enough, it would allow
> us to play around for Avalon 5 and see what feels the best. No need for
> arguing the pros and cons--we just do it, and it works. Of course, we
might
> argue that the simplified container architecture is Avalon 5....
>
> Until we have an infrastructure that is flexible enough, we really can't
start
> to look at Avalon 5 though.
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Berin Loritsch <bl...@apache.org>.
Jonathan Hawkes wrote:
> Did you even read the rest of the message? I'm not pushing a type 3
> replacement. You could continue to write components as you wish. Please
> see the original message and do me the courtesy of reading it. I'm not
> trying to spark an argument over which way is best.
>
Which is why the "IoC type Who Cares" RT would be best. It allows enterprsing
folks to try something new, while still working with the tried and true.
Since I like names better than numbers (I couldn't tell you what the difference
is between IoC type 1, type 2, or type 3 simply from its identifier), I guess
you could call your proposal Avalon PI.
Also, if we have an infrastructure that is flexible enough, it would allow
us to play around for Avalon 5 and see what feels the best. No need for
arguing the pros and cons--we just do it, and it works. Of course, we might
argue that the simplified container architecture is Avalon 5....
Until we have an infrastructure that is flexible enough, we really can't start
to look at Avalon 5 though.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Jonathan Hawkes <jh...@adsnm.com>.
Did you even read the rest of the message? I'm not pushing a type 3
replacement. You could continue to write components as you wish. Please
see the original message and do me the courtesy of reading it. I'm not
trying to spark an argument over which way is best.
----- Original Message -----
From: "Ulrich Mayring" <ul...@denic.de>
To: <de...@avalon.apache.org>
Sent: Tuesday, November 18, 2003 7:43 AM
Subject: Re: [proposal] IoC type 3.14 extension to the Avalon Framework
> Jonathan Hawkes wrote:
> >
> > I hope that the example needs little explanation (it is a bit contrived,
I admit).
>
> And that is a problem. If you had a real example of a working
> application, you'd find that there's a lot of code in the lifecycle
> methods (at least that is the case with our apps). In the type3 example
> all that stuff would have to be in the constructor.
>
> Because of obfuscation we have moved from DIY to the Avalon framework in
> the first place. And now people are trying to go back to "roll your own"?
>
> If anything, we'd need more framework, not less. We've written an
> application framework on top of Avalon to standardize even more. The
> Cocoon and Keel folks have done the same.
>
> Ulrich
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Ulrich Mayring <ul...@denic.de>.
Niclas Hedhman wrote:
>
> Are you saying that you DO want control or that you DO NOT want control?
I want the container to have control over the lifecycle of the component
it manages. I don't want the component to have control over its
lifecycle. So the answer is: depends on the point of view :)
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 18 November 2003 23:14, Ulrich Mayring wrote:
> Niclas Hedhman wrote:
> > Not having an opinion about his proposal at large (yet), your counter
> > argument is a bit bleak. Ever heard of methods ;o) ?
> >
> > public class Abc
> > {
> > public Abc( Configuration conf, ServiceManager man )
> > throws Exception
> > {
> > configure( conf );
> > service( man );
> > }
> > }
> >
> > Would that be so much different from what you are doing now?
>
> Of course it would. I cannot control the order in which the lifecycle
> stages are called, for example, or even their names.
Control? Reading your later posts, this statement makes we really wonder where
you come from.
Are you saying that you DO want control or that you DO NOT want control?
Are you saying; "Hey I have no clue in which order I should get my component
into operational shape, so please guide in runtime." ?
I am not arguing against Avalon4, just argue against your defense of it, which
makes absolutely no sense to me. :o(|) (Saya Monyet Bodoh!)
Cheers,
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Jonathan Hawkes <jh...@adsnm.com>.
> In Avalon you can control a component's lifecycle, in type3 you can't,
> because the component decides itself. No way of knowing what it does in
> its constructor. So I actually wonder whether type3 is IOC at all.
The Avalon Framework component contract clearly defines the order in which
the "lifecycle" interfaces MUST be called. LogEnabled, Contextualizable,
Serviceable, Configurable, Initializable -- in that order I believe. For a
container to invoke these methods in any other order is an implementation
error which violates the component contract and could possibly leave the
component in an unknown state. There is no such chance with IoC 3. And as
it has been discussed before, "lifecycle" is actually a misnomer for these
interfaces. The above interfaces allow the component to put itself together
before it is actually brought out to face the world. It is like a parent
(the container) passing on its DNA to its child (the component) before it is
born.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Ulrich Mayring <ul...@denic.de>.
Niclas Hedhman wrote:
>
> Some people here would say, the component writer already knows which order
> things must be executed, and if that is violated (by mistake for instance),
> the unit testing would catch it.
You're right, but the violator wouldn't write unit tests for that :)
If there were some generic unit tests usable "out of the box", that
would be quite different.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension to the Avalon Framework)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 19 November 2003 17:02, Ulrich Mayring wrote:
> Niclas Hedhman wrote:
> > Guys, remember Ulrich doesn't do UnitTesting at all, so he need the
> > container to enforce the accuracy of his code. He assumes that the
> > component writer is an idiot, who doesn't know how to code and need all
> > the UnitTesting to happen in runtime ;o)
>
> The container is responsible for calling the lifecycle methods in the
> correct order. Don't know what that has to do with unit testing. It has
> a lot to do with coding conventions in a multi-developer team. Maybe you
> guys work on your components all by yourself, but we have 9 people using
> each other's components, so standards are very important.
I was implying that you want an external party to enforce the component
developer to "configure before starting threads", and all the other execution
requirements of the component.
Some people here would say, the component writer already knows which order
things must be executed, and if that is violated (by mistake for instance),
the unit testing would catch it.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Ulrich Mayring <ul...@denic.de>.
Niclas Hedhman wrote:
>
> Guys, remember Ulrich doesn't do UnitTesting at all, so he need the container
> to enforce the accuracy of his code. He assumes that the component writer is
> an idiot, who doesn't know how to code and need all the UnitTesting to happen
> in runtime ;o)
The container is responsible for calling the lifecycle methods in the
correct order. Don't know what that has to do with unit testing. It has
a lot to do with coding conventions in a multi-developer team. Maybe you
guys work on your components all by yourself, but we have 9 people using
each other's components, so standards are very important.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension to the Avalon Framework)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 19 November 2003 02:32, Leo Simons wrote:
> Ulrich Mayring wrote:
> > Berin Loritsch wrote:
> >> The choice of how to apply IoC is a matter of taste in many cases. If
> >> everything is passed in the constructor, then we have a more atomic
> >> construction phase. But in reality no component is used until after the
> >> construction phase.
> >
> > Yep, but you have no control over the order in which the lifecycles
> > Compose, Configure, Initialize, Contextualize etc. are called.
>
> depending on how you look at it...you have control using 'type 3', and
> you don't have control (its dictated by the framework semantics) using
> avalon-framework.
Guys, remember Ulrich doesn't do UnitTesting at all, so he need the container
to enforce the accuracy of his code. He assumes that the component writer is
an idiot, who doesn't know how to code and need all the UnitTesting to happen
in runtime ;o)
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Stephen McConnell <mc...@apache.org>.
Ulrich Mayring wrote:
> Berin Loritsch wrote:
>
>>
>> The choice of how to apply IoC is a matter of taste in many cases. If
>> everything is passed in the constructor, then we have a more atomic
>> construction
>> phase. But in reality no component is used until after the
>> construction phase.
>
>
> Yep, but you have no control over the order in which the lifecycles
> Compose, Configure, Initialize, Contextualize etc. are called.
> Everything is collapsed within the constructor and it is assumed that
> the order of construction is irrelevant.
>
> However, it does make a difference whether you initialize an
> unconfigured component or configure an uninitialized component. For
> example, a component that accesses an external resource might need a
> username/password before it can do that. So it is vital that this
> component passes through configuration before initialisation.
>
> Of course it is possible to maintain the correct order in a
> constructor, but it cannot be guaranteed anymore. The component itself
> decides.
Actually isn't it the containers job to ensure that everything supplied
atomically (i.e. via the constructor) are consitent? No ordering should
be assumed in the atomic case.
Stephen.
>
>
> Ulrich
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
>> Ulrich Mayring wrote:
>>> Leo Simons wrote:
>>>
>>>> class MyComponent implements Configurable
>>>> {
>>>> public void configure( Configuration config )
>>>> {
>>>> new Thread( getNewWorker() ).start; // quite possible. Wrong, but
>>>> // possible
>>>> m_val = config.getChild("blah").value();
>>>> }
>>>> }
>>>
>>> We have invented an application framework on top of Avalon to prevent
>>> things like that.
<snip/>
>
> This is something I would welcome.
+1! (though it should be optional :D)
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Ulrich Mayring wrote:
>
>> Leo Simons wrote:
>>
>>> class MyComponent implements Configurable
>>> {
>>> public void configure( Configuration config )
>>> {
>>> new Thread( getNewWorker() ).start; // quite possible. Wrong, but
>>> // possible
>>> m_val = config.getChild("blah").value();
>>> }
>>> }
>>
>>
>> We have invented an application framework on top of Avalon to prevent
>> things like that. Yes, we thought about contributing that to Avalon,
>> but it's pretty hard to come up with something sufficiently general.
>
>
> most interesting! May I ask how? SecurityManager or something like that
> (hmm, would that work...)? Also, may I ask why? You run untrusted
> components?
Actually Leo, this is something I would welcome. As we delve into the world
of distributed components, or remote repositories, we need to ensure that the
unknown components are not given access to too much. IOW, we need to support
untrusted components--but we have been working in the much simpler world of
a trusted environment.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Leo Simons <le...@apache.org>.
Ulrich Mayring wrote:
> Leo Simons wrote:
>
>> class MyComponent implements Configurable
>> {
>> public void configure( Configuration config )
>> {
>> new Thread( getNewWorker() ).start; // quite possible. Wrong, but
>> // possible
>> m_val = config.getChild("blah").value();
>> }
>> }
>
> We have invented an application framework on top of Avalon to prevent
> things like that. Yes, we thought about contributing that to Avalon, but
> it's pretty hard to come up with something sufficiently general.
most interesting! May I ask how? SecurityManager or something like that
(hmm, would that work...)? Also, may I ask why? You run untrusted
components?
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Ulrich Mayring <ul...@denic.de>.
Leo Simons wrote:
> mind you, that is the case with avalon as well:
>
> class MyComponent implements Configurable
> {
> public void configure( Configuration config )
> {
> new Thread( getNewWorker() ).start; // quite possible. Wrong, but
> // possible
> m_val = config.getChild("blah").value();
> }
> }
We have invented an application framework on top of Avalon to prevent
things like that. Yes, we thought about contributing that to Avalon, but
it's pretty hard to come up with something sufficiently general.
cheers,
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Leo Simons <le...@apache.org>.
Ulrich Mayring wrote:
> Berin Loritsch wrote:
>
>> The choice of how to apply IoC is a matter of taste in many cases. If
>> everything is passed in the constructor, then we have a more atomic
>> construction phase. But in reality no component is used until after the
>> construction phase.
>
> Yep, but you have no control over the order in which the lifecycles
> Compose, Configure, Initialize, Contextualize etc. are called.
depending on how you look at it...you have control using 'type 3', and
you don't have control (its dictated by the framework semantics) using
avalon-framework.
> Everything is collapsed within the constructor and it is assumed that
> the order of construction is irrelevant.
I would say that it is assumed that the component itself will ensure
correct order of construction, if any is required.
> However, it does make a difference whether you initialize an
> unconfigured component or configure an uninitialized component. For
> example, a component that accesses an external resource might need a
> username/password before it can do that. So it is vital that this
> component passes through configuration before initialisation.
>
> Of course it is possible to maintain the correct order in a constructor,
> but it cannot be guaranteed anymore. The component itself decides.
mind you, that is the case with avalon as well:
class MyComponent implements Configurable
{
public void configure( Configuration config )
{
new Thread( getNewWorker() ).start; // quite possible. Wrong, but
// possible
m_val = config.getChild("blah").value();
}
}
in terms of security, its best to look at the avalon lifecycle as a
convention, not as something which is enforced. It is not enforced.
There is no guarantee.
cheers!
- LSD
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=users@avalon.apache.org&msgId=624609
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension
to the Avalon Framework)
Posted by Ulrich Mayring <ul...@denic.de>.
Berin Loritsch wrote:
>
> The choice of how to apply IoC is a matter of taste in many cases. If
> everything is passed in the constructor, then we have a more atomic
> construction
> phase. But in reality no component is used until after the construction
> phase.
Yep, but you have no control over the order in which the lifecycles
Compose, Configure, Initialize, Contextualize etc. are called.
Everything is collapsed within the constructor and it is assumed that
the order of construction is irrelevant.
However, it does make a difference whether you initialize an
unconfigured component or configure an uninitialized component. For
example, a component that accesses an external resource might need a
username/password before it can do that. So it is vital that this
component passes through configuration before initialisation.
Of course it is possible to maintain the correct order in a constructor,
but it cannot be guaranteed anymore. The component itself decides.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Definition of IoC (was Re: [proposal] IoC type 3.14 extension to
the Avalon Framework)
Posted by Berin Loritsch <bl...@apache.org>.
Ulrich Mayring wrote:
> Niclas Hedhman wrote:
>
>>
>> ?? Since when can you control the lifecycle ??
>> I must have missed that feature/bug ;o)
>
>
> It's called IOC :-)
>
> In Avalon you can control a component's lifecycle, in type3 you can't,
> because the component decides itself. No way of knowing what it does in
> its constructor. So I actually wonder whether type3 is IOC at all.
>
It is sometimes difficult to separate out what exactly IoC looks like when
there are so many ways to implement it. That is why it is a *pattern* and
not a predefined library.
At its root, IoC means inversion of control. The component does not decide
what facilities it uses, that information is provided to the component by
the container. Whether this is done through a constructor, getter/setter,
or an interface (like Avalon 4), is irrelevant. As long as the life of the
component is directly controlled by the container, and not by itself then we
have IOC.
There are three basic "Phases" of life for a component: construction, active
use, and destruction.
What the "Type 3" IoC approach does is collapse all of the construction phase
into the constructor. That is the contract between the component and the
container.
The "Type 2" IoC approach is not to use interfaces beyond the simple
Initializable and Desposable style interfaces. Any method calls before
the initialize() method is called are construction phase calls. Essentially
it looks like a JavaBean with setters/getters for all configuration points
and external service provision. This is roughly what javax.sql.DataSource
components do.
The "Type 1" IoC approach is Avalon 4.
The titles of "Type 1,2,3,XXX" were applied by the folks who created nano and
pico container.
The choice of how to apply IoC is a matter of taste in many cases. If
everything is passed in the constructor, then we have a more atomic construction
phase. But in reality no component is used until after the construction phase.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Ulrich Mayring <ul...@denic.de>.
Niclas Hedhman wrote:
>
> ?? Since when can you control the lifecycle ??
> I must have missed that feature/bug ;o)
It's called IOC :-)
In Avalon you can control a component's lifecycle, in type3 you can't,
because the component decides itself. No way of knowing what it does in
its constructor. So I actually wonder whether type3 is IOC at all.
>>Curious: what does "more neutral" mean in this context?
>
> Let's say that Peter Royal, Leo Simons and 400 other developers thinks
> PicoContainer is a better way to develop components. 400 Type2 component
> developers think their way is better, and 400 Type 1 ....
> All go about developing their stuff... Resulting in, for the sake of
> neutrality, 400 components of each type.
Ok, in the original posting it sounded like type3 was "more neutral"
than the other types and that I did not understand.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 18 November 2003 23:14, Ulrich Mayring wrote:
> Niclas Hedhman wrote:
> > Not having an opinion about his proposal at large (yet), your counter
> > argument is a bit bleak. Ever heard of methods ;o) ?
> >
> > public class Abc
> > {
> > public Abc( Configuration conf, ServiceManager man )
> > throws Exception
> > {
> > configure( conf );
> > service( man );
> > }
> > }
> >
> > Would that be so much different from what you are doing now?
>
> Of course it would. I cannot control the order in which the lifecycle
> stages are called, for example, or even their names.
Your statement is a bit ambigious, let me illustrate...
?? Since when can you control the lifecycle ??
I must have missed that feature/bug ;o)
Or are you saying that "pure Avalon 4", you can't control it, as you could
above? Ok, I buy this argument, hands down, and that's why this discussion is
already getting tweaked in the wrong direction.
> > AND, you don't have to use what he is suggesting, right?? If you like the
> > strict cycle (like I do, still), stick with it... But if we get access to
> > more components, i.e. components written in more neutral ways, I am +1
> > for that.
>
> Curious: what does "more neutral" mean in this context?
Let's say that Peter Royal, Leo Simons and 400 other developers thinks
PicoContainer is a better way to develop components. 400 Type2 component
developers think their way is better, and 400 Type 1 ....
All go about developing their stuff... Resulting in, for the sake of
neutrality, 400 components of each type.
Wouldn't even you be interested in using all teh 1200 components in your
Merlin container, mix-and-match whatever is available and fulfilling your
needs (function, performance, quality, whatever), or would you refuse and
stick only with the Type 1???
Well, for me it is a dirt-easy choice...
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Ulrich Mayring <ul...@denic.de>.
Niclas Hedhman wrote:
>
> Not having an opinion about his proposal at large (yet), your counter argument
> is a bit bleak. Ever heard of methods ;o) ?
>
> public class Abc
> {
> public Abc( Configuration conf, ServiceManager man )
> throws Exception
> {
> configure( conf );
> service( man );
> }
> }
>
> Would that be so much different from what you are doing now?
Of course it would. I cannot control the order in which the lifecycle
stages are called, for example, or even their names.
> AND, you don't have to use what he is suggesting, right?? If you like the
> strict cycle (like I do, still), stick with it... But if we get access to
> more components, i.e. components written in more neutral ways, I am +1 for
> that.
Curious: what does "more neutral" mean in this context?
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 18 November 2003 22:43, Ulrich Mayring wrote:
> And that is a problem. If you had a real example of a working
> application, you'd find that there's a lot of code in the lifecycle
> methods (at least that is the case with our apps). In the type3 example
> all that stuff would have to be in the constructor.
Not having an opinion about his proposal at large (yet), your counter argument
is a bit bleak. Ever heard of methods ;o) ?
public class Abc
{
public Abc( Configuration conf, ServiceManager man )
throws Exception
{
configure( conf );
service( man );
}
}
Would that be so much different from what you are doing now?
AND, you don't have to use what he is suggesting, right?? If you like the
strict cycle (like I do, still), stick with it... But if we get access to
more components, i.e. components written in more neutral ways, I am +1 for
that.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] IoC type 3.14 extension to the Avalon Framework
Posted by Ulrich Mayring <ul...@denic.de>.
Jonathan Hawkes wrote:
>
> I hope that the example needs little explanation (it is a bit contrived, I admit).
And that is a problem. If you had a real example of a working
application, you'd find that there's a lot of code in the lifecycle
methods (at least that is the case with our apps). In the type3 example
all that stuff would have to be in the constructor.
Because of obfuscation we have moved from DIY to the Avalon framework in
the first place. And now people are trying to go back to "roll your own"?
If anything, we'd need more framework, not less. We've written an
application framework on top of Avalon to standardize even more. The
Cocoon and Keel folks have done the same.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org